Part 1 · How to Think in the Interview Chapter 3

Asking great clarifying questions.

How the right questions change the design before the design begins.

Learning objective

Learn to ask a small set of high-value clarifying questions that reduce ambiguity, reveal constraints, and improve architectural choices.

Before you read

Make a prediction first.

Predict

Answer before the explanation.

Which single question could change a video upload design the most?

Commit

Write a rough answer.

Write three possible questions, then mark the ones whose answer would actually change the design.

Connect

Notice where it returns.

Clarifying questions reappear in every case study because they decide what the design is allowed to ignore.

Plain English

A good clarifying question doesn't exist to sound smart. It exists to change the design.

Clarifying questions are one of the highest-leverage parts of a system design interview. The prompt is often intentionally incomplete. The interviewer wants to see whether you can identify the missing facts that drive architecture.

For example:

If a feed is chronological, the design may stay much simpler.
If it's ranked and personalized, the system needs more computation and more cached views.
If a chat system needs strict ordering only within a conversation, that's a different problem from global ordering.
If a URL shortener cares heavily about analytics, the write path and storage needs change.

The point isn't to ask many questions. The point is to ask the few that separate one design from another.

Why it matters in interviews

Good clarifying questions do three things at once.

1 · Show judgment

You demonstrate you know which facts move the architecture.

2 · Prevent waste

You don't sketch a system that will be rebuilt in five minutes.

3 · Make defense easier

Later trade-offs feel grounded because the constraints are explicit.

Bad clarifying questions do the opposite: they ask about trivial details or sound like a long checklist with no impact on architecture. The interviewer should feel that your questions are narrowing the problem, not delaying the answer.

Mental model

Clarifying questions are levers.

Each strong question moves one of the big architectural levers. If a question doesn't move a lever, it isn't worth asking early.

Pull a lever — the architecture shifts. That's the test of whether a clarifying question was worth asking.

Key ideas

Five rules for staying in design-changing territory.

Ask only questions that materially change the design.
Group questions into reusable buckets so you don't freeze.
Prefer product-shaping questions before implementation-detail questions.
State why you're asking when it helps the interviewer follow your reasoning.
Once you have enough to proceed, move forward confidently.

Speaking script

Lines that demonstrate judgment.

Opening

I want to clarify the main use cases first, because that determines what the system needs to optimize for.

Scale

Can I assume this is read-heavy rather than write-heavy, or should I design for both at similar scale?

Latency

What latency matters most to the user here: write acknowledgement, read freshness, or background completion?

Consistency

Do we need strict correctness everywhere, or are there places where eventual consistency is acceptable?

Closing

I think I have enough to proceed, so I'll state the assumptions I'm using and sketch the baseline design.

Common mistakes

Predictable ways this round goes wrong.

Asking too many questions before making progress.
Asking questions whose answers don't affect architecture.
Asking implementation-detail questions too early.
Failing to state assumptions when the interviewer leaves something open.
Continuing to ask questions after the design direction is already clear.
Treating clarifying questions as a rigid checklist instead of a decision tool.

Misconception check

Correct the wrong model before it sticks.

Wrong intuition

What feels tempting

Clarifying questions are polite warm-up before the real answer.

Better model

What to replace it with

Good questions are architecture switches: the answer changes storage, latency, consistency, fan-out, or scope.

Interview move

What to do in the room

Ask fewer but sharper questions, and explain why each answer matters.

Trade-offs

Question styles, ranked by leverage.

Question style	Good when	Weak when	Interview line
Product / use-case Default	The prompt is broad and feature boundaries are unclear.	You never connect them to architecture.	I want to pin down the main user path because that changes what we optimize for.
Scale / traffic shape Default	Throughput, storage, or fan-out may affect structure.	You ask for exact numbers that are unnecessary.	Rough magnitude is enough here; I only need numbers that change the design.
Reliability / consistency	Data correctness or user expectations matter.	You ask abstract theory questions detached from product behavior.	Do users expect immediate global consistency, or is slight delay acceptable?
Detailed implementation	A deep dive is already underway.	The main system scope is still unknown.	I'll save algorithm-level detail until after the baseline design is clear.

Mini case study

One question. Two architectures.

Prompt: "Design a notification system." Watch what changes when the answer to a single clarifying question flips.

"What's the fan-out per event?" is one of the highest-leverage clarifying questions you can ask in this prompt.

Strong clarifying questions

Push only, or also email and SMS?
Transactional, promotional, or both?
Near-real-time, or is slight delay okay?
Do users have preferences and mute settings?
Is fan-out per event small or very large?

Why each one matters

Channel choice → infrastructure shape
Reliability expectations → retry & durability
Latency target → batching & queueing
Preferences → data model & filtering
Fan-out shape → throughput design

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 ask: "Are videos public or private? That changes storage access, CDN behavior, and authorization."

We do

Complete the missing piece.

For the video upload prompt, turn one vague feature into a design-changing question.

You do

Answer without notes.

Ask five questions, cross out two weak ones, and answer using only the strongest three.

Practice

Try it before you read the model answer.

Prompt

"Design a video upload system."

List the five highest-value clarifying questions you'd ask before sketching.

Show a strong model answer

I'd first clarify whether this system is mainly about upload and storage, or whether transcoding, playback, and sharing are also in scope. Then I'd ask about expected upload volume, average file size, and whether creators upload infrequently or at high scale. I'd ask what user experience matters most after upload: immediate acknowledgement, fast processing, or fast playback availability. I'd ask how long videos are retained and whether multiple resolutions are required. Finally, I'd ask whether this is single-region to start or expected to serve users globally, because CDN and storage choices depend on that.

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.

Questions are levers, not politeness.

Each one should move scope, scale, latency, consistency, or retention.

Five buckets — memorize them once.

Users · Scale · Latency · Data · Boundaries.

Then move on, with stated assumptions.

Don't keep asking. Decide, declare, design.

Reusable interview line

"I want to ask the questions that move the architecture, then state my assumptions and sketch."