How system design interviews work

By the Mockich team · Updated October 31, 2026 · 12 sources

A system design interview usually lasts 45 to 60 minutes and moves through the same steps: clarify the requirements, sketch the API and data, draw a simple design that works end to end, go deep on two or three parts, then close with bottlenecks and improvements. The most common way to fail, according to the prep guides we read, is running out of time without one coherent design.

Key points

Spend about five minutes on requirements before drawing anything. The prompt is vague on purpose.
Get a simple end-to-end design on the board first, then go deep. Going deep too early is the classic time sink.
Decide. Naming three options without choosing one is reported as a failure in its own right.
Expect the interviewer to change the problem: more load, a failed dependency, a new requirement.
Level moves the bar, not the topics: senior candidates are expected to drive and to put numbers on the requirements.

The usual shape of the round

Guides written by former interviewers describe almost the same sequence. The times below assume about 45 minutes of design after introductions; real rounds stretch or shrink each step.

Step	Typical time	What happens
Requirements and scope	About 5 min	What users can do, three to five qualities that matter (latency, availability, scale), and what is out of scope.
Estimation	1 to 3 min, or later	Only the numbers that change a decision, such as whether data fits on one machine or the read to write ratio.
Entities and API	5 to 7 min	The main objects and the interface the outside world calls. Schema detail only where it matters.
High-level design	10 to 15 min	A simple design that meets the functional requirements, walked through request by request.
Deep dives	10 to 25 min	Two or three parts hardened against the requirements: caching, partitioning, consistency, the hard part of this problem.
Wrap-up	About 5 min	Bottlenecks, what you would improve next, and a short recap.

Sources: [1], [2], [5], [6], [7]

What interviewers look for

No company publishes its system design rubric. Across the guides, the same signals come up again and again:

Framing: targeted questions instead of assumptions, and requirements with numbers where it counts.
A complete design delivered in time, even if simple.
Trade-offs: alternatives weighed against the requirements, then a decision with a reason.
Depth: how a chosen component actually works in this design, not just its name.
Scale and failure: bottlenecks, retries, degraded modes, and at senior level monitoring and rollout.
Collaboration: thinking out loud, checking in, and using the interviewer’s hints.
Honesty about limits: saying what you do not know and reasoning from first principles.

Sources: [1], [2], [3], [4], [7], [9]

The mistakes guides report most

Skipping or rushing the requirements and designing on assumptions.
Going deep on one component early, then running out of time with no complete design.
Listing options without choosing one.
Adding complexity the requirements do not need.
Waiting for the interviewer to lead, or designing in silence.
Ignoring a hint or arguing against feedback instead of using it.
Name-dropping a technology without explaining how it works here.
Leaving out failure handling and operations.

Sources: [2], [4], [6], [7], [8]

How the interviewer behaves

Clarifying questions get a direct answer, or a request to state an assumption and move on. When you are visibly stuck and say so, a small hint is common; skipping the question takes that chance away. Interviewers steer toward the parts where they still need signal, and they add constraints along the way: a worker crash or duplicate messages for mid-level candidates, a dependency failure, a strict latency target or a migration for senior ones.

A challenge is a probe, not a verdict. Holding your position with reasons is fine; ignoring the feedback is not.

Sources: [2], [3], [4], [6]

How the bar changes with level

The guides agree that the topics stay the same while the expectations rise, and that the jump from mid-level to senior is the largest.

	Mid-level	Senior and above
Who drives	The interviewer may structure the round and point at weak spots	You set the agenda and pick the deep dives
Requirements	Clarify the missing functional details	Turn a vague ask into workload numbers and service targets
Depth	A coherent API, data model and core flow	Bottlenecks, consistency, capacity and failure containment on the hard part
Operations	The basics	Monitoring that catches user harm, alerts, phased rollout, migration and ownership

Sources: [1], [3], [4]

ML system design and data science design rounds

ML system design keeps the same opening but replaces storage and sharding with ML questions: is ML needed at all, which metric defines success, where the data and labels come from, which features and model, how it is served, how it is evaluated offline and online, and how drift is caught after launch.

Data science design rounds are a different conversation: define the goal and a primary metric with guardrails, design the experiment (unit, duration, power and pitfalls), or work out why a metric moved. There is little or no architecture.

Sources: [10], [11], [12]

Go deeper on this round

Practise the round out loud

Mockich runs this round with the same steps: requirements, high-level design, a deep dive, scale and failures, and a wrap-up, on a shared whiteboard Vera can read. You get a report that scores each skill and quotes your reasoning.

Start a free mock interview How the practice round runs Read a sample report

Sources

We read these public prep guides on 2026-10-30 and summarised where they agree, in our own words. They describe typical practice reported by former interviewers; no company publishes its internal rubric, and formats vary between companies.

[1] Hello Interview, Delivery Framework (System Design in a Hurry)
[2] interviewing.io, A Senior Engineer’s Guide to the System Design Interview
[3] PracHub, System Design Interview Rubric by Level
[4] Hello Interview, 5 Keys to Staff-Level System Design Interviews
[5] Hello Interview, Mastering Estimation
[6] ByteByteGo, A Framework for System Design Interviews
[7] Grokking Tech Career, 3 reasons great developers still fail System Design Interviews
[8] GeeksforGeeks, Common Mistakes to Avoid in a System Design Interview
[9] Design Gurus, Scripts for Navigating Tough System Design Questions
[10] IGotAnOffer, ML System Design Interview
[11] Hello Interview, ML System Design in a Hurry: Introduction
[12] bookdown.org, Metrics and problem solving (Product Data Science Interview)