Vagueness is almost always intentional. "Design Twitter" is a deliberately under-specified prompt, and the interviewer is testing whether you can drive the conversation or whether you freeze and wait to be told what to build.
Do this
- Propose, do not interrogate. Instead of "how many users are there?", say "I will assume 10 million daily active users and a 100:1 read to write ratio unless you want a different scale." A proposed assumption shows judgement, keeps momentum, and still invites a correction - and interviewers will correct you if the number matters.
- Timebox it. Spend about 5 minutes of a 45 minute interview on requirements, then move on. You can always return to an assumption later; you cannot get the time back.
- Write assumptions where they are visible. A short list in the corner of the whiteboard or document is what you point at when the design changes, and it stops you silently contradicting yourself twenty minutes later.
- Ask only the questions that change the architecture. "Is this read heavy or write heavy?", "is stale data acceptable?" and "single region or global?" reshape the entire design. "What colour is the button?" and "which cloud provider?" do not.
- Distinguish a genuine ambiguity from a detail. If two reasonable answers lead to the same architecture, pick one and state it. If they lead to different architectures, that is worth a question.
Worked example. Prompt: "Design a notification system." Rather than asking six questions, say: "I will assume push, email and SMS channels; 10 million users; notifications are fire-and-forget with at-least-once delivery; ordering is not required; and I am not building the template editor. The at-least-once choice is the important one - it means consumers must be idempotent. Shall I proceed on that basis?" That takes twenty seconds and has already established the hardest constraint.
The failure modes to avoid
- Asking twenty low-value questions and running out of time before drawing anything.
- The opposite error - assuming silently, so the interviewer cannot tell whether you understood the ambiguity or missed it. Always say the assumption out loud.
- Treating a correction as a failure. When the interviewer says "actually assume 500 million users", that is the interview working as intended, not a mark against you.