What interviewers look for in a system design round

14 min read · last reviewed 2026-10-17

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

In one minute

A system design interview is a 45 to 60 minute conversation (interviewing.io) in which you design a large system from a vague prompt ("design a URL shortener", "design a rate limiter") while the interviewer probes your reasoning. There is no single right answer; there are defensible and indefensible ones.
The interviewer is not grading the final diagram. They are collecting evidence on a rubric: did you scope the problem, size it, choose components for stated reasons, find the hard parts, and reason about failure and trade-offs?
Time is the scarcest resource. In a 45-minute slot you may get only about 35 minutes of actual design once introductions and questions are done (Hello Interview). Most weak performances are not wrong designs but unfinished ones: 25 minutes on requirements, or a deep dive into a cache before the read path exists.
The same session also decides your level. A mid-level answer that works and a staff-level answer that works differ in how much of the conversation the candidate drives and how far down the stack they can go when pushed.
This chapter orients you. The rest of the course goes deep: Types of System Design Questions, Expectations by Level/YoE, the answering framework, Estimation Cheatsheet, Diagramming Tips, Tradeoffs, and some 30 full "Design X" walkthroughs such as Design Pastebin and Design Rate Limiter.

How it works

Why companies run them

Coding interviews say little about whether you can decide what to build when requirements are fuzzy, load is unknown and every option has a cost. That judgement is most of the job above entry level, and a poor partition key or consistency model can cost a team a year. The system design interview is a cheap, imperfect simulation of a design review, compressed into one hour with one reviewer.

The shape of a session

Almost every format follows the same arc, whatever the company calls it. The open curricula agree on the skeleton: the System Design Primer uses four steps (use cases and constraints, high-level design, core components, scaling) (System Design Primer), and Hello Interview budgets about 5 minutes for requirements, 10 to 15 for the high-level design and about 10 for deep dives (Hello Interview).

Prompt. One sentence, deliberately underspecified. The ambiguity is the test: a candidate who starts drawing immediately has skipped the part that matters.
Requirements. You agree the functional scope (three to five core features) and the non-functional targets (scale, latency, availability, consistency). You also say what is out of scope.
Estimation. Enough arithmetic to make decisions: requests per second, storage growth, bandwidth, and the read to write ratio. The Estimation Cheatsheet covers the numbers.
Interface. The main API calls or events, which pin down what the system actually does.
High-level design. A diagram of clients, services, stores and queues, with one walk through the write path and one through the read path. Diagramming Tips covers how to draw it.
Deep dives. Two or three hard parts, chosen by you or by the interviewer: the hot key, the fan-out, the exactly-once payment, the region failover.
Wrap-up. Bottlenecks, failure modes, what you would build first, and what you would change at ten times the load.

What the interviewer is doing

While you talk, the interviewer takes notes against a rubric of four to six dimensions such as scoping, high-level design, technical depth, trade-offs and communication. Hello Interview's version has four: problem navigation, solution design, technical excellence, and communication and collaboration, and notes that companies use different words for the same things (Hello Interview). Some questions are hints in disguise: "how many writes per second is that?" usually means your design will not hold at that rate. Afterwards they write feedback with concrete quotes for a debrief or hiring committee. Their job is to produce evidence, so yours is to make your reasoning visible.

Variations and what it is not

Prompts split into product designs ("design Instagram"), which reward scoping and data modelling, and infrastructure designs ("design a distributed cache"), which reward internals and failure handling; Types of System Design Questions classifies them. Most entry-level roles have no system design round at all (Hello Interview). Mid-level loops are often interviewer-led; senior loops expect you to direct more of the session (interviewing.io). Some companies also split the round by role: Meta's Product Architecture interview is the system design round for product engineers and asks for user-facing products rather than, say, a load balancer (Hello Interview). It is not a trivia test: "use Kafka" earns nothing, while "an append-only partitioned log, so consumers can replay" earns a lot. Nor is it a test of memorised designs; interviewers twist familiar prompts ("now some links get 100,000 hits per second") to separate reasoning from recall.

Down the stack

Layer 1The contract

The human process is a structured interview. Google's re:Work guide names its four parts: vetted role-relevant questions, recorded feedback, standardised rubrics, and interviewer training and calibration, and reports that structured interviews predicted job performance better than unstructured ones in Google's own data (re:Work). The contract between candidate and company is that every candidate for a role gets a comparable prompt, is scored on the same named dimensions, and is judged on evidence written down during the session rather than on a gut feeling afterwards. Concretely, a hire signal on "technical depth" should be traceable to something you said, such as "they explained why a write-through cache doubles write latency and chose cache-aside instead". That is why silence hurts: an interviewer cannot record a thought you did not say aloud. It is also why a single strong deep dive can carry a session while a long, shallow tour of every component cannot.

Layer 2The mechanism

Underneath the rubric, the technical content follows a dependency chain, and each artefact unlocks the next. Requirements fix which operations exist. Estimates turn them into rates: 100 million daily users posting twice a day is about 2,300 writes per second on average. Rates plus the read to write ratio choose the shape: at 100 reads per write you design the read path first, with caching or precomputation. The API fixes the access patterns, which fix the data model and the partition key. Data model plus rates expose the hard parts: a post fanned out to 50 million followers, a counter hit 10,000 times a second, one inventory row everyone wants. Deep dives resolve those with named mechanisms such as consistent hashing, an idempotency key or a lease. Skip a link and the answer feels unanchored.

Layer 3The machine

A strong candidate can check a design against the hardware in their head. Memory access is about 100 ns and a random SSD read about 100 us (Napkin Math). The classic table puts a round trip inside a data centre at 0.5 ms, but those figures date from about 2012 (latency numbers); a 2026 re-measurement on cloud VMs gives about 100 us within a zone and 250 us within a region, with region-to-region round trips of 25 to 180 ms (Napkin Math). Treat 0.1 to 0.5 ms as the in-region range. A day has 86,400 seconds, so one million events a day is roughly 12 per second. A single well-tuned Postgres primary handles thousands to low tens of thousands of simple writes per second; a single Redis instance, which executes commands on one thread, does on the order of 100,000 simple operations per second without pipelining and far more with it (Redis docs). A 10 Gbit/s NIC moves about 1.25 GB per second. These numbers turn opinions into checks: "a 1 KB write at 50,000 per second is 50 MB/s, one disk can absorb that, but one Postgres primary probably cannot commit that many transactions, so we batch or shard." Most interviewers will not ask for the numbers directly. They notice whether your choices are consistent with them.

Why it's built this way

Design ability cannot be observed by watching someone build a real system, because that takes months, so companies compress it into an hour. An hour is too short to finish a real design, so the interview grades the process, not the output. Process is invisible unless spoken, so the format rewards narrating your reasoning. Interviewers are human and inconsistent, so companies add rubrics, written evidence and committees to reduce variance. And because seniority shows up mainly in judgement under ambiguity, the same open-ended format is used to decide your level as well as your hire.

Diagram

flowchart LR
    P["Vague prompt"] --> R["Requirements and scope"]
    R --> E["Estimates: QPS, storage"]
    E --> A["API and data model"]
    A --> H["High-level design"]
    H --> D["Deep dives: 2 or 3 hard parts"]
    D --> W["Wrap-up: failures, evolution"]
    R -.-> N["Interviewer notes vs rubric"]
    H -.-> N
    D -.-> N
    W -.-> N
    N --> C["Debrief: hire and level"]

Worked example

Here is a 45-minute plan for "design a URL shortener", with what the interviewer can write down at each stage.

Minutes 0 to 5, requirements. You settle on create, redirect and optional expiry, with click counts as a stretch goal and user accounts out of scope; redirects under 50 ms at p99. Evidence logged: "scoped before designing".

Minutes 5 to 8, estimates. 100 million new links a month is about 40 writes per second. At 100 reads per write, that is 4,000 redirects per second on average and perhaps 20,000 at peak. At 500 bytes a record that is 50 GB a month. Said aloud: "reads dominate and the hot set fits in memory, so the redirect path is a cache lookup." Evidence: "used numbers to drive a decision".

Minutes 8 to 12, API and data. POST /links {url, ttl} returns a code; GET /{code} returns a 301 or 302. The table is code -> (url, expires_at, owner), partitioned by code.

Minutes 12 to 24, high-level design: load balancer, stateless link service, key-value store, Redis cache, and an ID allocator handing out ranges.

Minutes 24 to 41, deep dives: base62 counters versus hashing (7 characters give 3.5 trillion codes), an in-process cache for a link at 100,000 requests per second, and 301 versus 302 (browser caching versus click counts).

Minutes 41 to 45, wrap-up: what fails first at ten times the load (the cache tier's network), and the build order. A candidate who finishes this arc with three real deep dives is in hire territory at most levels; how deep each dive went decides which level.

In the wild

Niantic and Google Cloud, 2016: Pokémon GO launches at 50 times its estimate. Niantic planned for 1x traffic with 5x as the worst case; real traffic, measured on Cloud Datastore, reached 50x. Google engineers added tens of thousands of cores, and before the Japan launch the team upgraded GKE to allow over 1,000 more nodes and moved to the HTTP/S load balancer, after which Japan launched cleanly. It is the estimation phase of the interview at production scale: the number you plan for decides what breaks (Google Cloud).
Amazon Prime Video, 2023: the default architecture failed at 5% of expected load. A stream-quality monitor built from Step Functions, Lambda and S3 hit account limits on state transitions at about 5% of its target, and passing frames through S3 was expensive. Rebuilding the same components as one process on ECS cut infrastructure cost by over 90%. Interviewers reward this kind of reasoning from the workload's numbers rather than from a fashionable default (Prime Video Tech, archived).

Trade-offs

Approach in the room	Strengths	Weaknesses	Choose when
Breadth first, then depth	Never leaves a gap; shows structure	Risks shallow deep dives if slow	Default for every prompt
Depth early on the known hard part	Shows expertise fast	Unfinished design if it runs long	The prompt is obviously about one mechanism (rate limiter)
Interviewer-led, answer questions	Low risk of drifting	Weak signal on ownership and leadership	Junior loops, or when the interviewer clearly has a script
Candidate-led, check in often	Strong senior signal	Can miss what the interviewer wanted to see	Senior and staff loops

Pitfalls in production

The interview mirrors real design reviews, and the same failures show up in both:

Designing before scoping. In interviews this wastes time; at work it ships the wrong system. Fix: write three to five requirements and the non-goals before any box.
Numbers that never get used. Candidates compute 20,000 QPS and then draw a single database anyway. Fix: after every estimate, say the decision it forces.
No failure story. Designs that only describe the happy path fail both interviews and on-call. Fix: for each stateful box, say how it replicates and what the user sees when it is down.
Running out of time. The most common failure. Fix: budget the 45 minutes up front and check the clock at the end of each phase, which is exactly what this chapter's practice task builds.

Leadership lens

If you run interviews, write the rubric before the loop and calibrate interviewers on recorded or mock sessions; untrained interviewers grade confidence, not reasoning.
Pick prompts that resemble your real system's hard problems, but not your actual architecture, or candidates who happen to know it get an unfair edge.
Ask interviewers to log evidence as quotes, not adjectives. "Explained why fan-out on write fails for 50 million followers" is useful to a committee; "strong" is not.

Check yourself

Why can a candidate with a correct final diagram still get a no-hire?
Show answer
The interviewer grades evidence of reasoning on a rubric. If the diagram was not justified by requirements and numbers, and no hard part was explored in depth, there is little evidence to record for scoping, depth or trade-offs.
Why do estimates come before the high-level design?
Show answer
Rates and sizes decide the shape of the design, such as whether reads need a cache, whether one database is enough, or whether you need sharding. Without them component choices are arbitrary.
An interviewer asks "what happens when this cache node dies?" during your high-level design. What is going on?
Show answer
Usually a hint that they want a deep dive on availability or that your design has a single point of failure; answer briefly with the failure behaviour and mitigation, then offer to go deeper.
Why is saying "use Kafka" without a reason weak?
Show answer
It names a product without the property you need, so it gives no evidence that you understand why a partitioned log fits; the interviewer cannot tell recall from reasoning.

Sources and further study

Primary

A guide to structured interviewing (Google re:Work): the four parts of a structured interview and Google's evidence that it predicts performance better.
Napkin Math (Simon Eskildsen): latency and throughput numbers re-measured on current cloud hardware, a useful update to the 2012 table.

Systems docs

Redis benchmark (Redis docs): what one Redis instance does with and without pipelining, and why it is mostly single-threaded.

Books

System Design Interview – An Insider's Guide, Volume 1, Alex Xu, chapter 3 "A Framework For System Design Interviews": a four-step framework with a time budget for each step.
System Design Interview – An Insider's Guide, Volume 1, Alex Xu, chapter 2 "Back-of-the-envelope Estimation": the arithmetic behind the estimation phase.
Seeking SRE, ed. David Blank-Edelman, chapter 2 "Interviewing Site Reliability Engineers": how an interview loop is designed from the hiring side.

Other curricula

System Design Delivery Framework (Hello Interview): six steps with minute budgets, putting core entities before the API and leaving data flow optional.
How to prepare for Meta's Product Architecture interview (Hello Interview): frames the round as user-facing product design, with about 35 working minutes.
The System Design Interview: What is Expected at Each Level (Hello Interview): frames the same session along breadth, depth and proactiveness, with the weight shifting as the level rises.

Watch

System Design Interview: A Step-By-Step Guide (ByteByteGo): the phases of a session and what to produce in each.
Google Systems Design Interview With An Ex-Googler (Clément Mihailescu): a full mock session, useful for watching pacing and how the interviewer probes.

Free resources

System Design in a Hurry: Introduction (Hello Interview): a concise overview of interview formats and what is assessed.
System Design Interview Guide for Senior Engineers (interviewing.io): long-form guide written from the interviewer's side of the table.
The System Design Primer: a widely used open study guide with topic summaries and sample designs.
Use structured interviewing (Google re:Work): why companies use rubrics and consistent questions.
Latency numbers every programmer should know: the classic table behind the Layer 3 checks.

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