Clarifying Questions Checklist

Before drawing boxes, ask five questions. The answers change every downstream decision.

How It Works

The first 3–5 minutes of a system design interview should be spent asking — not designing. Five canonical questions: (1) Who are the users and roughly how many? (2) What are the core use cases we MUST support vs what's explicitly out of scope? (3) What's the read/write ratio and rough scale (DAU, QPS)? (4) What are the hard NFRs — latency, availability, consistency? (5) Are there regulatory, budget, or infrastructure constraints? Missing any of these leads to designing for assumptions that turn out wrong partway through the interview. Interviewers score this dimension heavily — candidates who jump straight into boxes without clarifying read as memorized answers, not system thinking.

Real-World Example

A recurring interview failure pattern: the candidate is asked to design a chat application and immediately starts sketching WebSocket servers without asking: is this consumer messaging (like WhatsApp — latency matters, billions of users, end-to-end encryption), enterprise chat (like Slack — consistency and searchable history matter, smaller scale, admin controls), or pub-sub alerting (like PagerDuty — reliability matters, small scale, integrations)? These three interpretations lead to radically different architectures. The candidate who asks gets to design once, correctly; the candidate who doesn't is designing blindfolded and often realizes 20 minutes in that they built the wrong thing.