A system design round is a 45-minute meeting with a vague agenda, and you are expected to chair it. This chapter gives you the shape of that meeting minute by minute, what the interviewer is writing down at each step, how to hold the agenda without talking over the person who scores you, how to choose the deep dives that earn the most evidence, and what changes in a Google round. It ends with a complete, timed run of a pastebin design and a set of drills.
This chapter is the plan for the round. The 45-minute plan gives the words for each stage. What loses the round catalogues the failures, with a checklist for your mocks. Senior vs Staff answers shows how the same round sounds at each level.
Why driving is the thing being tested
Two candidates hear "Design a pastebin". Here are their first 90 seconds.
Driver: "Before I draw: who can read a paste, how big can one be,
do they expire? I'll assume 5M pastes a day. Scope, then
numbers, then design. OK?"
Waiter: "Sure. So there's a database... what scale should I use?"
Result: the driver has given the interviewer three things to write
down. The waiter has handed over the plan.
That is the point of the round: the interviewer scores what you produce, and you produce more when you lead.
The prompt is short on purpose. "Design a pastebin" has no user count, no latency target, no budget and no definition of done. In a real planning meeting someone turns that into a problem before anyone draws a box. The interviewer wants to watch you be that person.
Look at it from the other side of the table. The interviewer has 45 minutes to collect evidence on roughly five things: how you navigate an ambiguous problem, the design itself, technical depth, communication, and operational judgement (the five things interviewers score). Every minute you spend waiting for direction, or on something they cannot score, is a minute of missing evidence. A candidate who structures the round produces evidence in every phase. A candidate who is pulled through it produces evidence only where the interviewer thought to ask.
Most designs go wrong in the first five minutes. The failure is starting on boxes and arrows before anyone has agreed what the system must do. A design conversation is a sequence of commitments, and each one narrows the set of designs that are still valid:
"Design a pastebin" every design is still possible
|
requirements create, read, expire; unlisted links; no edits
|
numbers 50 writes/s, 5k reads/s at peak, 50 GB/day
|
API and data POST /pastes, GET /p/{key}; key -> meta, bytes
|
diagram API, metadata store, blob store, edge cache
|
deep dives key unguessability; expiry and deletion
|
wrap-up 3 decisions, 1 risk, what breaks at 10x
A design with a distributed ID service, sixteen database shards and a message queue is a reasonable design for some system. At 50 writes a second the numbers line has already ruled it out, and saying so is part of the answer.
Never add a component without naming the problem it solves. A cache with no measured read pressure is decoration that you will then have to keep consistent.
What driving means. You propose the agenda, move the conversation through it, make the decisions, and keep the interviewer informed enough to steer by exception. Driving is different from talking without pause, and it includes being redirected gracefully; the section on control below is about handing it back at the right moments.
The 45 minutes, phase by phase
Nine phases, each with a budget and an artefact it leaves on the board. No company publishes a minute-by-minute plan; these budgets are ours, set to agree with what the guides report (below). They add up to 45 minutes; the subsection after the exit checks shrinks them to the time you will really have.
- 0–2 min
- Restate and set the plan. One sentence on what the system is for, then the order you will work in and roughly where you expect the deep dives to be. Leaves a title and empty headings: Requirements, Numbers, API, Data, Diagram, Deep dives, Parking lot.
- 2–5 min
- Functional requirements and scope. Three to five core actions written as verbs, who performs them, and an explicit out-of-scope list. Ask only questions whose answers change the design. Leaves an "in" list and an "out" list the interviewer has agreed to.
- 5–7 min
- Non-functional requirements, as numbers. Scale, latency per operation (p99), availability, durability, the consistency each operation needs, and any privacy or compliance rule. Leaves four to six lines, each with a number or a precise rule.
- 7–10 min
- Estimate. Peak rate per operation, bytes per day and per year, bandwidth, and a memory size if the design will depend on one. Each line ends in a "so": the decision the number forces. Leaves the arithmetic and two or three conclusions.
- 10–13 min
- API. The two to four calls behind the core actions, with the fields that carry decisions: idempotency keys, cursors, expiry, visibility. Leaves signatures.
- 13–16 min
- Data model. Entities, primary keys, the partition key and the access pattern it serves, and where large bytes live. Leaves a few schema lines.
- 16–25 min
- High-level diagram and walkthrough. The simplest design that meets the numbers. Trace one write and one read through it out loud, name the commit point, then fix the bottleneck your estimate predicted. Leaves the diagram with numbered steps.
- 25–40 min
- Deep dives. Two, occasionally three, chosen by risk (see below). Each one: the problem with its number, two or three options, a decision with its cost, and how it fails. Leaves decision notes beside the diagram.
- 40–45 min
- Wrap-up. The decisions you would defend, the main risk and how you would detect it, what breaks first at 10×, and time for the interviewer's questions.
These refine the blocks of the clock in The 45-minute plan (scope by 5, numbers by 10, API and data by about 15, wrap-up from 40). One difference is deliberate: the diagram is finished by 25, three minutes before the script's 15–28 block ends, which gives the deep dives fifteen minutes instead of twelve. The guides point the same way. Hello Interview's Google L5 guide advises about five minutes on requirements, and reports that most successful candidates have the major components on the board within the first 20 minutes and spend the rest going deeper where the interviewer shows interest. Google's own systems-design prep video is organised around communication, designing to scale, concrete and quantitative answers, and trade-offs.
Exit checks: when a phase is done
| Phase | Do not leave it until | If you are over budget |
|---|---|---|
| Restate and plan | You have said the order you will work in | It cannot overrun; it is one sentence |
| Functional scope | The interviewer has agreed the in and out lists | Turn the remaining questions into stated assumptions and move |
| Non-functional | Every line has a number or a precise rule | Propose the numbers yourself: "I'll assume 99.9%" |
| Estimate | Every number ends in a decision | Keep only the two numbers that decide something |
| API | Each core action has a call | Write only the create and read calls |
| Data model | The partition key is named and serves the main read | Fold it into the diagram as labels on the stores |
| Diagram | A write and a read have been traced aloud | Trace one path; trace the other when a deep dive needs it |
| Deep dive | A decision has been stated with its cost | Drop the third deep dive, never the decision in the current one |
| Wrap-up | The summary has been said | Say the summary in 30 seconds; skip "what next" |
The time you really have
A "45-minute" round includes introductions at the start and your questions at the end. Plan for 2–4 minutes lost at the start and 3–5 kept at the end, which leaves about 36–40 minutes of design. When the clock shrinks, apply the right-hand column above in this order: API, then data model, then estimate. Never cut the deep dives to zero. They carry the depth evidence and, at Senior and above, much of the level signal.
Google L6 design rounds are usually 60 minutes, according to Hello Interview's L6 guide. Spend the extra 15 minutes on a third deep dive and on operations (rollout, migration, cost), not on longer requirements.
What the interviewer is writing down
While you talk, the interviewer keeps a running record: what you said and drew, the numbers you used, the decisions you made, and every point where they had to prompt you. After the round they turn that record into written feedback with a recommendation. Google's own pages say every candidate is assessed against clear rubrics, the same ones for everyone considered for the role, and that interviewers are expected to give structured, thoughtful feedback. At Google that feedback goes to a hiring committee that never meets you; Atlassian's official page says its committee sees only the interview feedback and your CV. Three consequences:
- If you did not say it, it did not happen. A reason you thought of but did not say cannot be written down.
- Numbers and decisions are the easiest things to quote. Say them in short sentences that survive being quoted: "50 GB a day of bytes against 1 GB of metadata, so they go to separate stores."
- Prompted and unprompted are recorded differently. "Raised expiry unprompted" and "after a prompt, discussed expiry" are different evidence about the same knowledge. Hello Interview's Google guides draw part of the L5/L6 line here: an L5 drills into partitioning, indexing and failure handling when prompted; an L6 is expected to anticipate scale, availability, latency and evolution without much prompting.
The notes below are illustrative; no company publishes its note format.
| Phase | What gets recorded | A note that helps you | A note that hurts you |
|---|---|---|---|
| Restate and plan | Whether you proposed a structure | "Set an agenda in the first minute, named likely deep dives" | "Started drawing boxes at 0:01" |
| Functional scope | The questions asked and the scope decided | "Asked about visibility, size, expiry and edits; cut search and editing; interviewer agreed" | "Did not ask who can read a paste; designed public only" |
| Non-functional | The targets you set | "Read p99 200 ms, 99.9%, no loss after acknowledgement, unlisted links unguessable" | "No latency or availability target" |
| Estimate | The arithmetic and what it decided | "Bytes 50× metadata, so split stores; writes tiny, so no write sharding" | "Computed QPS; never used it" |
| API | The calls and their semantics | "Idempotent create; 404 for expired and missing alike, so existence does not leak" | "Skipped the API" |
| Data model | Keys and partitioning | "Hash-partitioned by paste key; bytes by reference in a blob store" | "One table, no partition key, 10 MB blobs in rows" |
| Diagram | Components, their reasons, the traced paths | "Traced create and read; named the commit point; edge cache for the 5k/s peak" | "Queue, cache and shards added without reasons" |
| Deep dives | Who chose them, how deep, the costs | "Chose keys and expiry as the hard parts; mechanism and cost for each" | "Needed a prompt to consider deletion" |
| Wrap-up | Summary, risks, time | "Summarised three decisions, named abuse as the main risk, finished on time" | "Ran out of time inside the diagram" |
The most expensive line in a Senior candidate's notes is a prompt about a core concern: "Interviewer asked: what happens to expired pastes?" It records that the concern was central, that there was time for it, and that the interviewer still had to raise it. Volunteer the concerns your own numbers point at before anyone asks.
Keeping control, and handing it back
Control comes from four habits, all of them visible to the interviewer:
- A stated agenda in the first minute, naming the deep dives you expect to reach. The interviewer sees the whole plan and can amend it at minute one instead of minute 30. The worked run below shows the wording.
- Visible structure. Headings on the board, so both of you can point at where you are.
- Announced timeboxes. "Two minutes on the API, then the diagram." A box said out loud is easy for you to keep and easy for the interviewer to extend.
- A parking lot. When a side topic comes up, write one line in a corner and say when you will come back to it. Nothing is lost and nothing derails the current phase.
Handing control back is the other half. The interviewer needs evidence on particular things, and their questions point at those things. Hand back at these moments:
- At every phase boundary, with a checkpoint question (next section).
- On product decisions that belong to the business: "Should unlisted pastes expire by default?" Propose a default, then ask.
- When choosing deep dives: offer your pick and one alternative.
- Whenever the interviewer asks anything. Answer it first, then return to your plan, or drop the plan if the question shows it is wrong.
- After about three minutes of continuous talking.
Hand back with a recommendation attached. "I'd go deep on expiry next, because that's where the storage cost is, or we could take the hot-paste read path; which is more useful to you?" keeps you in the chair. "What would you like me to do next?" gives the chair away.
| Situation | Keep control by | Hand back by |
|---|---|---|
| The interviewer has said nothing for ten minutes | Keep checkpointing; silence is not agreement | "Is this the level of detail you want, or should I move faster?" |
| A narrow question in the middle of the diagram | Answer in one to three sentences, park anything bigger | "Does that cover it, or do you want it in depth now?" |
| A redirect to a new area | Follow at once; park your thread in one line | "Switching. I'll note that expiry is still open." |
| You disagree with the interviewer | Give your reason and its cost, once | "If X matters more than Y for this product, I'd switch. Which is it?" |
| A hint: "what about very popular pastes?" | Treat it as a new requirement and address it fully | "So the risk is a hot key. Here's how the design handles it..." |
| You are behind the clock | Announce the cut before making it | "I'll skip the full API and come back to it if there's time. OK?" |
Signs you have lost the chair
The interviewer asks "what's next?". They choose every deep dive. You are answering a run of questions with no plan behind them. You have been on one component for fifteen minutes and cannot say why.
Signs you are gripping it too hard
You have said "let me just finish this" twice. The interviewer has tried to interject on the same topic more than once. You have not asked a question in eight minutes. You went straight back to your plan after a hint.