A system design interview isn't a memory test — it's a conversation about how you think when the problem is fuzzy. This chapter gives you a repeatable 4-step framework so you always know the next move.
Most people freeze in a design interview because they treat it like a pop quiz with one right answer. It isn't. There's no answer key — there's a problem too big to fully solve in 45 minutes, and an interviewer watching how you navigate it.
The good news: navigation is a skill you can rehearse. Strong candidates don't memorize architectures; they run the same loop every time — pin down what's actually being asked, sketch something simple, then sharpen the parts that matter while saying out loud what they're trading away.
This chapter hands you that loop as four steps you can lean on no matter the prompt. We'll thread one running example through all of it — "design a news feed" (think the home timeline of a social app) — so the abstract advice always has something concrete to land on.
The prompt you'll get is deliberately vague: "design a news feed," "design a URL shortener," "design Uber." That vagueness is the point. The interviewer isn't checking whether you've memorized a reference diagram — they're watching how you behave when the requirements are unclear, the scope is huge, and the clock is ticking. That's the actual job, distilled into 45 minutes.
So they're really probing four things, and almost none of them is recall:
Treat it as a collaboration. The interviewer is your teammate for the session, not an examiner waiting to pounce. Drive the discussion, but check in often — "does that scope sound right to you?" A senior signal isn't a perfect answer; it's a reasonable answer reached out loud, with the dead ends and the judgment calls visible.
Here's the loop. It works for any prompt because it mirrors how real systems get built: figure out what you need, sketch something whole, then make the important parts real.
Roughly budget your time: a few minutes scoping, about ten on the high-level design, the bulk on the deep dive, and a couple of minutes wrapping up. Click through the steps below to see each one play out on our running example.
The single biggest mistake is to start drawing boxes the moment you hear the prompt. "Design a news feed" could mean a Twitter-scale firehose or a small group's bulletin board — and those are completely different systems. Before a single line goes on the board, you ask. Spend the first few minutes turning the vague ask into a problem with edges.
A simple set of prompts gets you most of the way:
Write the answers in a corner of the board and treat them as your contract. Every later decision points back to them. Crucially, scoping is also how you make the problem winnable — by agreeing to ignore DMs, ads, and notifications, you've turned an impossible 45-minute task into a focused one. Cutting scope out loud is a strength, not a dodge.
As you clarify, sort what you hear into two buckets, because they pull on the design in completely different ways.
Here's the part people miss: the non-functional requirements are what actually shape the architecture. "A user can post" is satisfied by almost any design. But "feed loads in under 200 ms for 10M daily users" is what forces caching, fan-out, replicas, and CDNs into the picture. Features tell you what to build; qualities tell you how hard it has to be — and therefore which of the tools from Chapters 1 and 2 you reach for.
So when you finish scoping, you should be able to say something like: "Functionally, post / follow / view-feed. Non-functionally, read-heavy, low-latency, highly available, eventual consistency is fine." That second sentence is the one that earns the rest of the hour. Try sorting a shuffled deck of requirements below.
Once the requirements are pinned, two quick moves set up the whole high-level design — and both happen before you draw a single internal box.
Feed in the back-of-the-envelope math from Chapter 2. You don't need precision — you need the order of magnitude that decides the shape of the system. For the news feed: 10M daily users, each opening the app ~10 times a day, is roughly 100M feed reads a day ≈ ~1,200 reads/sec average, call it 5–10× that at peak. Posts are far rarer — maybe a few thousand writes/sec. That single ratio (read-heavy) already tells you to lean on caches and replicas. Storage and bandwidth estimates tell you whether one database can hold it or you'll be sharding.
This is the "design the interface, then implement" instinct from good programming, applied to systems. Pin down the API contract — the handful of endpoints clients call — and the data model — the core entities and how they relate. Do this first, because the API and schema constrain everything downstream; the boxes are just an implementation of that contract.
Below is that contract sketched as types. Treating requests and rows as plain data — and the system as functions over them — is the same lens Chapter 1 used for stateless servers. The shape is identical in both languages.
This is the section that separates senior candidates from everyone else. There is no single right answer in system design — every choice buys you one thing by spending another. The skill isn't picking the "correct" option; it's seeing the tradeoff and saying it out loud before you choose.
The recurring ones you'll meet again and again:
When you make a call, frame it as a tradeoff: "I'll use a cache here — that gets us under the latency target, at the cost of serving data that can be a few seconds stale, which our requirements said is fine." That one sentence shows you understood the requirement, knew the cost, and chose deliberately. Move the sliders below to feel each tradeoff swing.
Most failed interviews die from a handful of avoidable mistakes. Recognize them and you've already dodged them.