What should the scoping phase of a system-design interview round produce before you draw anything?

## Scoping produces an artefact, not a vibe The most useful mental shift about the opening beat of a system-design round is that it has a **deliverable**. You are not having a warm-up chat; you are writing the short document that the next half hour argues from. It lives at the top of the shared design canvas, stays visible, and gets pointed at repeatedly. ### What goes on the list **One line restating the problem.** In your own words, narrower than the prompt. A prompt like *design our notification delivery service* becomes *a service that accepts send requests from internal teams, delivers each to one channel, and reports what happened*. If the interviewer disagrees with your restatement, you have found the biggest possible misunderstanding in the cheapest possible minute. **Three or four functional requirements.** What the system must do, in verbs. Resist writing eight - a long list is a sign you have not chosen, and you cannot design eight things in half an hour. Three or four is enough to shape a design and few enough to actually satisfy. **A handful of non-functional requirements.** These are the ones that change the architecture, and juniors skip them: how much load at peak, how fast a request must come back, how stale an answer may be, whether a duplicate is tolerable, what happens when a dependency is down. You do not need all of them - you need the two or three that will actually push a decision. **One out-of-scope line.** This is the highest-value line on the canvas and the one candidates most often omit. *Not building template authoring, not designing the internal admin tooling, assuming an existing identity service.* It converts a bottomless prompt into a finite exercise, and it demonstrates the scoping judgment the round is partly there to test. ### How to ask so that ten minutes is enough Open questions hand the design back to the interviewer and burn the clock. Closed questions with a proposed default do the opposite: - Weak: *What kind of scale are we talking about?* - Strong: *I am going to assume a few million sends a day with a peak around three times average - tell me if that is the wrong order of magnitude.* The second version costs one sentence, is answerable with a nod, and leaves a written assumption behind either way. In an invented example - a Series C scale-up interviewing a senior backend engineer - a candidate who works this way lands seven usable lines on the canvas in eight minutes; a candidate asking open questions is still exploring at minute eighteen. When you have not got an answer and the interviewer is deliberately vague, **take the assumption yourself and label it**. Write it in a visibly different place or mark it as an assumption rather than an agreed requirement. Interviewers correct stated assumptions instantly and cheaply; they cannot correct one you kept in your head. ### Why this beat comes first The failure it exists to prevent is **drawing boxes and arrows before agreeing requirements or scale**. Without a list, every component on the canvas is unfalsifiable: nobody can say whether it is right, including you. With a list, the round gains a scoring rubric that you wrote and that you can point at - *this queue is here because of the tolerate-a-short-delay line, and it would come straight out if that line said the opposite*. That sentence is worth more than the queue. The list also gives you a way to refuse scope creep politely. Mid-round an interviewer may say *what about multi-region?* You can answer against the artefact: *nothing on our list needs it today; if we add a regional availability requirement, here is what changes*. That is a stronger answer than either designing it silently or waving it away. ### Keeping it honest for the rest of the round A requirements list you write and then ignore is worse than none - it advertises a habit you do not actually follow. Refer back at least twice: once when the high-level design is done (*that covers lines one through four; line five is what the deep dive should be about*) and once when you make a tradeoff. Cross a line out when you agree to drop it, rather than quietly abandoning it. ### Common mistakes - **Endless scoping.** Ten minutes is a budget, not a target with slack. Past it, decide and move. - **Only functional lines.** With no load and no latency, every architecture is defensible and none is chosen. - **No out-of-scope line.** The prompt then stays infinite, and you get judged on everything you did not have time for. - **A private list.** Requirements you say aloud but never write cannot be pointed at, and the interviewer taking notes will not reconstruct them for you.