Requirements Clarification (Step 1 Deep Dive)
AdvancedAdvanced3+ yrs experience Deep technical material — distributed-systems theory, low-level implementation details, and case studies of real production systems.Prerequisites: Production experience with at least one distributed system. Comfort reading research papers and RFCs.Time Budget: 5–10 minutes — The most critical phase. Never skip it.
The goal of this phase is to transform a vague, open-ended prompt (e.g., "Design Twitter") into a well-scoped, concrete problem you can actually solve in 45 minutes.
Why It Matters
Interviewers intentionally give you an ambiguous prompt. They want to observe:
- Do you make assumptions or ask questions?
- Can you prioritize features under constraints?
- Do you understand the difference between functional and non-functional requirements?
A candidate who jumps straight into drawing boxes has already lost points before writing a single line.
The Clarification Flow
The 4 Question Buckets
Organize your clarifying questions into these four categories:
| Bucket | Goal | Example Questions |
|---|---|---|
| 🟣 Features | Scope what to build | What are the must-have features? What can we skip? |
| 🔵 Users | Understand traffic patterns | Who uses this? Are they mobile or web? Authenticated? |
| 🟡 Scale | Drive technical decisions | How many users? Reads per second? Writes per second? |
| 🔴 Constraints | Avoid wrong choices | Any SLA? Budget? Specific latency limits? |
Worked Example: Design a URL Shortener
Interviewer: "Design a URL Shortener like bit.ly."
Step A — Ask About Features
You: "Before I dive in, I want to make sure I understand the scope. Should I focus on the core URL shortening and redirection, or do we also need analytics, custom aliases, and expiration?"
Interviewer: "Focus on shortening a URL, redirecting users, and let's add custom aliases. Skip analytics for now."
✅ Functional Requirements confirmed:
- Given a long URL, generate a short URL (e.g.,
sho.rt/abc123) - Redirect a user who visits the short URL to the original long URL
- Users can optionally specify a custom alias (e.g.,
sho.rt/my-brand) - Short URLs expire after a configurable time (default: 1 year)
Step B — Ask About Users & Scale
You: "What's the expected scale? Are we building this for a startup or something like bit.ly at full production scale?"
Interviewer: "Let's assume 100 million URLs shortened per day and 10 billion redirects per day."
📊 Back-of-envelope estimation:
Writes (URL Shortening):
100M URLs/day ÷ 86,400 sec/day ≈ ~1,160 writes/sec
Reads (Redirects):
10B redirects/day ÷ 86,400 sec/day ≈ ~115,700 reads/sec
Read-to-Write Ratio: ~100:1 → Read-heavy system
Storage (10 years):
100M URLs/day × 365 × 10 = 365 Billion URLs
Each record ~500 bytes → ~182 TB of dataStep C — Ask About Constraints & Non-Functionals
You: "Any latency requirements for the redirect? And should we optimize for high availability or strict consistency?"
Interviewer: "Redirects should be fast, under 50ms ideally. High availability is more important than perfect consistency."
✅ Non-Functional Requirements confirmed:
| Requirement | Value |
|---|---|
| Availability | 99.99% (four nines) |
| Redirect Latency | < 50ms (P99) |
| Consistency | Eventual (acceptable) |
| Durability | URLs must never be lost |
| Scale | ~100K reads/sec at peak |
The Scoped Problem (Output of Step 1)
The Dialogue Pattern
Here is how a real Requirements Clarification conversation sounds, broken down beat-by-beat:
Red Flags vs. Green Flags
| 🔴 Red Flag (What NOT to do) | 🟢 Green Flag (What TO do) |
|---|---|
| Jump straight into drawing boxes | Ask clarifying questions first |
| Build everything (feature creep) | Explicitly agree on what's out of scope |
| Assume scale without asking | Estimate DAU/MAU/RPS based on numbers given |
| Skip summarizing requirements | Repeat requirements back to the interviewer |
| Treat all requirements equally | Prioritize must-haves vs. nice-to-haves |
| Ask 10+ questions in a row | Group questions logically, ask 2-3 at a time |
Quick Reference Cheat Sheet
FUNCTIONAL NON-FUNCTIONAL
───────────────────────────────── ─────────────────────────────────
What the system DOES How the system PERFORMS
───────────────────────────────── ─────────────────────────────────
✓ Feature list (user stories) ✓ Latency (< 50ms P99)
✓ API surface (endpoints) ✓ Throughput (100K req/sec)
✓ Data the system stores ✓ Availability (99.99%)
✓ User interactions ✓ Consistency (strong / eventual)
✓ Durability (data never lost)
✓ Scalability (10x growth plan)Next Steps
Once requirements are clear, move to Step 2: Back-of-the-Envelope Estimation → where you estimate the scale, throughput, and storage required for your system.
TIP
Always keep your non-functional requirements visible (written on the whiteboard or noted down). They act as guardrails throughout the rest of your design.
WARNING
Spending more than 10 minutes on clarification is a red flag. Be efficient — ask the most impactful questions and move on.