How to run a system design interview

A minute-by-minute framework for the 45-minute system design interview: scoping, numbers, high-level design, deep dives, and what senior and staff interviewers are actually grading.

A system design interview is not a test of whether you know the answer. Most questions have several defensible answers. It is a test of whether you can drive a 45-minute conversation from a vague prompt to a concrete design, make tradeoffs out loud, and hold up under follow-ups. Candidates fail far more often on process than on knowledge: they design the wrong thing, run out of time before the interesting part, or cannot explain why they chose what they chose.

This guide is the process. Every question on this site is structured to match it.

The clock

Plan the 45 minutes before you walk in. A typical split that works at senior and staff level:

The single most common mistake is spending 20 minutes on the high-level design. The interviewer has seen that diagram a hundred times. The score is decided in the deep dives, so get to them by minute 20 even if the diagram is missing a box or two. You can add it later.

Requirements: shape the problem before solving it

Start by restating the prompt in your own words and asking what the interviewer cares about. "Design Slack" could mean messaging, search, file storage, or notifications; you cannot design all four in 45 minutes. Propose a scope and get agreement.

Functional requirements are what the system does. Aim for 5 to 8 and prioritise: "core: send a message in a channel and receive it in real time; secondary: history, unread counts; out of scope: search, file uploads." Saying what you will not build is a signal of seniority, not weakness.

Non-functional requirements are the numbers that drive the tradeoffs. Get a number for each of:

• scale: daily active users, requests per second, data written per day;
• latency: the p99 that matters for the core operation;
• availability: 99.9 % or 99.99 %, and which paths must survive a region loss;
• consistency: where stale reads are acceptable and where they are not;
• durability and correctness: money, health, and legal data have zero-loss requirements that change the design.

Name the requirement that drives the hardest tradeoff. In a chat system it is fan-out to large channels; in payments it is exactly-once money movement; in a feed it is read latency against write amplification. Saying "the hard part of this problem is X" in the first five minutes tells the interviewer you have seen the shape of the problem before.

Estimation: find the number that matters

You are not estimating for accuracy. You are estimating to find which part of the design is under pressure. See back-of-envelope estimation for the numbers to memorise. Compute:

• writes per second and reads per second, average and peak (peak is typically 3 to 10× average);
• storage per year for the dominant data type;
• the fan-out multiplier, if any (one write becomes how many reads or deliveries);
• the count of the pressured resource: concurrent connections, partitions, cache size.

End with a sentence: "So writes are trivial, but 10 k reads/s at p99 under 100 ms means the read path needs a cache." That sentence is the estimate's whole purpose.

High-level design: the boring version first

Draw the simplest design that meets the functional requirements, then say where it breaks. Every design has the same skeleton: clients, an edge (load balancer or API gateway), stateless services, durable storage, a cache, and an asynchronous path (queue or stream) for anything that does not need to happen before the response.

For each box say what it is responsible for and what backs it. For the two or three core operations, sketch the API (method, path, key fields, key response fields) and walk the request through the diagram in order. Interviewers listen for whether you understand what happens at each hop, not for the shape of the boxes.

Define the data model for the core entities: the tables or collections, the primary key, and the one or two indexes the access patterns need. Key design is where storage decisions are made, and it is where a follow-up question will land.

Deep dives: where the interview is decided

A deep dive is an answer to a "why" or "why not" question about one component or decision. The structure that scores well is the same every time:

1. State the problem with a number ("the largest channels have 50 k members, so one message becomes 50 k deliveries").
2. List two or three realistic alternatives, each with its main pro and con.
3. Pick one and give the concrete design: keys, thresholds, TTLs, consistency level, what happens on failure.
4. Say what breaks at 10× and what you would change.

Let the interviewer steer when they want to; they may have a topic in mind. When they do not, pick the hardest problem in your own design. Choosing an easy deep dive is a visible signal that you do not know where the hard parts are.

Expect follow-ups after every answer. The common shapes are: a failure case (a component crashes halfway), a scale case (10× the numbers), a "why not X" you did not address, an edge case, and "how would you know it is working". Every deep dive on this site includes these.

What interviewers grade

Rubrics differ, but at large companies they are close to this:

• Problem exploration. Did you ask, scope, and identify the hard part?
• Design quality. Does the design meet the requirements, and is each component justified?
• Tradeoffs. Did you consider alternatives and choose with reasons, or just assert?
• Depth. Can you go two or three levels down on the parts that matter: key design, failure handling, consistency?
• Communication. Did you drive, structure your time, and keep the interviewer with you?

Senior is expected to do all five for a familiar problem. Staff is expected to do them for an unfamiliar one, to disagree with the interviewer when the interviewer is wrong, and to talk about operations: rollouts, migrations, on-call, cost.

Habits that help

• Talk while you draw. Silence for more than 20 seconds loses the interviewer.
• Use numbers instead of adjectives. "Big" is not a size; "300 M rows per day" is.
• Name the technology as an example, not a requirement: "a wide-column store like Cassandra, because the access pattern is by partition key and time".
• When you do not know, say so and reason from first principles. Bluffing is detected quickly and costs more than the gap.
• Keep a list of things you skipped and return to them in the wrap-up. It shows you noticed.