The 6-Step Framework

A 45-minute system-design interview is not a test of whether you can build the system. You can't — nobody can in 45 minutes. It's a test of whether you drive a vague prompt into a defensible design without being told what to do next. This chapter is the process that does that, minute by minute.

The reframe
The interviewer already knows the "answer." What they're measuring is your operating procedure under ambiguity: do you scope before you scale, quantify before you architect, and name tradeoffs before you're cornered? The framework below is that procedure made explicit. Run it on every problem and you never freeze.

1 Why a process beats brilliance

The single most common failure isn't ignorance — it's a strong candidate who hears "design Twitter" and starts drawing Kafka topics at minute two. They've answered a question nobody asked, at a scale nobody specified, and now every later decision hangs off an assumption they never stated. The fix is boring and it works: always run the same six steps in the same order.

The six steps
  1. Requirements — functional, non-functional, and explicit scope cuts.
  2. Estimation — QPS, storage, bandwidth. Turn "scale" into numbers.
  3. API — the contract. Forces you to nail down what the system actually does.
  4. Data model — entities, keys, access patterns. The schema constrains everything.
  5. High-level design — boxes and arrows. The end-to-end request path.
  6. Deep dive — one or two components, taken to bedrock. This is where senior shows.
"Let me start by clarifying scope and writing down a few assumptions, then size it, then sketch the design — and I'll go deep wherever you want to steer."

Say that sentence in the first 60 seconds. It tells the interviewer you have a plan, that you'll be steerable, and that you won't rabbit-hole. From that point you're the one running the room.

2 The 45-minute timeline

Here's the hardest thing to internalize: the budget is fixed and front-loaded toward thinking, not drawing. Walk the timeline below. At each step, watch the time spent versus the signal the interviewer is recording — those are two different things, and conflating them is how good candidates run out of clock with a half-drawn diagram.

Interview use
Keep a literal clock in your head. At the 20-minute mark you should be finishing the high-level design, not starting it. If you're still in requirements at minute 15, you've already lost — say "I'll lock scope here and move to sizing" and force yourself forward.

3 What the interviewer is actually scoring

Every step has a hidden rubric. The deliverable (a diagram, a number) is just the artifact; the signal is the reasoning behind it. Same minutes, different scores:

StepBudgetArtifactSenior signal they're recording
Requirements~5 minScoped feature listNaming what you exclude; reads vs writes; consistency needs
Estimation~5 minQPS & storageWhich number drives the design (e.g. read-heavy → cache)
API~5 minEndpoint contractRight granularity; idempotency; pagination; auth boundary
Data model~5 minSchema + keysAccess-pattern-driven keys; SQL vs NoSQL justified
High-level~10 minComponent diagramClean request path; where state lives; obvious bottleneck named
Deep dive~12 minOne component, deepReal tradeoffs, failure handling, numbers — this is the seniority test
Wrap / Q&A~3 minRecap + risksSelf-critique: what you'd revisit with more time
Signal vs noise
Signal = a decision plus the reason plus the rejected alternative. "I'll shard by user_id because all reads are per-user, so no scatter-gather — at the cost of celebrity hot partitions, which I'll handle separately." Noise = naming technologies. "I'll use Cassandra and Redis and Kafka" scores nothing on its own; it's a list, not a thought. Seniors are measured in tradeoffs, not nouns.

4 The senior rubric: depth over breadth

Junior and senior candidates often produce the same high-level diagram. They diverge in the deep dive. A junior keeps the design wide and shallow — every box gets one sentence. A senior picks the load-bearing component and excavates: the data model, the failure mode, the number that breaks it. The shape of a strong interview looks like this:

depth breadth (components touched) junior: wide & shallow senior: deep where it matters the deep dive

Breadth gets you a passing high-level design. The spike — one component taken all the way down — is what separates a hire from a strong hire. When the interviewer says "tell me more about X," they're handing you the spike. Take it.

5 The four ways candidates lose

Almost every "no-hire" maps to one of these. Learn to catch yourself mid-sentence.

Failure 1 · Premature solution
Jumping to architecture before scope. You design for 1B users when the prompt implied 1M, or you build analytics nobody asked for. Tell: you're drawing boxes in the first three minutes. Fix: no diagram until requirements and estimation are on the board.
Failure 2 · Weak tradeoffs
Stating a choice with no alternative and no cost. "I'll use NoSQL" — why? versus what? at what cost? A decision without a rejected option is an assertion, not engineering. Fix: every significant choice gets the sentence pattern "X over Y because Z, at the cost of W."
Failure 3 · Hand-wavy scale
"It'll scale horizontally." That phrase is a red flag, not an answer. What scales, by what mechanism, and what's the new bottleneck? If you can't put a number on it, you haven't designed it. Fix: tie scaling claims back to the QPS and storage numbers from step 2.
Failure 4 · No driving
Going silent, waiting to be asked the next question, or sprawling without ever committing. The interviewer should feel like a passenger, not a tour guide. Fix: narrate your plan and announce each transition out loud.
Tradeoff · breadth-first vs depth-first when time is short

Finish the skeleton first

Get a complete, if shallow, end-to-end design on the board, then deepen. Guarantees you have a working answer if the clock runs out. Best default.

Deep-dive early

Shows depth fast and impresses — but risks an incomplete system if you mistime it. Only do this when the interviewer explicitly steers you into one component.

6 The exact phrases that drive the room

Senior signal is partly verbal. These lines do real work — they structure the conversation, surface tradeoffs, and keep you steerable. Memorize the shape of them.

MomentThe line
Opening"Before I design anything, let me clarify scope and state my assumptions."
Cutting scope"I'll treat analytics as out of scope for now and revisit if we have time."
Framing from numbers"This is read-heavy at ~100:1, so I'll optimize the read path and accept a heavier write path."
Every tradeoff"I'll pick X over Y because Z — the cost is W, which I'll mitigate by…"
Staying steerable"I can go deeper on the data model or the caching layer — which is more interesting to you?"
Catching your own gap"One risk here is hot partitions; let me address that explicitly."
Time check"I'm watching the clock — let me lock this and move to the deep dive."
Wrap-up"With more time I'd revisit X and load-test Y. The biggest risk is Z."
Interview use
The "which is more interesting to you?" line is quietly the most powerful one. It converts the interviewer into a collaborator who is now telling you where the points are. Always give them a steering wheel before you commit 12 minutes to a deep dive.
The mindset shift
Stop trying to produce the perfect system. Start trying to demonstrate the thinking of someone you'd want on your team: scopes ruthlessly, quantifies instinctively, owns tradeoffs, and never goes quiet. The framework isn't a script to recite — it's the visible shape of that thinking.

7 Checkpoint