Clarify before you draw

What it is really testing

Whether you scope a problem or start typing. A candidate who draws in minute one is designing for a system nobody described.

Ask these first

Before a single box goes on the board. The answers change the design, which is the point of asking out loud.

• Who uses this, and how many of them a day?
• Is it read-heavy or write-heavy, and roughly what ratio?
• What must never be lost, and what may be lost?
• What is the latency budget for the main action?
• One region or several?

The answer, in 4 moves

In this order. Each move earns the next one — say them out loud rather than drawing all four and narrating afterwards.

1. 1State the functional requirement in one sentence.
2. 2State the non-functional ones as NUMBERS, not adjectives.
3. 3Say out loud what is out of scope — and get agreement.
4. 4Repeat the whole thing back before you touch the whiteboard.

The trap

The follow-up that separates a rehearsed answer from a real one.

Designing for a scale nobody asked for is the most common way to fail an easy question. Ten thousand users do not need a globally sharded write path, and reaching for one says you cannot size a problem.