The five phases, and how long each one gets

A system design interview is forty-five minutes of structured conversation, and the structure is a large part of what is being assessed. Candidates who know the material still fail by spending twenty minutes on the wrong thing, by drawing before asking, or by never reaching the part where they scale it.

1. Clarify the requirements — about 8 minutes. The prompt is deliberately vague. Ask until you know what you are building, what scale it operates at, and which properties are non-negotiable. Every question you skip is a constraint you will discover later, in front of the interviewer.
2. Estimate the load — about 6 minutes. Numbers, out loud, with the arithmetic. Users, actions each, read/write ratio, peak multiplier, bytes. Being within an order of magnitude is the bar; showing the working is the test.
3. Sketch the high-level design — about 15 minutes. Boxes, arrows, and the data flow for one request end to end. Do not optimise yet. Get something coherent on the board that satisfies the requirements you established, then say what you are unsure about.
4. Go deep on one component — about 10 minutes. The interviewer picks a component and probes. This is where the requirements you did not clarify come back, and where "it depends" is only an acceptable answer if you then say what it depends on.
5. Now a hundred times the traffic — about 6 minutes. What breaks first, and what do you do about it? A good answer names the component, says why it is the constraint, and proposes a change whose cost you can state.

Why the first phase matters most

Skipping requirements is the single most common way a system design interview goes wrong, and it does not feel like a mistake at the time. It feels like efficiency: the prompt is clear enough, you know roughly what to build, and drawing gets you moving.

What actually happens is that you make a series of decisions without noticing they were decisions. Whether the data is mutable, what the read/write ratio is, how fresh things need to be — each of those has an answer, you assumed one, and the interviewer knows what you assumed. Then the deep dive arrives and asks about the thing you assumed wrong.

This simulation lets you skip it, and then charges you for it later — which is the only way to make the cost feel like anything.

What "it depends" is allowed to mean

It is a complete answer only when followed by what it depends on and what you would do in each case. "It depends on whether reads or writes dominate — at a hundred to one I would precompute and cache; at one to one I would not, because the write amplification would exceed the read saving" is a strong answer. "It depends" on its own is a stall, and it reads as one.

The prompts

• Design a URL shortener. — A mid-size consumer product.
• Design the news feed for a social network. — A social network.
• Design a real-time chat system. — A messaging product.