Updated 26 October 2026

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.

Typical targets for each kind of system, and the clarifying questions that get you to them, are in functional vs non-functional requirements.

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.
• Know which round you are in. A low-level design round wants classes and code, not boxes (HLD vs LLD), and Meta's product architecture round wants the API before the infrastructure (product architecture vs system design).
• Rehearse out loud before the day, with a person, a chat assistant set up as an interviewer, or a mock interview. Knowing the material and producing it under a clock are different skills.

Phrases that work

Small, specific sentences do a lot of work in this interview. Keep a few ready:

• "Before I design anything, let me confirm the scope and what is explicitly out of it."
• "I'll assume 10 M daily active users unless you have a number in mind."
• "That's about 5 k writes per second average, 15 k at peak. Writes are not the hard part here; fan-out is."
• "The boring version first: clients, gateway, service, database, cache. Then I'll fix what breaks."
• "There are three options here. I'd pick the second, because our requirement is X and it trades Y for Z."
• "This is the part I'd want to test, because it fails in a way the user would notice."
• "I'm making an assumption here: tell me if it is wrong and I'll redo this part."

And one for when you are stuck: "Let me think about that for a few seconds." Silence while thinking reads far better than filler.

Recovering when you are stuck

Every strong candidate gets stuck; the difference is the recovery.

1. Restate the constraint. "The problem is that a single counter can't take 100 k increments per second." Naming the bottleneck often produces the answer.
2. Reach for a pattern. The list is short: cache it, shard it, queue it, precompute it, approximate it, batch it, or give up a guarantee.
3. Solve a smaller version. "If there were only one region, I'd do this. Now what breaks with three?"
4. Say what you would measure. If you genuinely do not know whether an approach works, say what number would decide it. That is what a senior engineer actually does.

Never bluff a number or a technology you have not used. An interviewer who finds the bottom of one bluff discounts everything else you said.

Remote and whiteboard mechanics

• Draw the boxes left to right along the request path, keep the diagram to a dozen boxes, and label the arrows with the call, not with "HTTP".
• Leave whitespace: you will be adding a cache, a queue and a second region later.
• Write the numbers somewhere visible and keep them there; you will refer back to them in deep dives.
• On a shared document, type headings first (Requirements, Estimates, Design, Deep dives) so the structure is visible even while you talk.
• Narrate what you are drawing. Silence while drawing loses the interviewer, and they are grading your reasoning, not your rectangles.

The last five minutes

Do not let the interview end on a diagram. Spend the final minutes on:

• What would break first at 10× traffic, and what you would do about it.
• What you would monitor, in two or three metrics that map to the requirements.
• What you cut and would do next with more time.
• One honest weakness of your design. Interviewers trust candidates who can name it more than candidates who cannot.

Questions people ask

What is a system design interview?

A system design interview is a 45-minute conversation in which you take a vague prompt to a concrete design, make tradeoffs out loud and hold up under follow-ups. It is not a test of whether you know the answer, since most questions have several defensible answers. A typical run moves through requirements and scope, back-of-envelope numbers, a high-level design, two to four deep dives and a short wrap-up.

How do you prepare for a system design interview?

Prepare the process as well as the knowledge, because candidates fail far more often on process: they design the wrong thing, run out of time before the interesting part, or cannot explain why they chose what they chose. Plan how you will split the 45 minutes before you walk in, learn the numbers worth memorising for back-of-envelope estimates, and keep a few phrases ready, such as "Before I design anything, let me confirm the scope and what is explicitly out of it."

How should you split your time in a 45-minute system design interview?

A split that works at senior and staff level is 0 to 5 minutes on requirements and scope, 5 to 10 on back-of-envelope numbers, 10 to 20 on the high-level design, 20 to 40 on deep dives and 40 to 45 on wrap-up. The most common mistake is spending 20 minutes on the high-level design. 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.

How are system design interviews graded?

Rubrics differ, but at large companies interviewers grade problem exploration, design quality, tradeoffs, depth and communication. They check that you scoped the problem and found the hard part, justified each component, chose between alternatives with reasons, went two or three levels down on key design, failure handling and consistency, and drove the conversation. Senior candidates are expected to do all five for a familiar problem, and staff candidates for an unfamiliar one, plus operations such as rollouts, migrations, on-call and cost.

How do you structure a deep dive in a system design interview?

State the problem with a number, list two or three realistic alternatives with their main pro and con, pick one and give the concrete design, then say what breaks at 10× and what you would change. A problem stated with a number sounds like "the largest channels have 50 k members, so one message becomes 50 k deliveries". The concrete design names keys, thresholds, TTLs, consistency level and what happens on failure.

What should you do when you get stuck in a system design interview?

Restate the constraint, reach for a pattern, solve a smaller version, or say what you would measure. Naming the bottleneck often produces the answer, and the list of patterns is short: cache it, shard it, queue it, precompute it, approximate it, batch it, or give up a guarantee. Never bluff a number or a technology you have not used, because an interviewer who finds the bottom of one bluff discounts everything else you said.