Delivering the Review

The silent read is over. You have a ranked list. The interviewer looks up and says "so, what do you think?" The next three minutes matter more than the following twenty.

The three-minute opening#

Say these five things, in this order, and then stop.

1. Restate. "Let me check I have this right." Two sentences on what the system does and what it must satisfy. The interviewer corrects you if you are off, which is cheap now and expensive later.
2. Numbers. "Before the design, the numbers." The per-unit throughput, the units needed, the units available, in three or four short sentences. End on the conclusion: the goal is reachable, or it is not, or scale is not the risk at all.
3. Headline. The single finding that would sink the project. One sentence for the issue, one for why, one for what you would change.
4. Two more, briefly. The second and third ranked issues, one line each. Signal that there is a longer list without reading it.
5. Hand it back. "Where would you like me to go deeper?" The interviewer picks, and the conversation starts.

What you leave out of the opening: the nits, the wording contradictions, your alternative architecture, and anything that starts with "I noticed that". The opening is for the things that matter, said once, in order.

The sentence shape for a finding#

Every finding you raise, in the opening or later, has the same three parts:

Concern. "The dispatcher holds the only copy of the queue in memory." Why it matters. "When it fails over, every queued request is lost, and the standby starts empty, so the hot standby does not actually protect anything the user cares about." What I would do. "Either decide explicitly that clients retry, which needs idempotency and a timeout longer than one failover, or keep the pending set at the gateway and re-dispatch. I would start with the first, because it is simplest, and revisit if retries turn out to double load at the worst moment."

The third part is what turns an observation into a review. It also has a trade-off in it. If you cannot name the cost of your fix, say so: "I would want to think about what that does to the hot path." That is better than pretending the fix is free.

Staying constructive#

The doc is framed as a colleague's draft, and the interviewer is often playing the author. Tone is being scored, though nobody will say so.

Three habits that keep you on the right side of this table:

• Say what is good, early. One sentence, specific, before the first concern. "Batching by tokens rather than request count is the right unit." It costs nothing and reframes everything after it as a colleague's help rather than an attack.
• Ask before asserting when you are not sure. "Is the 30 second timeout at the load balancer fixed?" is a question. "The 30 second timeout is a problem" is a claim. If you are wrong about the claim, you have spent credibility; if you are wrong about the question, you have learned something.
• Separate the author from the doc. "The doc does not say how responses get back" rather than "you did not explain".

Handling pushback#

The interviewer will defend the design. This is the point of the round, not a sign you are wrong. Three cases:

They give you new information. "Actually the hardware budget is 300 hosts, Part 2 is just a placement exercise." Update immediately and visibly: "Then the capacity issue goes away and my headline moves to dispatch policy." Candidates who cling to a finding after its premise is gone lose more points than the finding was worth.

They disagree on judgment. "I think losing queued requests on failover is fine; clients retry." Hold your position if you believe it, with a reason, and name what would change your mind: "I would be comfortable with that if requests are idempotent and the client timeout is longer than a failover. If either is not true, I would still push back." You are not trying to win; you are showing that your position is conditional on facts.

They ask you to go deeper. "How exactly would you version prompts?" This is a mini design question inside the review. Answer it with the same discipline: the smallest change that fixes the issue, the data model or flow in a few sentences, the trade-off. Do not expand into a redesign.

Time management#

• Minutes 0 to 3: the opening.
• Minutes 3 to 15: the headline and the fix, in depth. The interviewer will probe here. Let them.
• Minutes 15 to 22: the second and third issues. Shorter.
• Minutes 22 to 25: the list of smaller items, in one breath each. "Then there are a few operational things: no health checks, no batch retry on worker death, metrics on queue depth. I would add those but none of them changes the design."
• Extension: whatever the interviewer brings. Use the same discipline: restate, numbers, answer, trade-off.

If you are running out of time with issues unsaid, say that: "I have two more I will skip in the interest of time: backpressure and max request size. Happy to come back to either." Unsaid-but-flagged beats unsaid.

Common mistakes#

• Nitpicking first. Opening with a wording contradiction or an endpoint name tells the interviewer you are reading for typos.
• Redesigning instead of reviewing. The most common failure for strong designers. You were asked what you think of this design, not what yours would be.
• Never doing the math. The second most common failure. The doc gave you numbers so that you would multiply them.
• The flat list. Twelve findings at the same volume. The interviewer cannot tell which one you would block the doc on, which means they cannot tell whether you have judgment.
• Agreeing with everything. Usually from a fear of seeming harsh. A review with no findings is a failed review. Soften the tone, not the content.
• Disagreeing with everything. Including the things the doc gets right. "No caching needed" in a system where every request is a fresh model call is correct; say so.
• Folding under pushback. The interviewer says "I think that is fine" and you say "ok". If you believed it a minute ago, say why you still do, and what would change your mind.
• Narrating your process. "So the first thing I did was read the background section, and then I..." Give conclusions, not a travelogue.

Next: the whole thing applied to a real doc, in the worked example.