A repeatable interview framework
A minute-by-minute script for the 45-minute design interview, so you spend your time in the right places and never freeze on a blank whiteboard.
Why you need a script
Under pressure, structure is what saves you. Every design problem in this chapter is solved with the same five-step motion — the one from Chapter 1, now expanded into a process you can run on autopilot while your attention goes to the actual engineering. Memorize the steps; improvise the content.
A rough time budget for a 45-minute interview:
| Phase | Time | What you produce |
|---|---|---|
| 1. Requirements | ~5 min | Scoped features + non-functional targets |
| 2. Estimation | ~5 min | QPS, storage, bandwidth → design drivers |
| 3. API + data model | ~5 min | Endpoints and the core schema |
| 4. High-level design | ~10 min | Boxes and arrows, the happy path |
| 5. Deep dives + scale | ~15 min | Bottlenecks, the interesting components |
| Wrap-up | ~5 min | Trade-offs, failures, “what I’d do next” |
The single most common mistake is skipping 1–2 and over-spending on 4. Don’t.
Step 1 — Requirements (scope it)
Turn the vague prompt into a contract. Ask clarifying questions, list functional requirements, then cut hard to a core you can actually design. State non-functional targets — scale, latency, availability, consistency — and confirm everything with the interviewer. (See the Chapter 1 lessons on requirements.) Write the scope on the board; it’s your reference for the rest.
Step 2 — Estimation (justify with numbers)
A few back-of-the-envelope figures: QPS (average and peak), read:write ratio, storage/year, bandwidth. You’re not after precision — you’re finding the design drivers: “100k reads/sec → must cache”; “50 TB/year → must shard.” Call out the numbers that force a decision. (Chapter 1’s estimation lesson is the recipe.)
Step 3 — API and data model
Define the interface before the internals — a handful of endpoints (or RPCs)
for your in-scope features: POST /tweet, GET /timeline. Then the core data
model: the main entities, their key fields, and the access patterns. This forces
clarity and naturally exposes the hard parts (a many-to-many here, a hot key
there).
Step 4 — High-level design (boxes and arrows)
Draw the happy path end to end: clients → load balancer → services → stores, plus caches, queues, and any specialized components (search index, blob store). Keep it simple first — one diagram a teammate could follow. Walk a read and a write request through it out loud. Don’t optimize yet.
Step 5 — Deep dives and scaling
This is where senior candidates win. Pick the interesting components (or follow the interviewer’s lead) and go deep: the timeline fan-out, the id generator, the matching engine, the consistency model. For each, name the bottleneck, apply the right building block (Chapter 2), and state the trade-off (Chapter 3). Proactively cover scale and failure: hot keys, a dead node, a region outage, a 10× spike.
Wrap-up
Summarize the key decisions and their trade-offs, call out what you’d improve with more time, and mention operational concerns (monitoring, deploys). Ending with “here’s what I’d revisit and why” leaves a strong, self-aware impression.
The meta-rules
- Drive the conversation — propose, don’t wait to be asked.
- Think out loud — narrate every choice; silence is invisible work.
- Tie every decision to a requirement or a number — no choices by taste.
- Start simple, scale on demand — add complexity only where an estimate forces it.
- State the cost of each choice — the three-clause trade-off sentence from Chapter 3.
Run this script on every problem ahead. The next lesson turns it into a concrete template you can stamp onto any prompt.