Engineering Atlas › System Design Interviews

A time plan for a 45-minute design round

15 min read · last reviewed 2026-10-17

Open in the interactive app: practice, quiz, mock interview →

In one minute

How it works

Why a framework at all

Without one, candidates drift: ten minutes of requirements, a diagram that grows without a reason, and no time for the deep dive that would have shown depth. A framework turns 45 minutes into a sequence of short phases, each with an exit condition, so you always know what to do next and when you are behind. A predictable structure also makes your evidence easy to find for an interviewer filling in a rubric. What is System Design? introduces the general method; this is its timed, interview-room version, with Estimation Cheatsheet and Diagramming Tips covering two of the phases in depth.

Published frameworks agree on the order and differ on the minutes. Hello Interview budgets about 5 minutes for requirements, 2 for core entities, 5 for the API, 10 to 15 for the high-level design and about 10 for deep dives, and makes capacity estimation optional unless it changes the design (Hello Interview). The System Design Primer uses four steps: use cases and constraints, high-level design, core components, then scaling (system-design-primer). Google's non-abstract design method, which is how its SREs run real reviews, asks four questions in turn: is it possible, can we do better, is it feasible, is it resilient (SRE Workbook, ch. 12). The budget below is one reasonable split; what matters is that you choose one and check it.

The phases and their exits

  1. Requirements (about 5 minutes). List 3 to 5 functional requirements as user actions and say what is out of scope. Then list non-functional requirements as numbers or rules: scale, latency target, availability, consistency per operation, durability, and anything regulatory. Exit when the interviewer agrees with the list. Write the non-functional list where it will stay visible.
  2. Estimation (2 to 4 minutes). Only the numbers that change the design: peak read and write QPS, storage growth, maybe bandwidth. Exit with one sentence of consequence: "about 12k writes per second at peak, so one primary is borderline and I'll plan to partition by user."
  3. API (3 to 5 minutes). The four to six calls that serve the functional requirements, with key parameters and the response shape. Mark which calls are hot and which must be idempotent. Exit when every functional requirement maps to a call.
  4. Data model (3 to 5 minutes). Entities (some frameworks list the core entities before the API, which also works), primary keys, the one or two indexes the hot queries need, and the partition key with its reason. Exit when every hot API call maps to a single-partition read or write, or you have said why it cannot.
  5. High-level design (about 8 minutes). Draw the request path for the main write and the main read, left to right. Walk one request through it. Exit when the design satisfies every functional requirement, even if not yet at scale.
  6. Deep dives (about 15 minutes). Pick two or three parts where the non-functional ledger is still open or where the problem is unusual. For each, name options, choose, give the cost and the failure mode. Exit each one by ticking a ledger entry.
  7. Wrap-up (about 3 minutes). Read the ledger back, name the biggest remaining risk, and say what you would build first and what you would monitor.

Steering and recovery

Interviewers interrupt on purpose. If they jump to a deep dive during the high-level design, go there, then say "I'll park the notification path and come back to it". Keep a short parked list next to the ledger. If you are behind at the 20-minute mark with no high-level diagram, compress: skip the remaining data-model detail, draw the simplest end-to-end path, and say what you skipped. A complete, simple design with one strong deep dive scores better than a beautiful API and no system.

What changes with level

Mid-level candidates are expected to reach a working high-level design and handle one deep dive with prompting; failing to deliver a working system at all is the most common reason they fail, and it usually shows up as poor time management (Hello Interview). Senior candidates drive the whole sequence, move through the basics quickly and pick the deep dives themselves (Hello Interview course). Staff candidates do that quickly, spend most of the time on the hard parts, tie each choice to a requirement and its cost, and talk about rollout, operations and how the design evolves.

Common mistakes

Down the stack

Layer 1The contract

The interview has an implicit contract with a rubric. Most large companies score a handful of dimensions. The names vary, but they cluster around problem navigation, solution design, technical excellence, and communication and collaboration (Hello Interview course). Each phase of the framework produces evidence for one or more of them: requirements and estimation show navigation, the high-level design shows solution design, deep dives show depth, and the ledger and wrap-up show communication and judgement. The contract you offer the interviewer is: "by the end, every requirement on this board will either be met by something on the diagram or named as a known gap". That sentence is testable, and an answer that keeps it reads as organised even when the design is imperfect.

Layer 2The mechanism

Run the interview as a small state machine. Each phase is a state with an entry action (say what you are about to do and roughly how long it takes) and an exit condition (the artifact exists and the interviewer has not objected). Transitions are forward by default, with two exceptions: an interviewer redirect pushes the current phase onto the parked list, and a new requirement discovered later sends you back to phase 1 briefly to add it to the ledger. Two data structures carry state across phases. The ledger is the list of non-functional requirements, each with a status: open, addressed by a named component, or accepted as a gap. The parked list holds topics you deferred. At each phase boundary, glance at the clock and the ledger: if open entries outnumber the deep-dive minutes you have left divided by five, pick the riskiest and say the rest will be named in the wrap-up.

Layer 3The machine

The hardware here is human. Conversational English runs at roughly 150 to 200 words per minute; a study of the Switchboard telephone corpus measured about 164 words per minute within a speaker's turns and 196 over elapsed time (Language Log). Even at the low end, 40 working minutes is about 6,000 spoken words, roughly a short book chapter, and every minute of rambling is 150 or more words of evidence you did not produce. Working memory holds about four chunks at once (Cowan, 2001), for you and for the interviewer, which is why the ledger and parked list belong on the board rather than in your head, and why a diagram with eight boxes is easier to follow than one with twenty. Interviewers type notes while you talk, often a few seconds behind; pausing after a decision ("so the feed is fan-out on write, except for accounts over 100k followers") gives them time to record it. Remote whiteboards are slower to draw on than paper, so keep diagrams to labelled boxes and arrows and spend the saved time talking.

Why it's built this way

Interviews are short and design space is large, so time is the binding constraint and needs an explicit budget. Later phases depend on earlier artifacts, so the order follows dependencies: numbers before stores, API before schema, a working path before optimisation. Depth is what separates levels, so the largest single block of time goes to deep dives. Humans forget, so the state lives on the board. And interviewers probe deliberately, so the framework has a defined way to be interrupted without losing its place.

Diagram

stateDiagram-v2
    [*] --> Requirements
    Requirements --> Estimation: NFR ledger written
    Estimation --> API: numbers with a consequence
    API --> DataModel: every feature has a call
    DataModel --> HighLevel: hot calls map to keys
    HighLevel --> DeepDives: read and write paths work
    DeepDives --> DeepDives: close a ledger entry
    DeepDives --> WrapUp: time or ledger done
    HighLevel --> DeepDives: interviewer redirect
    DeepDives --> Requirements: new requirement found
    WrapUp --> [*]

Worked example

The prompt is "Design a URL shortener". Here is a 45-minute run with clock checks.

  1. 0:00 to 5:00, requirements. Functional: create a short link, redirect, optional custom alias, optional expiry. Out of scope: analytics dashboards, user accounts. Ledger: 100 million new links a month; redirects p99 under 50 ms; redirects available even if link creation is down; a short code never maps to two URLs; links kept 5 years.
  2. 5:00 to 8:00, estimation. About 40 writes per second on average; at a 100 to 1 read ratio, about 4,000 redirects per second, perhaps 20,000 at peak. Six billion links over 5 years at about 500 bytes is 3 TB. Consequence: reads dominate and fit a cache; the data fits a few nodes, so partitioning is for availability more than size.
  3. 8:00 to 12:00, API. POST /links {url, alias?, expires_at?} -> {code} (idempotent by a client key), GET /{code} -> 301 or 302, DELETE /links/{code}.
  4. 12:00 to 15:00, data model. links(code PK, url, created_at, expires_at), partitioned by code. Every redirect is a single-key read.
  5. 15:00 to 23:00, high level. Load balancer, stateless redirect service, Redis, key-value store, a separate write service with a code generator. Walk a create and a redirect.
  6. 23:00 to 40:00, deep dives. Collision-free codes (a counter range per writer, base 62) closes "never two URLs per code". Redirect availability (cache, replicas, isolated write path) closes the availability entry.
  7. 40:00 to 43:00, wrap-up. All entries closed except expiry cleanup, accepted as a background job. Biggest risk: malicious URLs, which need scanning before activation.

If at 23:00 the diagram is not done, the second deep dive shrinks to a sentence.

In the wild

Trade-offs

ApproachStrengthsWeaknessesChoose when
Fixed phase order with timeboxesPredictable, hard to get lost, easy to gradeCan feel mechanical; may spend time on phases the interviewer does not care aboutDefault for most interviews
Requirements then straight to high level, API and schema inlineFaster to a working designAccess patterns can be missed; schema decided implicitlyProblems where the API is obvious (URL shortener, rate limiter)
Interviewer-ledMatches their interests exactlyCedes control; passive candidates score lower on navigationWhen the interviewer clearly drives; still state your plan

Pitfalls in production

The same framework runs design reviews at work, with the same failure modes.

Leadership lens

Check yourself

  1. At minute 22 you have requirements, estimates, a detailed API and schema, and no diagram. What do you do?

    Show answer

    Say you are moving on, draw the simplest end-to-end path for the main read and write in a few minutes, and pick a single deep dive. A complete simple design beats a detailed fragment.

  2. Why keep non-functional requirements visible as a ledger rather than just mention them at the start?

    Show answer

    Deep dives need a target. The ledger tells you which ones to pick, gives each a clear finish, and lets the wrap-up show which requirements are met and which are accepted gaps.

  3. The interviewer interrupts the high-level design to ask how you prevent double booking. What happens to your plan?

    Show answer

    Go to that deep dive now, park the unfinished part of the diagram, and return to it afterwards if time allows. The redirect is a signal of what they want to score.

Sources and further study

Primary

Systems docs

Books

Other curricula

Watch

Free resources

Open in the interactive app: practice, quiz, mock interview →