Week 1: adopt a framework
I picked one structure and stuck to it for every problem:
- Requirements (5 min). Functional, non-functional, scale estimates. State assumptions aloud.
- API design (5 min). The public contract. This anchors the rest.
- Data model (5 min). What gets stored, how it is keyed, rough sizes.
- High-level architecture (10 min). Components and arrows. Client → LB → service → DB.
- Deep dives (15 min). The interviewer picks the direction. Be ready for any component.
- Scale, failure, monitoring (5 min). Not an afterthought.
Every problem fits this skeleton. Candidates who jump straight to boxes and arrows usually forget requirements or estimates and get dinged.
Week 2: the building blocks
I drilled the primitives until I could sketch them cold:
- Load balancers (L4 vs L7, health checks, sticky sessions)
- Databases (SQL vs NoSQL, when each wins, sharding, replication)
- Caching (where to put it, eviction, stampede protection, consistency)
- Queues vs streams (RabbitMQ vs Kafka, when each wins)
- CDNs (what they actually cache, invalidation)
- Consensus (Raft in plain English, when you need it)
The goal was not depth — it was recall speed. In a 45-minute interview I need to reach for these without stalling.
Week 3: classic problems, one per day
URL shortener, Twitter timeline, chat app, ride-sharing dispatch, Dropbox, rate limiter, distributed job queue, notification system. I wrote each one up end-to-end, timed myself at 45 minutes, and graded against the framework.
The list is not magical. The point is rep count. By the fifth problem, the framework is muscle memory and I can spend cognitive budget on the specific trade-offs.
Week 4: pacing and communication
I recorded myself solving problems. Watched them back. Cringed.
I talked too fast, skipped trade-offs, and drew boxes without saying why. The fix: narrate every decision as a trade-off. "I am putting Redis here instead of reading from Postgres because this is a hot path. The cost is cache invalidation complexity, which I will address in the deep-dive section."
Interviewers grade what you say out loud. Drawing quietly is invisible.
Week 5: mocks with real humans
Three mock interviews with different engineers. Paid a coach for one to get calibration against the bar. The feedback that mattered most:
- Stop saying "we would." Say "I would." You are the engineer.
- Estimate before deciding. A LB choice that is fine at 1k RPS is silly at 1M RPS.
- Leave airtime for the interviewer. They want to steer; a monologue prevents that.
Week 6: behavioral-on-technical
Every system design answer is also a behavioral signal. Did I consider maintainability? Did I name cost? Did I acknowledge what I did not know?
The phrases I practiced:
- "I would need to check the specific throughput, but here is the rough shape…"
- "There is a trade-off between X and Y. For this product, I would lean X because…"
- "I would defer this until we hit the bottleneck. Premature sharding has real costs."
Senior engineers acknowledge uncertainty confidently. Juniors either bluff or freeze.
Resources that actually helped
- Designing Data-Intensive Applications — Kleppmann. The fundamentals book.
- Grokking the System Design Interview — for problem lists and framework.
- Jordan Has No Life (YouTube) — mock interviews with real calibration.
- Reading actual engineering blogs (Meta, Discord, Figma, Stripe) — for what real systems look like.
The thing nobody tells you
FAANG system design is not about being brilliant. It is about being legible. Clear structure, stated assumptions, articulated trade-offs, time management. A methodical senior engineer beats a brilliant but scattershot one almost every time.