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.

What a candidate skipped by drawing microservices first

Requirements and estimation, so they cannot know whether microservices are even warranted.

Without scope and numbers, every later choice is a guess. The candidate is now committed to defending an architecture chosen before anything was known about the problem.

Estimation for a URL shortener in the next unit shows a modest write load and a huge read load, which points to a cached monolith rather than microservices. The numbers actively contradict the drawing, and getting there takes two minutes.

There is a signaling problem on top of the technical one. Jumping to microservices reads as pattern-matching on what sounds impressive, and lesson 8-1's honest answer, meaning that microservices solve an organizational problem, is the one interviewers are listening for.

Recovering is possible and costs time you do not have. Backing up to ask about requirements after drawing a design is better than continuing, and it burns five of the forty minutes and some credibility.

Skipping steps 1 and 2 is the most common and most fatal interview mistake. The script exists to make those five minutes automatic, so the interesting parts of the problem get the time they deserve.

Completing the tradeoff sentence

The answer is cost.

Every technique in this course bought something by paying something. Caches bought speed at the cost of staleness in unit 3, replication bought safety at the cost of lag in unit 4, sharding bought scale at the cost of scatter-gather queries in unit 5, and queues bought resilience at the cost of duplicate deliveries in unit 6.

Stating the cost unprompted is what makes an answer sound senior. Anyone can name a technique, and naming what it takes away demonstrates you have run it in your head past the happy path.

It also changes the shape of the conversation. A candidate who volunteers the downside gets asked how they would mitigate it, and a candidate who hides it gets asked whether they know it exists.

Every design choice gives something up, and the word names the downside you take on knowingly. A design presented as having no costs is a design that has not been examined.