Back to System design
How to Structure a 45-Minute System Design Interview
easyMost people who fail a system design round are not short of knowledge. They spend twenty minutes on requirements, draw a diagram nobody asked for, and never reach the part where the interviewer decides whether to hire them.
ScaleN/A — framework
Key Concepts
1
The interviewer is filling in a scorecard, and it is not "did they draw the right boxes". It is closer
to: did they scope the problem, did they justify choices with numbers, did they notice the bottleneck, and
could they go deep on at least one component. You control how much evidence they get for each, and the
control is time.
The interviewer is filling in a scorecard, and it is not "did they draw the right boxes".
2
Minutes 0-5: scope, out loud. Ask what the system must do and, more importantly, what it need not do.
Pin down one or two functional requirements to build for, then the non-functional ones that actually
constrain the design: scale, latency target, consistency requirement, availability. Write them down where
both of you can see. Five minutes, not fifteen.
Minutes 0-5: scope, out loud.
3
Minutes 5-10: the numbers. Users, actions per user, resulting read and write rates, storage per year.
This is where you earn the right to make design choices, because every later claim points back to a figure.
Finish with a sentence that starts "so this rules out...".
Minutes 5-10: the numbers.
4
Minutes 10-20: the high-level design. Boxes and arrows: clients, API layer, services, stores, queues,
caches. Walk one write and one read all the way through. Keep it simple enough that there is time left to
break it.
Minutes 10-20: the high-level design.
5
Minutes 20-35: go deep where the difficulty is. This is the part that decides the outcome, and the
component is usually obvious from the estimate — the fan-out, the hot partition, the exactly-once path. Let
the interviewer steer; if they ask about something, that is what they want to score.
Minutes 20-35: go deep where the difficulty is.
6
Minutes 35-42: break it on purpose. What happens when this node dies, this region is partitioned, this
key gets ten times the traffic? Volunteering failure modes is the strongest senior signal available, because
it shows you have operated systems and not only designed them.
Minutes 35-42: break it on purpose.
7
Minutes 42-45: summarise and name the trade-offs. Two sentences on what you built, one on what you
chose to give up, one on what you would do next with more time. Interviewers write their notes immediately
afterwards, and a clear summary writes those notes for them.
Minutes 42-45: summarise and name the trade-offs.
8
The recoveries worth rehearsing. If you are stuck, say what you are choosing between and why it is
close — that is a design discussion, not a silence. If the interviewer keeps returning to a component, stop
and go there. And if you realise your design is wrong at minute 30, say so and fix it; changing your mind
with a reason is a positive signal, not a failure.
The recoveries worth rehearsing.
9
What the interviewer is probing.
What the interviewer is probing.
10
1. "How would you spend the 45 minutes?" Probing: whether you have a plan. Stalls: "Start
designing." Moves up: roughly 5 minutes on requirements, 5 on estimates and the API, 15 on the
high-level design, 15 on a deep dive, 5 on bottlenecks.
1. "How would you spend the 45 minutes?"
11
2. "What is the most common way candidates lose the interview?" Probing: self-awareness.
Stalls: "Wrong technology." Moves up: drawing boxes before agreeing what is being built — scope
that is never pinned down means the design cannot be judged.
2. "What is the most common way candidates lose the interview?"
12
3. "What should you do when the interviewer interrupts?" Probing: how you take signals.
Stalls: "Finish your point." Moves up: follow them — an interruption is usually a steer toward
what they want to assess, and ignoring it wastes the time you have.
3. "What should you do when the interviewer interrupts?"
13
4. "What do you do if you are running out of time?" Probing: the practical skill. Stalls:
"Rush." Moves up: say what you would do next and why, rather than half-building it — stating the
trade-off scores better than an unfinished diagram.
4. "What do you do if you are running out of time?"
The clock
0-5 Scope
What must it do? What is out of scope?
Non-functional: scale, latency, consistency, availability.
Write them where both of you can see them. 5-10 Estimate
Users -> actions -> reads/writes per second -> storage/year.
End with: "so this rules out X". 10-20 High-level design
Boxes and arrows. Walk one write and one read end to end.
Keep it simple; you need time to break it later. 20-35 Deep dive
The component the estimate flagged. Data model, algorithm,
partitioning, the specific trade-off.
Follow the interviewer's steering -- their question IS the
scorecard line they are filling in. 35-42 Failure and scale
Node dies. Region partitions. Key gets 10x traffic.
Deploys, backpressure, what the user sees during each. 42-45 Summary
What you built, what you gave up, what is next. If you are running late
Sacrifice breadth, never the deep dive. A design with one
component explained properly beats five described vaguely.Signals, in the interviewer's words
Strong
"Asked what we did NOT need before designing."
"Derived the numbers and used them to reject an option."
"Found the bottleneck without being led to it."
"Volunteered failure modes before I asked."
"Changed the design when I raised a constraint, and said why." Weak
"Jumped to a diagram."
"Said 'it scales' without a number."
"Listed technologies without justifying any of them."
"Had no answer for what happens when a node dies."
"Never finished a component -- everything was one level deep." The two most common time failures
1. Fifteen minutes on requirements. You now have thirty minutes
for a forty-minute design.
2. Twenty minutes on the API contract. Nobody is scoring your
REST path naming. What to do with silence
Think out loud. "I'm weighing fan-out on write against on read;
the follower distribution decides it, so let me estimate that."
That sentence is worth more than two minutes of quiet
correctness.