You are given a one-line design prompt and you start drawing within twenty seconds. The design goes well, you are fluent, you cover data and models and serving, and the interviewer stays quiet and lets you run. Somewhere after minute twenty-five a short question arrives — "how many of these do we get in a day?", "who actually looks at this output?" — and the answer is a number you never had. The rest of the round feels like it is being unpicked. The feedback says "did not clarify requirements" or "solved a different problem", and you cannot see the mistake, because everything you drew was technically correct.
Any ML system design or case round, and the failure is heaviest in the 45-minute version where there is no time to recover. It bites hardest on prompts that sound familiar — fraud detection, churn, a document assistant — because familiarity is exactly what makes a candidate skip the asking. Freshers are more exposed than experienced engineers, since a fresher's practice was mostly on datasets that arrived pre-defined, with the scale, the labels and the users already decided by somebody else. Linked module: 6.5 (ML system design / case round).
The prompt is deliberately under-specified, and the missing details are the assessment.
A one-line ask like "detect fraudulent seller listings" has at least six unknowns inside it: how many listings arrive, how many are fraudulent, what fraud even means here, who acts on the output, how fast the answer is needed, and what each kind of mistake costs. Every one of those changes the design. Nine hundred listings a day and three reviewers produces a rules-and-queue system. Nine million listings a day and an automated block produces something else entirely. Both are correct designs; only one of them is the answer to the question that was asked.
So the candidate who does not ask is not saving time. They are picking values for all six unknowns silently, in their own head, and then defending a design against numbers the interviewer never had in mind. The interviewer usually knows this within the first two minutes and waits, because the wait is the test.
There is a second, quieter cost. Assumptions that stay unspoken cannot be corrected. An interviewer who hears "I will assume five thousand a day" can say "make it five million" and steer you back in ten seconds. An interviewer who hears nothing has no cheap way to intervene without taking the round over, so most of them let it run and mark it at the end.
The reason strong students fall into this is that asking feels like not knowing. In an exam, a question is a sign of weakness. In this round, the questions are the visible part of the reasoning, and silence reads as a candidate who has never had to find out what a system was for.
Spend the first five minutes asking, and write every answer where the interviewer can see it.
The opener, word for word. "Before I design anything, I want to check a few things about the problem." Then ask, in this order:
Write them down. Put the word ASSUMPTIONS in a corner of the board or the document and list every answer under it, including the ones you invented. Point at that corner when you make a design choice: "because it is four thousand a day, one small service is enough."
When they say "you decide". Do not treat this as permission to stay silent. State the number out loud, write it under ASSUMPTIONS, and design against it: "I will assume five thousand applications a day and a two-second budget — tell me if that is far off." A visible assumption is a scoring move; an invisible one is the failure in this entry.
The stop rule. If you are still asking at minute eight, stop and design. Six questions is enough. This entry's twin failure — the candidate who interviews the interviewer for twenty minutes and designs nothing — is rarer but scores no better.
Practise on one-line prompts only, never on well-specified ones, because a well-specified prompt trains the exact habit that fails here. Keep a written opener of six questions and use it on every practice case until you can say it without thinking. In pair practice, make the interviewer's rules strict: answer only what is asked, invent consistent numbers, and stay silent otherwise — a partner who volunteers information hides this failure from you. Grade every practice design on whether the assumptions block exists and is visible, before grading anything technical. On the day, treat the first five minutes as non-negotiable and draw no boxes at all inside them; the design you start at minute five will finish faster than the one you started at minute zero.
Q: "Design a system that flags risky merchants on our payments platform." Strong answer: open with "before I design, a few questions", ask about merchant volume, who acts on a flag, how fast, what a wrong flag costs a genuine merchant, and how many confirmed cases exist today — then write the answers down and design against them. Weak answer: start naming components. The tell an interviewer listens for is whether any number in your design came from them; if every number came from you, you designed for a company that does not exist.