NEW: ML Mock & Coaching with a 20+ year experience coach. Save $20 on sessions for Premium.ML Mock & Coaching now available
NEW: ML Mock & Coaching with a 20+ year experience coach. Save $20 on sessions for Premium.ML Mock & Coaching now available
The critique-style system design round: you are handed a colleague's design doc and asked what you think. What the format looks like, how it differs from designing from scratch, and what the interviewer is scoring.
Was this lesson helpful?
Finished this lesson?
Sign in to save your progress across devices.
Tip: use ← and → to move between lessons.
Most system design interviews start with a blank whiteboard: "Design a URL shortener." The design doc review round starts with a full one. The interviewer shares a one or two page design written by a colleague, gives you a few minutes to read it, and asks a single question: "What do you think?"
Anthropic uses this format in its system design loop, and it is spreading to other companies that care more about judgment than about reciting architectures. If you have never done one, it is disorienting. If you have reviewed real design docs at work, it is the most natural interview you will ever sit.
4 lessons · about 33 min of reading
Setup
The interviewer shares the doc and explains the premise: a colleague wrote this, it is a first draft, you have been asked to review it before it goes to the team.
Silent read
You read and take notes. Ask clarifying questions as they come up; the interviewer plays the author. Do the arithmetic here if the doc has numbers.
The review
You walk through your findings, biggest first. The interviewer defends the design, asks why, and probes your proposed fixes. This is a conversation, not a presentation.
Extension
A follow-up that tests whether you understood the system: a capacity puzzle, a placement question, or 'sketch the fix you proposed for issue two'.
The doc itself is short. One to two pages, often with a request flow written as a numbered list, a table or two, and a section of explicit assumptions. It is written to look like a real internal first draft, which means it has real first-draft problems: an unstated assumption that does not hold, a step in the flow that contradicts the overview, a number that does not add up, a failure mode nobody thought about.
The doc is not a trick. The author is not an idiot and the design is not a straw man. It is a plausible v0.1 from a competent engineer who was in a hurry. Review it with that in mind, and you will find the right issues in the right tone.
| Design from scratch vs. doc review | ||
|---|---|---|
| Design from scratch | Doc review | |
| What you produce | An architecture | A ranked list of findings with fixes |
| Where the numbers come from | You choose them (and the interviewer nudges) | The doc gives them; you check whether they close |
| The main skill | Generating a reasonable design under time pressure | Reading critically, prioritising, and proposing targeted changes |
| What a strong candidate sounds like | Structured, covers the pillars, makes trade-offs explicit | Leads with the one thing that would sink the project, then ranks the rest |
The biggest shift is that you are not being asked to be creative. The design already exists. You are being asked whether you can tell a good one from a bad one, explain why, and say what you would change with the least disruption. Candidates who treat the round as "now let me show you how I would have done it" score poorly even when their alternative is better, because they did not do the job.
Can you tell the issue that blocks the goal from the issue that is merely untidy? Do you lead with the former?
The doc gives you inputs. Do you multiply them? Do you notice when a goal and a constraint cannot both be true?
For each major issue, a concrete change and the trade-off it introduces. Not a rewrite; the smallest change that resolves the risk.
Notice what is not on the list: breadth of architectural knowledge. You do not need to know every consensus protocol. You need to read one page carefully, do arithmetic, and have an opinion you can defend.
It favours people who have reviewed real designs. If you have sat in design reviews at work, written comments on a colleague's RFC, or been the person who asked "wait, how many requests per second is that?" in a meeting, you already have the muscle. The lessons in this course mostly make that muscle explicit and give you a routine for the clock.
It is harder for people who have mostly consumed system design content. Knowing what a correct design looks like does not automatically tell you how to find where a specific design departs from it, or which departure matters most. That is a separate skill, and it is learnable in a few hours of deliberate practice.
Read the five-pass framework once, then go straight to a practice doc and apply it with a timer running. The worked example shows the framework applied to a real Anthropic doc; read it after your own attempt, not before.
Two Anthropic doc-review questions with a structured review editor, capacity math and a sample review.
A doc review mock is a conversation. Practise the back-and-forth with someone who has run the real round.
| The classic failure | Running out of time in requirements | Listing twelve nits at equal volume, or redesigning the whole thing |
| How much you talk | Most of the time | About half; the interviewer defends and probes |
It is a colleague's draft. Do you say what it gets right? Do you ask before asserting? Do you handle pushback without folding or digging in?