How is a 45-minute system-design interview round usually structured, and how should you budget the time?
answer
- The clock is divided, not spent freely
- Nothing is drawn during the first beat
- Scope, then scale, then structure, then depth
- The final beat is the interviewer's pick
basics
~20 sA 45-minute system-design round runs in four beats: roughly 10 minutes agreeing requirements and scope, 5 on rough scale estimates, 15 sketching the high-level design and its interfaces, and 15 on one deep dive the interviewer picks.
solid answer
~40 sTreat it as four timed beats inside the slot, not one long sketch. Spend about the first **10 minutes** turning the prompt into an agreed requirements list at the top of the shared design canvas: what the system must do, how much load it carries, what is explicitly out of scope. Give about **5 minutes** to rough scale estimates that actually size something. Then about **15 minutes** on the high-level design and the interfaces between the pieces, and the final **15** on one deep dive that the interviewer steers. Say the plan out loud in the first minute so the interviewer knows you have one, and glance at the clock twice: by minute 15 you should be drawing, by minute 30 you should be inside the deep dive.
go deeper
Memorise the four beats and their rough minutes so the shape is automatic. Be ready to say, in one sentence, what you would do in the first ten minutes of such a round and why nothing is drawn yet.
Explain why the order matters, not just what it is - each beat produces the input the next one argues from. Expect to justify how many minutes you would give each beat and what you would sacrifice first when running late.
Show that you manage the clock live: announce the plan, check in at the two-thirds mark, and cut scope deliberately out loud rather than silently rushing. Interviewers score visible time management here as much as the design.
Own the tradeoff between breadth and depth in a fixed slot. Be ready to argue when you would deliberately abandon the standard budget - an unusually ambiguous prompt, or an interviewer who has signalled they only care about one subsystem - and what you give up by doing so.
## The round is a budget, not a canvas A system-design round is a timed exercise, and the person running it - usually an engineer from the team you would join - is scoring how you spend the time at least as much as what ends up drawn. Most interviewers are calibrated against roughly the same four-beat shape, so a candidate who follows it is legible and a candidate who wanders is not. | Beat | Rough budget | What lands on the shared design canvas | |---|---|---| | Scope and requirements | ~10 min | A short list at the top: what the system must do, the load and latency it must hold, and one line naming what you are *not* building | | Rough scale estimates | ~5 min | Two or three numbers written beside the requirement they came from | | High-level design and interfaces | ~15 min | The components, the flow between them, and the small set of operations each exposes | | One deep dive | ~15 min | One component opened up, with the alternative you rejected written next to it | ### The slot is shorter than the slot A 45-minute booking is rarely 45 minutes of design. Introductions and the prompt statement eat three or four minutes, and a good interviewer leaves two or three at the end for your own questions. Plan against roughly **38 usable minutes** and the budget above still fits, because the beats are rough. If the round is 60 minutes, the extra fifteen almost always go to the deep dive rather than to more scoping. ### A worked pass at the clock Take an invented example: a Series C scale-up hiring a senior backend engineer, and the prompt is *design our notification delivery service*. - **Minutes 0-2.** You restate the prompt in one sentence and say how you intend to use the time: scope first, a couple of estimates, then the high level, then whatever the interviewer wants opened up. This costs almost nothing and buys you the right to keep driving later. - **Minutes 2-10.** You write the requirements list at the top of the canvas. Three functional lines (accept a send request, fan out to a channel, report delivery status), three non-functional ones (peak send rate, how late a notification may be before it is useless, whether a duplicate send is tolerable), and one out-of-scope line (no template authoring UI today). - **Minutes 10-15.** Two estimates, each tied to a line above it, each with the assumption said out loud before the arithmetic. - **Minutes 15-30.** The high level. Boxes, the direction of flow, and for each box the two or three operations it offers its neighbours. You narrate as you draw and you point back at requirement lines as you satisfy them. - **Minutes 30-43.** The deep dive. The interviewer points at one component; you open it. ### The failure this shape exists to prevent The single most common way to lose a design round is **drawing boxes and arrows before agreeing requirements or scale**. It feels productive - the canvas fills up fast, and silence is uncomfortable - but every box drawn before the requirements list exists is a box you cannot justify. When the interviewer later asks *why this component*, the honest answer is that it came from a diagram you have seen before, not from anything this problem asked for. Interviewers read that instantly, and the rest of the round becomes them steering you back to questions you skipped. The cheap defence is mechanical: nothing gets drawn until there is a written list above it. The list is not ceremony - it is the thing you argue from for the next half hour. ### Checkpoint discipline Two glances at the clock are enough, and they map to the two ways rounds die. - **At minute 15**, you should be drawing. If you are still asking scoping questions, you have over-invested in the safest beat. Close it explicitly: state the assumptions you are going to run with and move. - **At minute 30**, you should be inside a deep dive. If you are still adding components to the high level, you are about to be cut off with the most heavily weighted beat unscored. When you are behind, say so and cut deliberately rather than speeding up silently. *I have got about twelve minutes left, so I will leave the reporting path at the level it is and spend them on the delivery path* is a strong sentence. Running out of time mid-sentence is not. ### What legitimately varies Some interviewers hand you the requirements instead of making you extract them; some skip estimates entirely; some ask for the interface list before the diagram. Adapt the budget, but keep the order: scope, then scale, then structure, then depth. Reversing it is what the shape is protecting you from.
- How would you tell me, in the first minute, how you plan to use our 45 minutes?One sentence, then move: "I will spend about ten minutes on requirements and scale, sketch the high level for fifteen, and leave the last fifteen for whichever part you want me to open up." It sets the contract, tells the interviewer you have a plan, and earns you the right to keep drawing later without asking permission at every step.
- You are thirty minutes in and still arguing about requirements - what do you do?Close the beat out loud and take the assumptions yourself. Say which two or three open points you are deciding unilaterally, write them on the canvas as assumptions rather than agreed requirements, and start drawing. An interviewer will correct a stated assumption in seconds; they cannot rescue a round with no design in it.
- The round is 60 minutes rather than 45 - what changes in your plan?Mostly the depth beat. Scoping does not get much better with more time, and the high level is a fixed amount of work, so the extra quarter-hour usually buys a second deep dive or a much more thorough first one. Say that split out loud so the interviewer can redirect it if they had something else in mind.
Think of it like a talk with a hard stop rather than an open sketching session. The first slide is never the architecture; it is the agenda everything after it is measured against.
saying these in an interview costs you the question
- Drawing components on the canvas before any requirement is written down
- Spending half the round on scoping questions and never reaching a design
- Treating the whole slot as one undifferentiated sketching session
- Never checking the clock, then being cut off mid-diagram
- Reciting a memorised diagram that no requirement on the canvas asked for