How to Crack the System Design Interview

How to Crack the System Design Interview

System design interviews terrify engineers because they're open-ended. There's no right answer — and that's the point. Interviewers want to see how you think, not whether you've memorised Twitter's architecture.

Here's the framework that turns open-ended into structured.

Step 1: Clarify Requirements (5 minutes)

Never start designing without understanding scope. Ask:

• Functional: What should the system do? (feature list)
• Non-functional: Scale, latency, availability, consistency requirements
• Out of scope: What are we explicitly not building?

Step 2: Capacity Estimation (3 minutes)

Back-of-envelope math to understand the scale:

• Daily active users → requests per second
• Read/write ratio
• Storage requirements (5 year horizon)

Common numbers to memorise:

• 1M DAU, 10 actions/day = ~100 req/sec
• 1 image = ~300KB; 1M images/day = 300GB/day

Step 3: API Design (5 minutes)

Define the 3-5 most important endpoints. This forces clarity on what the system actually needs to do.

POST /api/v1/tweets      { userId, content, mediaIds? }
GET  /api/v1/timeline    { userId, cursor, limit }
GET  /api/v1/tweets/{id}

Step 4: High-Level Architecture (10 minutes)

Draw the main components: clients, load balancer, application servers, databases, caches, message queues. Connect them with arrows. Explain each one.

Step 5: Deep Dive (10 minutes)

The interviewer will steer you toward the interesting problem. Common deep-dives:

• How does the feed generation work?
• How do you handle the hot-spot problem?
• How does your system behave when the cache is cold?

Step 6: Trade-offs & Bottlenecks (5 minutes)

Every design has weaknesses. Identify yours before the interviewer does. This demonstrates senior-level thinking.

---

The single biggest mistake: jumping to solutions before understanding requirements. Treat the first 5 minutes as sacred.