What the interview tests + the framework

The system design interview feels open-ended and scary because there's no single right answer. But it's the most learnable interview once you see it for what it is: a structured conversation with a repeatable framework. This lesson gives you that framework.

What they're actually testing

Nobody expects you to design Twitter in 45 minutes. Interviewers are checking whether you can:

• Handle ambiguity — turn a vague prompt into concrete requirements.
• Reason about trade-offs — every choice has a cost; can you name it?
• Think at scale — what breaks at 1M users that didn't at 1K?
• Communicate — structure your thinking so a teammate can follow it.

It's a simulation of real senior work: taking "we need a notifications system" and producing a defensible design.

The framework (memorize this)

1. 1Requirements — clarify scope; what's in, what's out.
2. 2Estimation — rough numbers for scale (users, QPS, storage).
3. 3API & data model — the contract and the core entities.
4. 4High-level design — boxes and arrows; the happy path end to end.
5. 5Deep dive — pick 1–2 components and go deep; scale them.
6. 6Bottlenecks — identify weak points, single points of failure, and trade-offs.

The cardinal rule: drive the conversation

The biggest failure mode isn't a wrong answer — it's silence, or jumping straight to databases. Narrate your thinking. Ask questions. State assumptions. The interviewer is your collaborator, not an examiner waiting for you to slip.