The rounds nobody prepares for

What it is

Most candidates prepare coding and system design, and then meet a round they have never rehearsed. Six formats account for nearly all of them, and each has a specific thing being scored that is not obvious from the format.

ROUND                 WHAT IS ACTUALLY SCORED
------------------------------------------------------------------
Design doc review     can you critique at the right altitude, and
                      do you distinguish blocking from
                      preference?

Code review           the PRIORITISATION of your comments, not
                      the count of them.

Debugging             your method under uncertainty. Whether you
                      form a hypothesis and try to disprove it,
                      or guess repeatedly.

Incident simulation   whether you mitigate before you diagnose.
                      Most candidates go straight to root cause.

Take-home             the README. At staff level the code is
                      table stakes and the trade-off write-up is
                      the artifact.

Product sense         whether you have an opinion about the users
                      and the metrics, or await instructions.

What this is confused with: these as easier rounds. They are frequently the discriminating ones, because everyone has drilled algorithms and almost nobody has rehearsed critiquing a document out loud.

Also confused: the round's surface and its content. A debugging round is not testing whether you can fix that bug. It is testing whether an engineer who has never seen this code can make progress systematically, which is what the job is.

The problem it solves

A candidate who has drilled two formats and meets a third performs a level below their ability.

An engineer with twelve years of experience, given a
four-page design doc and 40 minutes:

  minute 0-15   reads it silently
  minute 15-40  lists 23 observations in the order they
                appear in the document, including three
                typos, two naming preferences, one genuine
                correctness problem and one missing failure
                mode

The correctness problem was mentioned nineteenth.

Debrief: "thorough, but I couldn't tell what they thought
mattered."

They review documents well in their actual job. They had
never done it out loud, against a clock, for someone
scoring them.

And the incident round has a single failure that accounts for most of it:

"Error rate is at 14%, here are the graphs. What do you do?"

The reflex: "I'd look at what changed. Let me check recent
deploys, then the database metrics, then..."

That is diagnosis. Meanwhile the service is failing.

The answer that scores: "First, is there anything that
stops the bleeding right now? If a deploy went out in the
last hour I'd roll it back before I understand why. If
there's a feature flag for the new path, I'd turn it off.
THEN I'd diagnose, because mitigation is reversible and
being down is not."

Same candidate, same knowledge. The ordering is the signal.

Mechanics

Design doc review

WHAT IS SCORED: altitude, prioritisation, and whether you can
disagree without being unpleasant.

THE METHOD, out loud:

1. STATE THE PROBLEM BACK, in one sentence, before critiquing
   anything. If you cannot, that is your first finding and it
   is usually the most important one.
2. WORK TOP DOWN, not front to back:
     is this the right problem?
     is this a reasonable approach to it?
     does the design satisfy its own stated requirements?
     what happens when it fails?
     what does it cost to operate?
     ...then details, naming, typos, if there is time.
3. LABEL EVERY COMMENT: blocking, suggestion, question, nit.
   Say the labels out loud. This is the same taxonomy as a
   code review and it is what makes prioritisation audible.
4. NAME WHAT IS MISSING, which is harder and worth more than
   critiquing what is present. Failure modes, rollback,
   migration, cost, the operational story, who is on call for
   it.
5. SAY WHAT IS GOOD, specifically. A review that is entirely
   negative reads as a person you would not want reviewing
   your work.

THE FIVE QUESTIONS that find most real problems:
  - what happens when the thing it depends on is down?
  - how does this get rolled back?
  - who operates this, and what do they get paged for?
  - what does this cost, and at what scale does that change?
  - what is the migration from what exists today?

PRACTICE MATERIAL, and it is free and excellent: Rust RFCs,
Kubernetes KEPs, Kafka KIPs. All public, all real, all
written to be reviewed.

Naming what is missing is where staff-level review separates, because critiquing what is on the page is a skill anyone with taste has, and knowing that a document has no rollback section requires knowing that rollback sections exist.

Code review round

WHAT IS SCORED: prioritisation. A candidate who finds twelve
issues and cannot say which two matter scores below one who
finds four and ranks them.

THE ORDER, said out loud:
  1. CORRECTNESS      does it do what it claims? edge cases,
                      error paths, concurrency, the failure
                      modes
  2. SECURITY         injection, authz, secrets, unbounded
                      input
  3. DESIGN AND
     BOUNDARIES       is this the right place for this code?
                      does the next change get harder?
  4. TESTS            do they test behaviour? would they fail
                      if the code were wrong?
  5. READABILITY      will someone understand this in a year?
  6. NITS             everything else

LABEL EVERY COMMENT: blocking / suggestion / nit / question.

BLOCKING COMMENTS MUST STATE THE CONSEQUENCE, not the rule:
  weak:   "don't use a mutable default here"
  strong: "mutable default argument, so the list persists
           across calls and the second caller sees the first
           caller's items"

AND SAY WHAT YOU WOULD AUTOMATE. "None of the formatting
comments should be human comments; that's a linter." That
sentence alone is a leadership signal in a code review round.

Debugging round

FORMAT: a repository you have never seen, failing tests or a
described symptom, 45 minutes.

WHAT IS SCORED: method under uncertainty, not the fix.

THE LOOP, narrated:
  1. REPRODUCE. Get to a reliable failure before changing
     anything. "Can I run the failing test? Does it fail
     consistently?"
  2. NARROW. Bisect the space. Which layer, which input,
     which commit. Say what you are eliminating and why.
  3. HYPOTHESISE, and say what would DISPROVE it. This is the
     single strongest behaviour in the round.
       "I think the cache key doesn't include the locale. If
        that's right, the same request with a different
        locale returns the same result. Let me check that
        before I read any more code."
  4. TEST THE HYPOTHESIS with the cheapest possible check.
  5. FIX, and add the test that would have caught it.
  6. SAY WHAT ELSE HAS THIS SHAPE. "If the cache key is
     missing locale here, it's probably missing it in the
     other two cache calls." That generalisation is the staff
     signal.

WHAT LOSES: reading code linearly hoping to spot it, changing
several things at once, and never stating what you expect to
see.

PRACTICE: clone an unfamiliar open-source repository, have
someone introduce a bug, and fix it timed. The unfamiliarity
is the point; practising on your own codebase practises the
wrong thing.

"What would disprove this" is the sentence that separates the round, because it converts guessing into an experiment and it is audible.

Incident simulation

FORMAT: "here are the graphs, error rate is climbing, what
do you do?" Live, with the interviewer feeding you new
information.

WHAT IS SCORED: the ORDER of your actions.

THE LOOP, and say the first line out loud:
  1. STOP THE BLEEDING. "I'd mitigate before I diagnose."
     Roll back, flip the flag, shed load, fail over, scale
     out. Mitigation is reversible; being down is not.
  2. ESTABLISH ROLES if it is big. "I'd take incident
     command and ask someone else to own comms, because I
     can't do both."
  3. COMMUNICATE ON A CADENCE. "Status update every 15
     minutes even if there's nothing new, so people stop
     asking."
  4. DIAGNOSE, now, with the pressure off.
  5. VERIFY the fix, and say how you would know.
  6. POSTMORTEM, blameless, with owned and dated actions.

THINGS THAT SCORE, said unprompted:
  - "what changed in the last hour" as the first diagnostic
    question, because most incidents are a change
  - asking what the customer impact is, in customer terms,
    before technical detail
  - naming what you would NOT do: "I wouldn't restart the
    database, because I'd lose the state that tells me what
    happened"
  - "is this affecting all users or a subset" as an early
    question, because the answer halves the search space

THE MOST COMMON FAILURE, stated once more: going straight to
root cause. Say "mitigate before diagnose" in the first
thirty seconds.

Take-home and presentation

WHAT IS SCORED at staff level: the README, and the scoping.

SCOPE SMALL, SHIP CLEAN. A half-finished ambitious solution
loses to a complete modest one, every time.

THE README IS THE ARTIFACT. Structure:
  - what it does, and how to run it, in three lines that
    actually work
  - the decisions you made, and what you traded away
  - what you did NOT do, and why, with the time budget
    stated: "I spent the time on X because the brief
    emphasised it; with another day I'd add Y"
  - the failure modes you know about
  - what you would do differently at production scale

TESTS, and say what they cover and what they deliberately
do not.

TIME-BOX IT HONESTLY, and say the box in the README. A
"four-hour" take-home where the best submissions take
sixteen is a filter on free time rather than skill, and
saying "this is four hours of work, here is what four more
would buy" is both honest and a strong signal.

THE PRESENTATION: lead with the decisions, not the demo.
Five minutes of walkthrough, then the trade-offs. Bring the
diagram.

At senior level the code is scored; at staff level the code is a gate and the README is scored, because the artifact demonstrates judgment and communication in a way a working program does not.

Product and business sense

FORMAT: "how would you prioritise this roadmap", "should we
build X", "what would you measure".

WHAT IS SCORED: whether you have an opinion about the users
and the metrics.

THE SHAPE:
  1. WHO is the user, and what are they trying to do
  2. WHAT METRIC would move if this worked, and what is it
     now
  3. WHAT IS THE CHEAPEST TEST of the assumption
  4. WHAT WOULD YOU NOT BUILD, and why

Know the company's north star metric before the loop. A lead
who cannot name it looks disconnected, reasonably.

The strong version names a thing you would kill: "I'd stop
the notification work, because the metric it moves is
already at the level where further gains don't affect
retention, and I'd put that team on the onboarding drop-off,
which is 30% and unowned."

A worked example: a loop that failed on the two unprepared rounds

A senior engineer with eleven years of experience, interviewing for staff at a company whose loop was: system design, architecture deep dive, code review, debugging, incident simulation, and leadership.

The result:

system design         strong hire
architecture deep dive strong hire
leadership            hire
code review           no hire
debugging             mixed
incident simulation   no hire

Outcome: no offer.

Two of the six rounds sank a loop where the other four were strong, and both were rounds the candidate had never rehearsed.

What happened in the code review round:

A 340-line PR with, by the interviewer's design, six issues:
  1 SQL injection in a rarely-used admin path
  1 race condition in a cache write
  1 missing error path that silently swallowed a failure
  1 N+1 query
  2 naming and structure issues

The candidate found five of six (missed the race), which is
a good result.

They were presented in file order. The SQL injection was
mentioned fourth, between a variable name and a suggestion
about extracting a method, in the same tone.

Debrief: "found most of it. Couldn't tell what they'd block
on. I'd worry about them reviewing a junior's PR."

Finding five of six and losing the round on presentation order is the specific shape of this failure, and it is entirely a rehearsal problem.

What happened in the incident round:

"Checkout error rate went from 0.1% to 12% eight minutes
ago. Here are four graphs."

Candidate's first fifteen minutes: an excellent diagnostic
walk. Checked the graphs, asked about the database, asked
about a downstream dependency, formed a good hypothesis
about connection pool exhaustion, and was right.

At minute fifteen the interviewer asked: "the site is still
down. What have you done about that?"

Nothing. The candidate had diagnosed for fifteen minutes
while the described service was failing.

The deploy that caused it had gone out nine minutes before
the alert, and the candidate never asked what had changed.

Debrief: "smart, and I would not want them running an
incident."

"What changed in the last hour" was never asked, which is the single highest-yield diagnostic question and also the fastest path to a mitigation.

The preparation the candidate did before the next loop, over three weeks:

CODE REVIEW (about 6 hours total)
  - reviewed 10 open-source pull requests, out loud, recorded
  - forced the order: correctness, security, design, tests,
    readability, nits
  - labelled every comment blocking / suggestion / nit /
    question
  - after each, listened back and asked: could someone tell
    from the first 60 seconds what I would block on?

  By review 4 the answer was yes.

DEBUGGING (about 8 hours)
  - cloned four unfamiliar repositories, had a friend
    introduce a bug in each, fixed them timed
  - practised narrating the hypothesis-and-disproof loop,
    which felt unnatural for the first two
  - the transferable habit: say "if I'm right, X should be
    true" before looking

INCIDENT SIMULATION (about 4 hours)
  - wrote the loop on a card: mitigate, roles, comms
    cadence, diagnose, verify, postmortem
  - practised saying "I'd mitigate before I diagnose" as the
    FIRST sentence, five times, until it was automatic
  - practised the four unprompted questions: what changed in
    the last hour, what is the customer impact in customer
    terms, is it all users or a subset, what would I not do

DESIGN DOC REVIEW (about 4 hours, not in the previous loop
  but in the next one)
  - critiqued three Kubernetes KEPs out loud, top down
  - practised the five questions

Twenty-two hours of preparation on the rounds nobody prepares for, against roughly two hundred hours previously spent on algorithms and system design.

The next loop, at a different company, same format:

code review           strong hire
                      ("prioritised immediately, flagged the
                       injection as blocking in the first
                       minute, and said the formatting
                       comments should be a linter")
debugging             strong hire
                      ("stated a hypothesis and how to
                       disprove it before touching the code,
                       then generalised the fix")
incident simulation   strong hire
                      ("first sentence was mitigate before
                       diagnose; asked what changed within
                       thirty seconds")
system design         strong hire
architecture deep dive strong hire
leadership            hire

Offer at staff.

Nothing about the candidate's engineering ability changed in three weeks. What changed was that three formats they had never performed became three formats they had performed a dozen times.

And the candidate's own recorded assessment:

"I review code every day and I'd never done it out loud. I
run incidents and I'd never had to narrate one from a cold
start with someone scoring me. The skills were there; the
performances weren't, and an interview is a performance of a
skill, not the skill."

Production evidence

Stripe's loop is publicly described as including an integration round against a real API and a debugging round on a broken repository, with the stated emphasis on practical over algorithmic ability, which is the clearest example of these formats being the discriminating rounds rather than the supplementary ones.

Shopify's pair-programming-in-a-real-repo round and AI labs' agentic coding rounds (working in an unfamiliar codebase with real tools, often with a take-home followed by a deep dive) are the same movement: assessing work in unfamiliar code under time, which is what the job is.

Google's SRE hiring includes a troubleshooting round with the documented expectation of a systematic approach, and the SRE Book's incident-management chapter states mitigation before diagnosis as the operating principle, which is why saying it out loud maps directly onto a published rubric.

Public RFC processes (Rust RFCs, Kubernetes KEPs, Kafka KIPs) are real design documents written to be reviewed, with the review threads attached, which makes them the best available practice material for the design-doc-review format and for calibrating what a good critique looks like.

Conventional Comments (conventionalcomments.org) codifies the blocking/suggestion/nit/question taxonomy, and its stated purpose, removing ambiguity about how strongly a comment is held, is exactly what the code review round scores.

Research on structured interviewing consistently finds that assessing a work sample under realistic conditions predicts performance better than abstract problem solving, which is the reason these formats have spread and the reason they are increasingly the deciding rounds.

The debate

Are these rounds fair? More so than algorithm rounds, because they resemble the job. The unfairness is asymmetric preparation: everyone knows to drill LeetCode and almost nobody knows to rehearse critiquing a document out loud, so the round measures preparation awareness as much as ability.

Should you prepare for formats you have not been told about? Ask the recruiter, always, and prepare the two or three most likely regardless. Twenty-two hours across these formats is a rounding error next to the time most candidates spend on algorithms, and in the worked example it converted three no-hires into three strong-hires with no change in underlying ability.

Is a take-home worth doing? For a role you want, with a genuine time box, yes. The objection, that it is unpaid work and excludes people with caregiving responsibilities, is legitimate and is about the employer's design rather than the format, and the honest response as a candidate is to hold the stated box and say in the README what another day would buy.

Is the incident round realistic? No, and it does not need to be. It tests whether you reach for mitigation before explanation under pressure, which is a real disposition, and a candidate who diagnoses for fifteen minutes while a described service is down has demonstrated the thing the round exists to detect.

Should you find every issue in a code review round? No. Finding four and ranking them beats finding twelve unranked, and the candidate in the worked example found five of six and lost the round on ordering. Say the labels out loud, and say the highest-severity finding first.

Do product-sense rounds belong in an engineering loop? For staff and lead roles, yes, because prioritisation is part of the job and an engineer with no opinion about the users defaults to executing someone else's list. The failure is asking a deep product question of a deeply technical role, which is a badly designed round rather than an illegitimate one.

Follow-up Q&A

"What is actually being scored in a code review round?"

Prioritisation, not coverage. A candidate who finds twelve issues and cannot say which two matter scores below one who finds four and ranks them. Work in order, correctness, security, design, tests, readability, nits, label every comment blocking, suggestion, nit or question, and say the labels out loud so the ranking is audible. State the consequence rather than the rule on a blocking comment. And say that the formatting comments should be a linter, because that one sentence is a leadership signal inside a code review.

"How do you approach a debugging round in an unfamiliar codebase?"

Reproduce before changing anything, narrow the space and say what you are eliminating, then state a hypothesis together with what would disprove it, and check that before reading more code. "I think the cache key doesn't include the locale; if that's right, the same request with a different locale returns the same result, so let me check that first." That sentence is the single strongest behaviour in the round, because it converts guessing into an experiment and it is audible. Then fix it, add the test that would have caught it, and say what else in the codebase has the same shape.

"What is the most common failure in an incident simulation?"

Going straight to root cause. The reflex is to diagnose, and while diagnosing, the described service is still down. Say "I'd mitigate before I diagnose" in the first thirty seconds, because mitigation is reversible and being down is not: roll back, flip the flag, shed load, fail over. In one loop a candidate spent fifteen minutes on an excellent diagnostic walk, arrived at the correct answer, and had done nothing about the outage, and the debrief was "smart, and I would not want them running an incident."

"What is the highest-yield question in an incident?"

What changed in the last hour. Most incidents are a change, so it is both the fastest diagnostic and the fastest route to a mitigation, since a rollback does not require understanding. In the failed loop the deploy that caused the incident had gone out nine minutes before the alert and the candidate never asked. The other three worth saying unprompted: what is the customer impact in customer terms, is this all users or a subset, and what would I deliberately not do.

"What is graded in a take-home at staff level?"

The README. The code is a gate; the write-up is the artifact. Scope small and ship complete, because a half-finished ambitious solution loses to a complete modest one. Then document the decisions and what you traded away, what you deliberately did not do with the time budget stated, the failure modes you know about, and what you would change at production scale. Holding the stated time box and saying what another day would buy is both honest and a strong signal.

"How do you review a design document out loud?"

State the problem back in one sentence before critiquing anything, and if you cannot, that is your first and most important finding. Then work top down rather than front to back: is this the right problem, is this a reasonable approach, does it meet its own requirements, what happens when it fails, what does it cost to operate, and only then the details. Label every comment. And spend most of the time on what is missing rather than what is present, because rollback, migration, operational ownership and cost are the sections that are usually absent, and noticing an absence requires knowing what belongs there.

Common misconceptions

"These are the easy rounds." They are frequently the discriminating ones, because preparation is asymmetric: everyone drills algorithms and almost nobody rehearses critiquing a document out loud.

"Find every issue in the code review." Finding four and ranking them beats finding twelve unranked. In one loop a candidate found five of six issues and lost the round on presentation order.

"The debugging round tests whether I can fix the bug." It tests whether someone who has never seen the code can make progress systematically, which is what the job is.

"Diagnose first, then act." Mitigate first. Mitigation is reversible and being down is not, and the rollback does not require understanding.

"The take-home is judged on the code." At staff level the code is a gate and the README is the artifact, because it demonstrates judgment and communication in a way a working program does not.

"I do this every day, so I don't need to practise it." An interview is a performance of a skill rather than the skill. Reviewing code daily and never having done it out loud against a clock are different things.

Interview delivery note

Say this verbatim, as the first sentence of any incident round: "Before I diagnose anything: is there something that stops the bleeding right now? If a deploy went out in the last hour I'd roll it back before I understand why, because mitigation is reversible and being down is not." It is the single highest-value rehearsed sentence in this chapter and it addresses the most common failure in the format.

The senior-versus-staff separator across all six rounds is generalising the finding. In debugging: "if the cache key is missing locale here, it is probably missing it in the other two cache calls." In code review: "none of these formatting comments should be human comments, that is a linter." In a design doc review: "there is no rollback section, and I would want one on every doc of this kind, not just this one." Each turns one observation into a class of observations, which is the difference between fixing a bug and improving a system.

The second signal is rehearsing the format rather than the content. Saying "I review code every day and I had never done it out loud, and an interview is a performance of a skill rather than the skill" is a piece of self-knowledge that also explains why twenty-two hours across these formats moved three no-hires to three strong-hires with no change in ability.

The Staff & Team Lead Interview Reference