A repeatable interview framework

The five-step script

A system design interview is 40 minutes to design something like Twitter at a whiteboard. Wandering is the main way candidates fail, so use the same script every time:

1. Requirements (5 min). Ask what is in and out of scope. Split functional (what it does) from non-functional (scale, latency, availability, consistency)
2. Estimation (5 min). Lesson 9-1: DAU → RPS → peak, storage per year. Say conclusions out loud: read-heavy, fits one leader, needs a cache
3. API and data model (5 min). List the main endpoints, sketch the tables and their keys
4. High-level design (10 min). Draw the unit 1 anchor and grow it: load balancer, stateless app tier, database with replicas, cache, queue for slow work. Walk one read and one write through the whole diagram
5. Deep dives (15 min). The interviewer picks a hard part: sharding, the feed algorithm, the hot key. Go deep there

Speaking in tradeoffs

What interviewers actually grade is whether your choices connect to the requirements. The strongest sentence pattern in the room is:

I would choose X because of requirement Y, accepting cost Z.

For example: I will fan out on write because feeds must load in under 200 ms, accepting extra work at post time. Or: replicas may lag, which is fine for timelines but not for balance checks, so those reads go to the leader (lesson 4-3).

Three habits that signal seniority:

• Name the bottleneck before fixing it (lesson 1-2, forever)
• Start simple: propose the monolith with a cache before the 12-service diagram (lesson 8-1)
• Say the failure story: what happens when a server dies, when the cache is cold, when the queue backs up

Unit 10 applies this script three times, end to end.