System Design Interviews: A Minute-by-Minute Guide to the Hour

A system design interview is 45 to 60 minutes of turning a vague prompt into a defensible design out loud, and it follows the same arc almost everywhere: scope the problem, estimate the load, sketch one design end to end, go deep where the interviewer pushes, and close on trade-offs. Nobody is checking whether you know what a message queue is. They are checking whether you can drive that arc while saying why, which is why a mock interview is the preparation that transfers and reading architecture write-ups is not.

The shape of the hour

Almost every system design round follows the same arc. Knowing the arc is worth more than knowing any particular technology, because it tells you where you are and what is expected next.

The last row is where senior candidates separate from mid-level ones. A design with no stated weakness reads as a design nobody has thought hard about. Saying "this falls over if writes become hot on a single key, and here is what I would do then" is the single most senior thing available to you in that hour.

The numbers you should not have to look up

You do not need precision. You need the right order of magnitude, instantly, so the estimate takes ninety seconds rather than derailing the interview. The requirements and estimation guide works one estimate through end to end.

Six rows. With those, "a million users posting twice a day" becomes about twenty writes a second and about two gigabytes a day, so well under a terabyte a year, out loud and without a calculator. Every later choice then has a number behind it.

"Premature optimization is the root of all evil."
- Donald Knuth, Structured Programming with go to Statements (1974)

Knuth's line is quoted constantly and applied rarely. In this round it means: do not shard on slide one. Reach a working single-region design first, then let the interviewer's pressure pull you toward scale. Candidates who open with sharding and multi-region replication signal that they have memorized an architecture rather than reasoned to one. When the pressure does come, the sharding and replication guide covers what to say.

Where interviewers actually probe

• The data model and the storage choice. It is the part of a design that is hardest to change later, so expect "why that database?" and "what does this table look like?" early.
• What breaks under load. The hot key, the single database, the queue that backs up. Name it before you are asked.
• Consistency. Which reads may be slightly stale, and what the user sees when they are.
• Failure and recovery. What happens when a dependency is down, and how the system catches up afterwards.
• Specific technology names matter least. Memorizing which database a company runs is time spent on what the follow-up questions almost never test: they ask about your reasoning, not their stack.

How to actually practice this

Reading a design write-up is to this round what reading a recipe is to cooking. The only practice that transfers is producing a design out loud, under interruption, with someone asking why.

Three rules for a useful session. Speak continuously, even while drawing, because silence is where the assessment stops. Commit to a design early and refine it rather than surveying options for forty minutes. And volunteer one weakness before you are asked for it.

Rehearse the data model on its own as well, because it is the part of a design that is hardest to change later. The guide to choosing and modeling a database works one schema from access patterns to indexes, and backend engineer interview prep covers the idempotency and concurrency questions senior rounds add.

The sentence worth rehearsing

If you prepare one thing, prepare this: "Here is the trade-off I am making, here is what it costs, and here is when I would revisit it." Say it three or four times in the hour, about real choices in your own design.

That sentence is what the round is looking for. Everything else, the estimates, the diagrams and the technology names, exists to give you something true to put inside it. How to explain trade-offs in a system design interview works through six common ones, and the clarifying questions to ask first covers the scoping that the sentence depends on.

Frequently asked questions