Interview Framework

You get 45 minutes. The interviewer says "design Twitter." There are a thousand things to say and you'll remember half of them. Without structure, you'll ramble about load balancers for 20 minutes, never estimate scale, forget to design the API, and leave out the rabbit hole entirely. That's a no-hire signal, and the problem isn't your knowledge — it's your process.

The framework below is the one every senior engineer runs in their head. It takes practice to make it automatic, but once it is, you can't design badly.

Every system design interview follows the same shape. The ratio is roughly:

You drive the clock. If you spend 20 minutes on requirements, you'll never reach the deep dive — and the deep dive is where you differentiate.

Phase 1 — Requirements (5 min). Distinguish functional from non-functional. Functional: what the system does (users post, followers see posts). Non-functional: how well it does it (latency < 200ms, 99.9% availability, read-heavy 100:1). Always ask "who are the users, how many, where?" — location matters for CDN and replication. Don't ask about every conceivable feature — pick 3–4 core flows.

Phase 2 — Scale estimation (5 min). Derive numbers from assumptions. "100M DAU × 2 posts/user/day = 200M posts/day ÷ 86400s ≈ 2300 writes/sec. Reads are 100× that = 230k reads/sec. Each post is ~1KB → 200GB/day → 70TB/year." The numbers drive the design: 230k reads/sec means CDN and cache at minimum. 70TB/year means sharding matters.

Phase 3 — High-level design (15 min). Sketch one box diagram: clients → LB → API → cache → DB → queue → workers. Label what each piece does. Establish the single-user baseline first, then layer in distributed concerns. Define the API (5–6 endpoints with request/response shapes). Pick a database and justify the choice in one line: "Postgres because we need transactions on the payments table."

Phase 4 — Deep dive (20 min). Pick the one interesting thing in your design and go deep. For Twitter, it's fan-out. For Uber, it's geospatial indexing. For a URL shortener, it's hashing. Don't go deep on everything — pick the concept uniquely interesting to this problem and explore its tradeoffs, failure modes, and alternatives. This is where you prove you're senior.

• Jumping to architecture before scale — you'll end up with Kafka and Cassandra on a problem that fits in a single Postgres. Always estimate first.
• Designing for scale you don't have — "what if 10B users?" when the prompt said 10k. Build for the stated scale + one order of magnitude of headroom. Not three.
• Pattern matching without justification — "I'll use Redis and Kafka" with no reason. Every component needs a "because X" attached.
• Ignoring the interviewer — they'll steer you toward what they want to discuss. Follow their hints. When they ask "what about consistency?" — that's the deep dive they want.
• No API design — candidates skip endpoints because they seem boring. They're not; the endpoint shape reveals whether you actually understand the product.
• No numbers in tradeoffs — "we'll use caching" is weak. "We'll use a 16 GB Redis with cache-aside and 10-minute TTL, covering 90% of reads" is strong.

For every topic you discuss, know where you are on this ladder — and be ready to climb it when asked.

Layer 1 — Conceptual. What is this component and why do we use it? "A load balancer distributes requests across servers." Every engineer knows this.

Layer 2 — Design decisions. What tradeoffs did we make picking it, and what alternatives did we reject? "We use L7 load balancing with P2C because our request costs vary. L4 would be faster but can't route by path. Round robin would ignore request-cost variance." Mid-level engineers stop here.

Layer 3 — Rabbit hole. What happens when things break or scale further? "When the LB itself is a single point of failure, we run two LBs with anycast IPs and use DNS round-robin between them. Health checks use TCP rather than HTTP to avoid application-layer false positives. The drain-on-shutdown pattern is..." Senior engineers operate here.

The 11-section structure on every problem page maps directly to these four phases. Section 1–3 = Requirements + Scale. Section 4–5 = High-level. Section 6 = Deep dive. The rest is polish.