The Five-Pass Review Framework

You have about ten minutes alone with the doc before the conversation starts. What you do with them decides the round. Reading top to bottom and underlining things that look odd produces a flat list of observations. The framework below produces a ranked list of findings, each with a fix, and it does so in the same ten minutes.

Five passes. Each one has a single question and a single output. Do them in order; later passes depend on earlier ones.

Pass 1: Restate the goal and constraints#

Read the background and goals sections, then write down, in your own words, what the system must do and what it must not exceed. Two sentences. If you cannot do this, you are not ready to critique anything.

This pass seems trivial and it is the one candidates skip. It matters for two reasons. First, it is what you will say out loud in your opening, and saying it tells the interviewer you understood the doc before judging it. Second, it is where you catch the doc's own contradictions: a goal that the constraints make impossible is visible the moment you write both down next to each other.

Also write down the assumptions the doc states explicitly. Docs that say "we assume X" are telling you where the author was unsure. Each one is a candidate for a clarifying question, and one of them is usually the thing that breaks.

Pass 2: Make the numbers close#

If the doc has any numbers, multiply them. Throughput per unit of capacity, units needed at average and at peak, units available, the smallest latency a request can possibly see. If the doc has no numbers, supply plausible ones and say they are yours.

What you are looking for:

• A goal and a constraint that cannot both be true. "Serve 10k QPS" and "3 hosts" with a per-host capacity of 70 QPS. One of the two numbers is wrong; find out which before spending time on anything else.
• A latency target the architecture cannot meet. A 1.5 second processing floor with a "low latency" goal; a synchronous request path with a first-token target.
• Growth nobody bounded. Writes per day, storage per year, queue depth under overload. Anything that grows without a stated limit is a finding.
• The opposite: a small system wearing big-system clothes. Two requests per second does not need sharding. Saying "scale is not the risk here" is a finding too, and a good one.

Round aggressively. Orders of magnitude are what matter, and false precision costs you time.

Pass 3: Trace one request end to end#

Pick a single request and walk it through every box in the doc. Who receives it? Where does it wait? Who decides when it moves? How does its response find the way back? At each hop, ask three things:

1. Who owns this state? Every queue, cache and connection belongs to some component. If the doc does not say which, that is a gap, because whoever owns the state owns its failure mode.
2. Does this step agree with the overview? First drafts are written in pieces. The request flow often contradicts the system overview written an hour earlier. Those contradictions are findings, usually minor ones, but they point at places the author had not fully thought through.
3. Is this component alone? A single active instance with a hot standby that holds no state is a single point of failure with extra steps.

The response path deserves its own trace. Docs are good at describing how requests go in and vague about how responses come out, particularly when something in the middle (a batcher, a queue, an async worker) breaks the one-to-one mapping between a request and the connection waiting for it.

Pass 4: Ask what breaks first#

Two scenarios, two minutes.

Under load. Traffic is three times the design point. Which component saturates first? What happens to the requests it cannot handle: do they wait forever, fail fast, or crash the component? A design with no backpressure and no load shedding will do the first or the third.

Under failure. The weakest component you found in pass 3 dies. What is lost? In-flight requests, queued requests, the mapping from responses to clients, the ability to make progress at all? Is the loss acceptable for this product, and did the author decide that or just not think about it?

You are not looking for every failure mode. You are looking for the one that would be on the incident report, and for whether the doc knows about it.

Pass 5: Rank and recommend#

You now have somewhere between six and fifteen observations. Most candidates fail here: they present them in the order they found them, at equal volume. Rank them instead, using severity:

Pick the top three. For each, write one line: the issue, the fix, the trade-off the fix introduces. A fix with no trade-off is usually a sign you have not thought it through; most real changes cost something, and naming the cost is what separates a reviewer from a critic.

Finally, write down one thing the doc gets right. You will say it early. It is not politeness; it is calibration. A reviewer who finds nothing good is as useless as one who finds nothing bad.

Doc smells, and the question each one deserves#

Patterns that show up in interview docs again and again. When you see one, you know what to ask.

Self-check#

Run this after every practice attempt, before you open the answer key.

Next: how to deliver the review, because a correct ranked list said badly still scores badly.