What Is the System Design Interview

A system design interview is a discussion, usually 45 to 60 minutes, in which the candidate designs the architecture of a software system from an under-specified prompt such as "design a URL shortener" or "design a chat service". There is no single correct answer. The interviewer evaluates how the candidate turns vague requirements into a concrete design, justifies choices, and reasons about failure and scale.

What the interview evaluates

The round measures engineering judgment at the level of whole systems rather than functions or classes. Interviewers typically look for:

Problem scoping. Asking questions that turn an ambiguous prompt into a bounded set of requirements.
Technical breadth. Knowing the standard building blocks: load balancers, caches, databases, queues, search indexes, object stores.
Technical depth. Explaining how at least a few of those components work internally, for example how a leader-follower database replicates writes, or how a cache evicts entries.
Trade-off reasoning. Choosing between options and stating what is given up. A design that lists components without reasons for choosing them is incomplete.
Quantitative sense. Estimating traffic, storage, and bandwidth to decide whether one machine suffices or data must be partitioned.
Communication. Presenting a structured design, checking assumptions, and responding to feedback.

Common formats

Format	Description	Typical emphasis
Whiteboard or shared drawing tool	Candidate draws boxes and arrows while talking.	Architecture diagram, data flow.
Discussion only	Conversation with little or no drawing.	Verbal structure and precision.
Take-home or written design	A design document is produced in advance and discussed.	Written clarity, completeness.
Domain-specific	Prompt tied to the employer's domain (payments, ads, streaming).	Domain constraints, correctness.
Deep dive on past work	Candidate explains an existing system they built.	Ownership, decisions, lessons.

Many interviews are 45 minutes. The candidate is expected to lead. The interviewer answers questions, adds constraints, and steers toward areas of interest.

How it differs from a coding round

Aspect	Coding interview	System design interview
Problem statement	Precise, with inputs and outputs.	Deliberately vague.
Correct answer	Usually one optimal complexity class.	Several valid designs.
Output	Working code.	Diagram, API, data model, reasoning.
Evaluation focus	Algorithms, data structures, correctness.	Trade-offs, scale, failure handling.
Who drives	Interviewer sets the problem, candidate implements.	Candidate drives, interviewer probes.
Scope of a change	One function or class.	Many services and data stores.

The two rounds overlap where a data structure appears inside a system, for example a Bloom filter in a crawler or a trie in autocomplete.

Scoring dimensions

Rubrics differ between companies, but most map to the following dimensions.

graph TD
    A["Interview signal"] --> B["Requirements and scoping"]
    A --> C["High-level design"]
    A --> D["Depth in critical components"]
    A --> E["Trade-offs and justification"]
    A --> F["Scalability and reliability"]
    A --> G["Communication"]

Requirements and scoping. Functional and non-functional requirements are identified and prioritized before design begins.
High-level design. The components and their interactions cover the stated requirements. The design is coherent and has no missing piece, such as a write path with no read path.
Depth. For the hardest one to three sub-problems, the candidate goes beyond naming a technology and describes the mechanism, failure modes, and alternatives.
Trade-offs. Each significant choice states the alternative and the reason it was not chosen. Examples: SQL versus NoSQL, push versus pull fan-out, synchronous versus asynchronous processing.
Scalability and reliability. The design addresses growth, single points of failure, hot spots, data loss, and recovery.
Communication. The candidate states assumptions, checks them, keeps a logical order, and adjusts when the interviewer redirects.

Interviewers usually calibrate expectations to level. A junior candidate is expected to produce a working design with reasonable components. A senior candidate is expected to lead, quantify, and go deep on several areas. A staff-level candidate is expected to challenge requirements, weigh organizational and operational cost, and identify risks the interviewer did not raise.

Example: one statement mapped to dimensions

For the prompt "design a URL shortener", the following candidate statements each produce signal on a different dimension.

Candidate statement	Dimension
"Should links expire, and do we need custom aliases?"	Requirements and scoping
"At 100 million new links per day the store grows by tens of GB per day, so one node will not hold five years of data."	Quantitative sense, scalability
"Redirects are read-heavy and keyed by short code, so a cache in front of a key-value store fits."	High-level design, trade-offs
"A counter with base-62 encoding avoids collisions but needs a coordinated ID range per server. Hashing needs no coordination but needs a collision check."	Depth
"If the cache fails, reads fall through to the store, so the store must handle the full read rate or requests are shed."	Reliability

A statement that names a component without a reason ("use Redis") produces no signal on trade-offs or depth.

What a strong answer contains

Clarified scope with prioritized features and explicit non-goals.
Non-functional targets (latency, availability, consistency needs, scale).
Rough estimates that justify design decisions.
A high-level architecture with an API and a data model.
A deep dive into the components that are hardest or most critical.
Discussion of bottlenecks, failure modes, and possible extensions.

The process for producing these in order is described in the system design interview framework. Common ways answers lose points are covered in interview communication and common mistakes.

Interview questions

Why is the prompt intentionally vague? Requirement gathering is part of the skill being assessed. Real projects start with incomplete requirements, and the questions a candidate asks show how they scope work.
Is there a correct architecture? No. Several architectures can satisfy the same requirements. The evaluation is based on whether the choices fit the stated requirements and whether the trade-offs are understood.
How much depth is expected in each component? Broad coverage of the whole path from client to storage first, then depth in the components that dominate the problem, such as fan-out in a news feed or seat locking in ticket booking.
Should the candidate write code? Usually not. Small pseudocode or a data-structure sketch may be used where it clarifies a mechanism, but the main artifacts are the diagram, API, and data model.