The Requirements Phase Candidates Rush Through

"How many users are we talking about?"

"Let's say ten million daily actives."

The candidate writes 10M DAU in the top corner of the board, and never refers to it again. Twenty minutes later they add a cache, and the reason they give is that caches are good — not that ten million of anything implied it. The question was asked because asking questions is part of the format. The answer was collected, not used.

That exchange is the whole problem with the clarifying phase. It has become a ritual with the shape of enquiry, performed at speed so the candidate can get to the part they rehearsed. And it is the cheapest place in the entire hour to buy yourself a better design, because a requirement you agree on at minute three is a constraint the interviewer cannot spring on you at minute forty.

The test for a good question

A clarifying question is worth asking if you can state, in advance, which two designs the answer chooses between.

Not "it would be useful to know" — which two designs. If both answers lead you to draw the same boxes, you are collecting trivia. If one answer gives you a queue and the other does not, ask it immediately and ask it first.

By that test, most of the standard opening questions fail and four of them carry almost everything.

Read to write

Ask for the ratio, not the count. The count is a number you have to interpret; the ratio is the interpretation.

A hundred reads per write and you are designing a fan-out-on-write system with aggressive caching, replicas, and a write path you are allowed to make expensive because it happens rarely. Near parity and all of that inverts — caching buys you little, the replicas mostly serve stale data nobody wanted, and the interesting problems move to the write path and to contention.

Those are two genuinely different diagrams from one question. Very few questions clear that bar.

What is allowed to be stale

The vaguest word in system design interviews is "consistency", and the way to make it concrete is to stop asking whether the system needs it and start asking what the user sees when it is missing.

"If a user updates their profile and someone else loads it two seconds later, is showing the old version acceptable?" is answerable by a non-engineer. "If two people book the last seat simultaneously, what should happen?" is answerable too, and the answer decides whether you need a single serialisation point somewhere in your design — which is one of the very few things you genuinely cannot bolt on later.

Ask it per operation, not per system. Almost every real design tolerates staleness in most places and refuses it in exactly one, and finding that one is most of the work.

Who is holding the client

A mobile client on a flaky network, a browser tab, and another backend service inside your own datacentre are three different sets of constraints wearing the same arrow on a diagram.

Mobile means retries you do not control, long tails of stale app versions, and a hard argument for idempotency keys on every write. Browsers mean you are talking about connection limits, caching headers and what happens on refresh. An internal caller means you can assume a sane retry policy, use a chattier protocol, and stop pretending you need an edge cache.

The candidates who skip this end up designing for a client that does not exist and then being surprised by a follow-up about duplicate submissions.

What failure is acceptable

Ask what the system is allowed to do when it is unhealthy, and you will get a requirement more useful than any availability target.

"If the recommendation service is down, is an empty carousel fine or is the page broken?" tells you whether that dependency is on the critical path. "If the payment provider times out, can we take the order and reconcile later?" tells you whether you need durable intent and an outbox, or a synchronous flow with real rollback. "Can we drop some events under overload, or is every one of them billable?" decides whether you are building a lossy pipeline or a lossless one — and those are not the same system with a different queue size.

Nobody volunteers this information. It is the single most under-asked question in the format.

The ones that are usually ritual

"How many users?" without a follow-up that uses the answer. "Should it be scalable?" — nobody has ever said no. "Do we need it to be highly available?" — same. "Should I consider security?" asked as a box-ticking gesture rather than a specific question about who the untrusted party is.

None of these are forbidden. They are just not free, and you are spending minutes from a fixed budget. Ask them if the answer will change your board, skip them if it will not, and notice that "how many users?" becomes an excellent question the moment you follow it with "and how concentrated is that in the peak hour?" — because now you have named the threshold you are testing.

Close the phase out loud

The last thing to do is the part that gets skipped even by candidates who asked well: say the constraints back as a list, including what you are not building.

"So: read-heavy by roughly a hundred to one, staleness fine everywhere except the booking step, mobile clients so writes need to be idempotent, and we can degrade recommendations but not checkout. I'm leaving accounts, billing and abuse detection out unless you want them."

Four sentences, and every architectural choice you make for the next half hour now has something to point at. That is what the phase is for. It is not throat-clearing before the real answer — it is the part that decides which real answer you are giving.