Part 1 · How to Think in the Interview Chapter 2

The answer framework.

The reusable five-step flow that works across almost every system design interview.

Learning objective

Use a stable answer structure that works across prompts, so you can stay organized under pressure even when the topic is brand new.

Before you read

Make a prediction first.

Predict

Answer before the explanation.

If the prompt changes completely, what part of your answer process should stay the same?

Commit

Write a rough answer.

Before reading, name the one stage where you usually rush or go blank.

Connect

Notice where it returns.

This chapter is the spine for every later design: URL shortener, chat, video, feed, and rate limiter all use the same route.

Plain English

Don't invent a new process for every prompt.

Candidates often fail because they try to reinvent how to answer for every new system. That wastes mental energy. The better approach is one repeatable flow with the content swapped inside it.

This course uses a five-step answer flow. The order matters.

If you skip scope, your design may solve the wrong problem.
If you skip size, your architecture may be disconnected from the scale.
If you skip the sketch, the interviewer has nothing stable to react to.
If you deep dive too early, you lose the big picture.
If you never defend, your answer sounds mechanical.

The framework is valuable because it reduces anxiety. When the prompt changes, your process does not.

Why it matters in interviews

The framework gives the interviewer confidence — and gives you a recovery path.

It shows you know how to manage ambiguity, time, and detail. It also helps you recover. If you get stuck, you can ask yourself which step you're in:

Am I still scoping?
Do I need a rough estimate?
Do I need to draw the baseline?
Have I chosen the right deep dive?
Have I explained the trade-offs clearly?

That's much better than improvising blindly.

Mental model

The framework as a camera zoom.

Choose the scene. Understand its scale. Draw the wide shot. Zoom into the important area. Explain why this framing is the right one.

This model keeps you from zooming into a leaf before you've shown the forest.

Key ideas

Five things to actually do at the table.

Reuse the same flow across nearly every prompt.
Spend early time on alignment, not detail.
The first diagram should be broad, clean, and explainable quickly.
Pick one deep dive that matters most instead of touching everything shallowly.
End with explicit trade-offs and next-step evolution.

Speaking script

Lines you can run on autopilot.

Opening

I'll quickly clarify the scope, estimate rough scale, then sketch a baseline design before going deeper.

Sizing

For sizing, I only need rough numbers that change architecture decisions.

Sketching

I want my first diagram to be simple enough to explain in under two minutes.

Deep dive

The deepest part of the discussion should be the area where scale or reliability actually creates pressure.

Defending

I'll close by calling out the main trade-offs and how I would evolve the system.

Common mistakes

How candidates misuse the framework.

Treating the framework as a script to recite mechanically instead of a structure to think with.
Spending too much time on back-of-the-envelope math.
Using the baseline sketch as the final design and never evolving it.
Choosing several shallow deep dives instead of one meaningful one.
Ending without summarizing the main trade-offs.

Misconception check

Correct the wrong model before it sticks.

Wrong intuition

What feels tempting

A new system design prompt needs a new custom process.

Better model

What to replace it with

Most prompts can be handled by the same stable flow: scope, size, sketch, deep dive, defend.

Interview move

What to do in the room

Say the flow out loud at the start so the interviewer can follow your map.

Trade-offs

Which posture to lean on.

Defaults are tagged in blue.

Strategy	Good when	Weak when	Interview line
Strong up-front structure Default	You need clarity and pacing early.	You sound robotic and never adapt.	I'll start with scope and scale so the design stays grounded.
Fast first-pass sketch Default	You need alignment on the system shape.	The diagram is vague or unsupported by assumptions.	Here's a simple baseline before I optimize anything.
Single deep dive	One subsystem clearly dominates scale or risk.	You pick an unimportant detail.	The highest-value deep dive here is feed generation, because that's where the scale pressure sits.
Broad but shallow coverage	The interviewer wants a quick survey first.	Nothing gets explained with enough depth.	I can survey the full design first, then zoom into the highest-risk area.

Worked example to solo answer

Fade the support before the real practice.

Do not jump straight from reading to a full answer. First see the shape, then complete part of it, then answer alone.

I do

Study the model move.

I would open a rate limiter with: "I will scope who is being limited, estimate request volume, sketch the request path, then deep dive on counters and fairness."

We do

Complete the missing piece.

Fill the five boxes for the rate limiter in one line each before reading the model answer.

You do

Answer without notes.

Redo the same five boxes for a notification system without looking back.

Practice

Walk the framework with one sentence per step.

Prompt

"Design a rate limiter."

One sentence per step. No more.

Show a strong model answer

First I'll scope whether this is per user, per API key, or per IP, because that changes the state model. Then I'll estimate the request rate and whether limits need to be enforced across multiple servers. Next I'll sketch a baseline with the application calling a rate-limiter service backed by fast counter storage. Then I'll deep dive on algorithm choice and distributed correctness. Finally, I'll explain the trade-offs between strict accuracy, latency, and operational simplicity.

Training loop

Make this chapter stick.

Before moving on, turn recognition into production. Close the model answer, answer from memory, then retry one small slice.

Recall

Say the chapter's core idea without looking. Then name one related idea from an earlier chapter.

Vary

Change one constraint in the practice prompt and answer again in half the time.

Score

Use the rubric to pick one dimension below 3, then retry only that dimension.

Recap

Three things to take into the room.

The process stays stable when the prompt changes.

Reuse the five steps every time.

One real deep dive beats five shallow ones.

Pick the area where pressure actually sits.

Defend, don't just describe.

Close with explicit trade-offs and next-step evolution.

Reusable interview line

"I'll quickly clarify scope, estimate rough scale, then sketch a baseline before going deeper into the bottleneck."