Interview Framework

A structured 6-step approach to ace any system design interview. Follow this framework and you'll never get lost.

Step 1: Clarify Requirements

3-5 min

Start every interview by asking questions. Never jump straight into designing. This shows maturity and prevents you from building the wrong system. The interviewer is testing whether you can scope a problem.

✓Understand functional requirements (what the system does)
✓Understand non-functional requirements (scale, latency, availability)
✓Identify the most important features to focus on
✓Agree on scope with the interviewer

Quick Reference Numbers

Numbers to Memorize

1 day = 86,400 sec ≈ 100K sec
1 year ≈ 31.5M sec ≈ 30M sec
QPS from DAU: DAU × actions/day ÷ 86,400
Peak QPS ≈ 2-5× average QPS
1 char = 1 byte (ASCII), 2-4 bytes (Unicode)
UUID = 128 bits = 16 bytes
Timestamp = 8 bytes
1 KB = 1,000 bytes, 1 MB = 10⁶, 1 GB = 10⁹, 1 TB = 10¹²

Latency Numbers

L1 cache: 1 ns
L2 cache: 4 ns
RAM access: 100 ns
SSD read: 100 μs
HDD seek: 10 ms
Same datacenter roundtrip: 0.5 ms
Cross-continent roundtrip: 150 ms
Redis/Memcached GET: 0.1-1 ms
PostgreSQL simple query: 1-5 ms

Capacity Estimates

Single server: ~10K-50K QPS (depends on work)
Redis: ~100K-500K ops/sec per node
PostgreSQL: ~10K-50K QPS per node
Kafka: ~1M messages/sec per cluster
S3: virtually unlimited storage
Single MySQL table: ~10M-100M rows practical limit
WebSocket connections per server: ~50K-100K

What Interviewers Look For

Signal	Strong Candidate	Weak Candidate
Requirements Gathering	Asks targeted questions, prioritizes features, quantifies scale	Jumps into design, assumes requirements, asks generic questions
Estimation	Quick mental math, derives QPS/storage, uses estimates to justify choices	Skips estimation, gets stuck on exact math, doesn't use numbers in design
High-Level Design	Clear diagram, separates read/write paths, uses appropriate tech	Cluttered diagram, single DB, no caching, ignores async patterns
Deep Dive	Discusses algorithms, data models, consistency trade-offs, failure modes	Surface-level descriptions, can't explain WHY, no failure analysis
Communication	Thinks aloud, asks for feedback, structures the discussion	Silent design, ignores interviewer hints, disorganized presentation
Trade-offs	Names specific trade-offs, mentions alternatives, discusses operational concerns	Claims design is perfect, no awareness of limitations, ignores cost

The Golden Phrase

When you're unsure what to say next, use this phrase:

"The trade-off here is between [X] and [Y]. Given our requirements of [Z], I'd choose [X] because..."

This phrase shows engineering maturity. It tells the interviewer you understand that every decision has costs and you can reason about them.