This chapter defines the interview framework used throughout the book. Read it after this lesson.
System design interviews are deliberately open-ended. "Design Twitter" could go a hundred directions. The interviewer isn't just checking your technical knowledge — they're watching how you think: do you clarify before diving in? Do you reason about scale? Do you explain your trade-offs?
A framework gives you a repeatable structure so you spend your mental energy on substance, not on figuring out what to say next.
Most candidates fail not because they don't know enough — they fail because they start drawing without clarifying requirements, or they go silent and work alone. The interviewer wants a collaborative conversation, not a monologue.
This maps to a 45-minute interview. The time splits are approximate — let the conversation guide you.
Never start drawing. Your first job is to understand what you're actually building.
Functional requirements — what features must the system support? Agree on 2–4 core features. Push back on scope creep.
Non-functional requirements — scale, latency, availability. Ask:
Write requirements on the board as you hear them. The interviewer will confirm or correct — that's valuable signal.
Show you understand scale. Use rough numbers — magnitude matters, not precision.
See the Estimation Cheat Sheet for latency numbers and size references.
This is the core. Draw the architecture and walk through the main flows.
Don't over-engineer the first design. Start with the simplest thing that works, then evolve it. If you open with 15 microservices, you've nowhere to go.
The interviewer will direct you: "Tell me more about how the database scales" or "What happens if the cache fails?" This is where you differentiate yourself.
Never go silent for more than 30 seconds. If you're thinking, say "I'm considering two options here — option A has lower latency but option B gives us stronger consistency. Let me think through the trade-offs…" Thinking out loud is the entire point.