| name | interview-prep |
| description | Prepare for system-design interviews using a repeatable framework - requirements clarification, capacity estimation, API and data design, deep dives, and trade-off articulation. Use when coaching candidates, calibrating interviewers, or self-preparing for staff/principal/architect loops. |
System Design Interview Prep
Strong candidates win on structure, not trivia. A repeatable framework keeps you driving the conversation, surfaces trade-offs the interviewer cares about, and leaves time for the deep dive that distinguishes seniority.
Stack Baseline (2026)
| Concern | Recommended |
|---|
| Framework | Requirements -> Estimation -> API -> Data -> HLD -> Deep dive -> Trade-offs |
| Modeling | C4 Context + Container on the whiteboard |
| Reference text | Richards & Ford, Fundamentals of Software Architecture 2e |
| Distributed depth | Designing Data-Intensive Applications (Kleppmann), The Hard Parts |
| Patterns | Event-driven, CQRS, outbox, saga, CDC, sharding, consistent hashing |
| Practice format | Architecture Kata (Ted Neward), 45-min timeboxed mocks |
When to Use
- Personal prep for staff/principal/architect interview loops.
- Coaching internal candidates on promotion panels.
- Calibrating interviewer rubric so signal is consistent.
Prerequisites
- Comfort with one cloud's primitives (compute, queue, KV, OLTP, OLAP, object store).
- Working mental model of CAP, latency numbers, and consistency models.
- A whiteboard or digital canvas; a stopwatch.
Instructions
flowchart LR
R[Requirements<br/>5 min] --> E[Estimation<br/>5 min]
E --> A[API + Data<br/>10 min]
A --> H[High-Level Design<br/>10 min]
H --> D[Deep Dive<br/>10 min]
D --> T[Trade-offs + Wrap<br/>5 min]
- Clarify requirements: functional, non-functional (RPS, latency, durability, consistency), constraints. Write them on the board.
- Estimate capacity: users, QPS read/write, storage/day, bandwidth. Show the math; round aggressively.
- Sketch API + data model: 3-6 endpoints, key entities, access patterns, primary/secondary indexes.
- Draw HLD as C4 Containers: clients, edge, services, datastores, async backbone. Mark sync vs async.
- Pick a deep dive the interviewer signals interest in (hot path, sharding, consistency, failure mode).
- Articulate trade-offs: what you chose, what you rejected, what would change your mind.
# Mock Scoring Rubric (per dimension, 1-5)
- Requirements & scoping
- Capacity estimation (numbers, units, sanity)
- API & data modeling
- High-level design clarity (C4-ish)
- Distributed-systems depth (consistency, partitioning, failure)
- Trade-off articulation
- Communication & time management
Pass bar (Staff): >=4 average, no dimension <3, deep dive shows production scars.
Common Pitfalls
| Pitfall | Why it hurts | Fix |
|---|
| Jumping to a diagram | Misses the actual problem | Spend the first 5 min on requirements + NFRs |
| Hand-waved estimates | Signals lack of rigor | Always show units and assumptions |
| Buzzword stacking | Reads as Golden Hammer | Justify each component against an NFR |
| One-way design | Can't defend choices | Pre-load 2-3 trade-off pairs (consistency vs availability, etc.) |
| No deep dive | Looks junior | Pick the riskiest piece and go three layers deep |
| Time blowouts | No wrap, no trade-offs | Use the 5/5/10/10/10/5 timebox |
Output Format
- A one-page personal cheat sheet: framework, latency numbers, estimation templates.
- A library of 10-15 practiced prompts with notes on chosen designs and rejected options.
- Mock recordings or transcripts scored against the rubric above.
Authoritative References
- Mark Richards & Neal Ford, Fundamentals of Software Architecture, 2e (O'Reilly, 2024).
- Mark Richards & Neal Ford, Software Architecture: The Hard Parts (O'Reilly).
- Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly).
- Ted Neward, Architecture Kata format — neward.net/architecturalkatas.
- C4 model — c4model.com.
- ThoughtWorks Technology Radar — thoughtworks.com/radar.
