How to use this book

This is a reference for people interviewing for staff engineer and team lead roles. It exists because the usual prep artifact, a long checklist of terms, produces a candidate who can name things and cannot teach them. Naming is free at this level. An interviewer at a staff loop will pick one item off your list and push two layers past it, and the whole hire decision turns on what is underneath.

So the rule for this book is: every term, claim, drill and design question is taught, not merely named. A topic page is not finished until it contains a precise definition, the problem the thing solves, real mechanics with code or math, a worked example with numbers, at least one named production system that uses it, the tradeoff debate with a committed position, the follow-up questions an interviewer will ask with full answers, the misconception candidates carry, the sentence worth saying verbatim in the room, and primary sources.

Where the material comes from

The whole book is an expansion of one document, kept read-only at source/team-lead-staff-interview-prep.md in this directory. That document is the map: five parts, 51 sections, a 66-question drill bank, a 12-week study calendar and a self-audit of its own gaps. This book is the territory. When a page says "source §17.1", it means the corresponding section of that document, and the page you are reading is the expanded version of it.

Three sections of the source are the quality bar the rest is measured against: §41.1 (prefill vs decode), §42.1 (CQRS), and §43.1 and §43.2 (the two fully worked design answers). If a page here is thinner than those, it is not done, and the build status page says so honestly rather than hiding it.

How the book is laid out

Two hundred and seventy-plus topic pages across twenty chapters, in three kinds:

Topic pages teach one thing to the full bar: definition, the problem it solves, mechanics with code or math, a worked example with numbers, named production evidence, the debate with a committed position, follow-up Q&A, misconceptions, the delivery note, and sources. Most of the book is these.

Leadership scenario pages (chapter 16) use a different shape, because a role-play is not a concept: the answer, where it goes wrong, interviewer follow-ups, the delivery note, and further reading.

Design transcripts (chapter 15, all nineteen written) are the longest pages: clarify, capacity math, architecture, a deep dive on the hardest component, failure modes, what changes at ten times the scale, then the standard closing sections.

The two chapter kinds are meant to be read together. A topic page teaches a mechanism in isolation; a design page shows it assembled under a latency and cost budget, and they cross-link in both directions. If a design page seems to skip a mechanism, it is because the topic page has it.

Two navigational aids do more work than the chapter list. The drill bank maps all sixty-six questions to the page that teaches each one, so the fastest way in is to try answering a drill out loud and follow the link when you cannot. And the recitables sheet is the extract: the numbers, formulas and one-sentence positions worth having without notes.

Two forms of the delivery note

Every topic page ends with an interview delivery note, and it always contains two things: the sentence or two worth saying close to verbatim, and the depth signal that separates someone who has done this from someone who has read about it. The book expresses the second in two forms, and both are deliberate.

Most pages carry it as a labelled paragraph: "The senior-versus-staff separator is...". It is easy to find when you are scanning.

Some carry it integrated into the closing move of the note instead: "Close on the sequencing, because it is the judgement...", "The detail that shows implementation experience...", "And show calibration about the table itself...". Those read better and they are the same element.

So if a note has no labelled separator, the signal is its last paragraph. It has not been left out.

The three passes

Reading this front to back is the wrong use of it. Do three passes with three different purposes.

Pass one, inventory. Skim every chapter index and every topic title. Mark anything you could not explain to a peer for two minutes without notes. That marked set is your study list; everything else is maintenance. This pass takes an evening and saves weeks.

Pass two, production. Work only the marked topics. Read the page, then close it and say the answer out loud, then write the code snippet from memory. An answer you have only read is not an answer you have. Every topic page ends with follow-up questions for exactly this purpose: read the question, answer it out loud, then check yourself against the written answer.

Pass three, retrieval. In the last two weeks before a loop, use only four things: the drill bank, the recitables sheet, the questions to ask, and your own story portfolio. Nothing new. Cramming new material in the last three days costs you recall on material you already have.

The night-before subset

If you have one hour before an onsite, read these and nothing else:

1. Recitables, the numbers and formulas sheet.
2. Your own 12 to 16 stories, in SCOR form, timed to three minutes each.
3. The questions you will ask each interviewer persona (chapter 18).
4. The one design you expect to be asked, skimmed for the sequence, not the detail.

The 12-week mapping

The source document carries a 12-week calendar. This book maps onto it directly, so you can run the calendar and read the corresponding chapters:

Weekly constants regardless of focus: eight to ten timed coding problems, one mock from week three onward, one story tightened, one design written out longhand rather than read.

Seven devices that recur

The same few moves show up across chapters that have nothing else in common. They are worth naming, because recognising one tells you what kind of answer a question wants.

Turn a cultural complaint into arithmetic. "Engineers should rebase promptly" becomes a Poisson calculation showing 96 percent of pull requests are stale on completion. "Deploys cause latency" becomes 85% x 20/15 = 113%. "The canary might not exercise unusual paths" becomes a 21 percent probability. In each case the number is one line and it converts a debate about diligence into a statement about feasibility.

The control everyone reaches for is the one that cannot work. Host-allowlist CSP cannot work because an allowlisted CDN also hosts a JSONP endpoint. An accessibility launch gate cannot work because the expensive decision was made months earlier. More end-to-end tests cannot work because flake compounds. Naming the popular control and why it fails is usually a stronger opening than proposing the right one.

When the read and the outcome disagree, the instrument is wrong. A server-side SLI improved during a total regional outage. A lead's read of "steady but not stretching" was a misreading of someone carrying 60 percent of the team's uncredited work. A closed-loop load test reduces its own load when the system slows. Audit the rig before the system.

The number was true when it was written. A documented 12-minute RTO that was 47. A documented 4-hour restore that was 9h40m. A backup success rate of 100 percent on a 12 KB file. Nobody was dishonest; the number was derived once and never re-derived. Any number in an operational document should carry the date it was measured.

The local problem with the global fix. Making a projection synchronous to fix one screen's staleness taxes every write. Adding a repository layer to give one report query a home imposes an interface on 34 entities. Autoscaling to absorb a spike adds instances that inherit a hopeless queue. The global fix wins by default because it is easier to name in a planning meeting.

Find the question only the other party can answer. "How stale can this be before a merchant calls support" is answerable by a product manager in five seconds and unanswerable by an engineer, and in one case it was the difference between 480,000 requests a minute and 2,000. Its siblings: "which fact decides this", asked of a stakeholder, and "is there anything about my background that gives you hesitation", asked of an interviewer.

Convert many losing arguments into one policy argument won in advance. An error budget, a declared three-bucket capacity split, a page-budget overflow rule, a pre-registered primary metric. Each individual case ("can we fix this alert?", "can we do this refactor?") loses to a dated commitment, so the decision has to be made when nothing is at stake.

What this book will not do for you

It will not make you fluent. Fluency comes from saying these answers out loud to a person who interrupts you. The failure mode of a document this size is that comprehensiveness creates the illusion of preparation. The only signal that counts is whether you can produce the answer under time pressure, out loud, to a skeptical stranger. Everything here is in service of that, and none of it substitutes for mock interviews.

Interview mechanics

Senior interviews test whether you can solve a problem. Staff and team lead interviews test whether you can pick the problem, frame it, and get other people to solve it with you. Different bar, different preparation. This chapter is the scoring rubric, the loop formats company by company, and the structural habits that decide the outcome before any technical content is exchanged.

The single most common failure at this level is telling senior-level stories in a staff-level interview: the story is about what you built, not about how the org changed. The second most common is doing the design round as requirements to boxes to done, skipping capacity math and the API contract, and never once saying "the alternative was X; I am not choosing it because Y; if Z changed I would revisit."

What this chapter covers

• [done] What gets scored: the six signals
• [done] The staff-level design interview
• [done] The rounds nobody prepares for
• [done] Company loop formats
• [done] Differentiators, and interview-day mechanics
• [done] The architecture deep dive
• [done] SCOR, STAR and the scar-tissue story
• [done] Executive communication
• [done] Handling what you do not know

Source: §1 to §14 (except §4, which is Track A: the coding round), §27, §38.

What gets scored: the six signals

What it is

Senior interviews test whether you can solve a problem. Staff and lead interviews test whether you can pick the problem, frame it, and get other people to solve it with you. Different bar, and the scoring rubric reflects it in six dimensions.

Signal      Senior looks like            Staff/lead looks like
------------------------------------------------------------------
SCOPE       owns a service               owns a problem space
                                         across teams

AMBIGUITY   given a spec, executes       given a vague goal,
                                         produces the spec

JUDGMENT    picks a good option          explains three options,
                                         why the others lose, and
                                         the reversal criteria

INFLUENCE   convinces their team         convinces peers and leads
                                         who do not report to them

MULTIPLIER  delivers                     others got faster because
                                         of them

RISK        handles known risk           names the risk nobody
                                         else named

And two track-specific additions:

TEAM LEAD adds   performance conversations, the hiring bar,
                 delivery predictability, morale under
                 pressure, PM and stakeholder negotiation,
                 headcount and prioritisation trade-offs

STAFF adds       technical strategy over 12 to 24 months,
                 cross-org standard setting, deprecation and
                 migration leadership, design review
                 authority, making the hard call in a room of
                 senior people

What this is confused with: seniority as difficulty. A staff design round is not a harder version of a senior one. It asks a different question, and answering the senior question extremely well is the most common way to fail it.

Also confused: the six signals as a checklist to recite. They are the axes an interviewer scores on, so the useful work is making each one visible in a story you were going to tell anyway.

The problem it solves

The single most common failure is telling senior-level stories in a staff-level interview.

The story is about WHAT YOU BUILT, not about HOW THE ORG
CHANGED.

  "I designed and built the new ingestion pipeline. It
   handles 40,000 events a second, we cut p99 from 800ms to
   120ms, and I wrote most of the core."

That is an excellent senior answer. Every clause is about
personal execution.

An interviewer scoring SCOPE hears one service.
Scoring INFLUENCE hears nobody outside the team.
Scoring MULTIPLIER hears one person's output.
Scoring AMBIGUITY hears an implementation of a decided thing.

The candidate is strong, the story is true, and it argues for
the level they already have.

The same project, told against the six signals:

  "Three teams were each building their own ingestion, and
   the reason was that nobody owned the question of what
   'an event' meant here [SCOPE, AMBIGUITY]. I wrote the
   proposal for a shared pipeline and spent about six weeks
   getting the two teams who disagreed with it to a position
   they'd defend, which meant giving up the schema registry
   design I preferred [INFLUENCE, JUDGMENT]. The thing I got
   wrong was the migration order: I sequenced by technical
   difficulty rather than by which team could absorb the
   change, and we stalled for a month [RISK, and a real
   regret]. After it landed, the two consuming teams stopped
   maintaining their own ingest, which is about a person and
   a half of ongoing capacity [MULTIPLIER], and p99 went from
   800ms to 120ms."

Same project. Same facts. The numbers are still there, at the
end, where they belong.

The technical result moved from the opening to the closing, and that reordering is most of the difference.

Mechanics

Making each signal visible

Scope. The question the interviewer is answering is "how big was the thing this person owned."

Weak:   "I owned the payments service."
Strong: "I owned payment correctness as a problem, which meant
         the service, the reconciliation with finance, the
         contract with the two teams that wrote to our ledger,
         and the on-call for all of it."

The tell is whether the boundary you describe is a REPOSITORY
or a PROBLEM. Repositories are assigned; problems are claimed.

Ambiguity. The question is "what was the state of the problem when you got it."

Weak:   "We were asked to reduce checkout latency."
Strong: "The complaint was 'checkout feels slow', which
         turned out to be three different things: a slow p99
         for large carts, a rendering delay nobody had
         measured, and a perception problem with the spinner.
         I split them because two of them had different
         owners."

The signal is producing the specification, not receiving it.
And the strongest version includes a problem you decided NOT
to solve, with the reason.

Judgment. The question is "does this person reason about options, or advocate for one."

The complete shape has four parts, and most candidates give
two:
  1. the options, at least three
  2. what each costs
  3. why the ones you rejected lose, SPECIFICALLY
  4. the REVERSAL CRITERIA: what would have to be true for
     you to change your mind

Part 4 is the one almost nobody offers, and it is the
strongest single signal on this axis, because it demonstrates
that the decision was made against a model rather than a
preference.

  "I'd revisit the single-writer design if write volume
   passed about 40,000 a second or if we needed sub-50ms
   writes in Europe, and both were far enough away that I
   took the simpler thing."

Influence. The question is "can this person move people who do not report to them."

Weak:   "I convinced the team to adopt it."
Strong: "The platform team's lead thought it was the wrong
         layer, and he was partly right. I rewrote the
         proposal to move the boundary he objected to, which
         cost us a quarter, and he then co-signed it, which
         is what got the other two teams to move."

The signal is a NAMED DISAGREEMENT and what it cost you. A
story where everyone agreed is a story with no influence in
it, and interviewers hear that.

Multiplier. The question is "did other people get faster."

Weak:   "I mentored two juniors."
Strong: "Two teams stopped maintaining their own ingest,
         which is roughly a person and a half of recurring
         capacity, and the runbook I wrote is why the on-call
         rotation could expand from four people to seven."

Quantify the OTHER PEOPLE'S output, not your own. Mentoring
counts when you can say what the mentee did afterwards.

Risk. The question is "does this person see what others miss."

Weak:   "We had a rollback plan."
Strong: "The risk nobody had named was that our two consumers
         both cached the old schema for up to 24 hours, so a
         cutover looked instant to us and was a day long for
         them. That's why the migration ran a dual-write
         window of 48 hours rather than the two we planned."

The framing that scores is "the risk nobody else named",
which requires you to have been the one who named it, and to
say what changed because you did.

The audit, which takes an hour

Take your five best stories. For each, mark which of the six
signals it evidences, honestly.

A typical result before any work:

  story         scope  ambig  judg  infl  mult  risk
  ingest         yes     -    yes    -     -    yes
  latency work    -      -    yes    -     -     -
  migration      yes    yes   yes   yes    -    yes
  the outage      -      -    yes    -     -    yes
  mentoring       -      -     -     -    yes    -

INFLUENCE and MULTIPLIER are the two columns that are usually
empty, and they are the two that most distinguish the level.

The fix is not to invent stories. It is to notice that the
influence and multiplier content is ALREADY IN the stories
you tell and is being left out because it feels like it is
not the interesting part.

The influence and multiplier content is almost always present and almost always omitted, because the engineering is the part that felt like the work.

What the interviewer writes down

The scoring artifact is a written assessment read by people
who were not in the room. So the useful question is not "did
they understand me" but "what can they WRITE DOWN".

Give them quotable lines:
  "owned the event schema standard across four teams"
  "the two consuming teams retired their own ingest, about
   1.5 engineers of recurring capacity"
  "changed position after the platform lead's objection, and
   that is what unblocked adoption"

Vague warmth does not survive the transcription. A sentence
with a boundary and a number does.

A worked example: two candidates, the same project

Two engineers from the same team, interviewing at the same company for staff, describing the same eighteen-month migration.

Candidate A's deep dive, compressed:

Spent 35 of 45 minutes on the technical design: the sharding
scheme, the consistency model, the dual-write mechanism, the
backfill's throughput tuning. All of it correct and
genuinely deep. Answered every follow-up.

The last 10 minutes covered the outcome: 4x throughput, p99
down 60%, cost down 22%.

Debrief comments:
  "Very strong engineer. Deep systems knowledge."
  "I'd hire, at senior."
  "Scope: I heard one system. Ambiguity: the problem was
   well-defined when they got it. Influence: didn't come up."

Outcome: offer at senior. Declined.

Candidate B's deep dive, same project:

Spent 8 minutes on the technical design, at a level of detail
that invited follow-up, and answered every follow-up as deeply
as A did when asked.

Spent the rest on:
  - why the migration existed at all, which was a
    reliability argument the candidate had made to a VP with
    an error-budget number attached [SCOPE, AMBIGUITY]
  - the three approaches considered, what each cost, and the
    condition under which they would have chosen differently
    [JUDGMENT]
  - the two teams who resisted, what their objection was, and
    the design change that resolved it [INFLUENCE]
  - the sequencing mistake: ordered by technical difficulty
    rather than by which team could absorb the change, which
    cost a month [RISK, regret]
  - what the org could do afterwards that it could not
    before: two teams retired their own pipelines, and the
    schema standard became the default for new services
    [MULTIPLIER]

Same numbers, at the end.

Debrief comments:
  "Owned the problem, not the project."
  "Named a real mistake with a real cost."
  "Changed the design in response to an objection, and could
   say why the objection was right."

Outcome: offer at staff.

Candidate A was, by the team's own assessment, the slightly stronger engineer. The difference in outcome was entirely in which questions the 45 minutes answered.

What A did differently the second time, six months later:

Same project, same facts, one structural change: the
technical design moved from 35 minutes to 8, with an explicit
offer ("I can go as deep as you like on the sharding scheme,
and I'd rather spend the time on why we did this and what it
cost us to get agreement").

Two interviewers took the offer and went deep. A answered at
the same depth as before, in the follow-up rather than in the
opening.

Offer at staff.

A's own recorded assessment: "I thought the depth WAS the
signal. It's the price of entry. The signal is what I did
with the room's attention once I'd paid it."

"The depth is the price of entry, not the signal" is the compressed lesson, and it is why the reordering works without removing anything.

The signal audit, run on both candidates' story sets beforehand, would have predicted this:

                    A's 5 stories       B's 5 stories
scope                    2                   4
ambiguity                1                   3
judgment                 5                   5
influence                0                   4
multiplier               1                   3
risk                     3                   4

A's judgment column was full and their influence column was
empty. Both had the same underlying career; one of them had
noticed which parts of it the rubric asks about.

Production evidence

Published engineering career ladders (Rent the Runway's, CircleCI's, Dropbox's, Square's, and the collection at progression.fyi) all express the senior-to-staff transition in terms of scope, ambiguity and influence rather than technical difficulty, which is the structural basis for the six signals: the interview rubric follows the ladder.

Will Larson's Staff Engineer and Tanya Reilly's The Staff Engineer's Path both identify the same transition, with Larson's archetypes (tech lead, architect, solver, right hand) all defined by the shape of the scope rather than by depth, and Reilly's treatment of influence without authority as the distinguishing capability.

Google's hiring committee model, where a packet is read by people who were not in the room, is the documented reason quotable, written-down scope statements matter more than the impression left on any one interviewer.

Amazon's requirement that leadership-principle answers carry data, and its Bar Raiser role, are the clearest instance of a loop scoring on named dimensions rather than on a general impression.

Meta's published distinction between E5 and E6 impact is the same claim in different words: E5 is demonstrated by what you built, E6 by change across an organisation.

Structured-interview research consistently finds that defined dimensions with behavioural evidence predict performance better than unstructured impressions, which is why loops converge on rubrics and why speaking to the rubric is not gaming, it is answering the question asked.

The debate

Is technical depth still what matters? It is the price of entry and not the differentiator. A staff candidate who cannot go deep fails immediately, and a staff candidate who goes only deep gets a senior offer. The resolution is to demonstrate depth quickly and explicitly offer more, then spend the room's attention on the signals depth does not cover.

Should you consciously speak to the rubric? Yes, and it is not gaming. The rubric describes what the role requires, so an answer that omits influence and multiplier is not a modest answer, it is an answer to a different question. The failure mode is reciting the signals rather than evidencing them, and the distinction is whether the story contains a named disagreement and a number about someone else's output.

Do you need a story per signal? No, and trying produces six thin stories. Three or four strong stories that each carry three or four signals is the right shape, and the audit's purpose is to find the empty columns, which are almost always influence and multiplier.

Is the difference between senior and staff real, or is it politics? It is real and it is not about technical ability. The observable difference is whether the org changed, and that requires convincing people who do not report to you, which is a genuine skill with a genuine learning curve. The politics critique lands on the calibration process rather than on the distinction.

Should you admit a mistake? Yes, with the cost, and it scores on the risk and judgment axes rather than against you. A story with no regret in it reads as either unreflective or sanitised, and the strongest version names the mistake, its cost, and what you changed, which is what the candidate in the worked example did with the sequencing error.

Is it dishonest to reframe an existing story? No, as long as the facts do not change. The influence and multiplier content is usually already true and simply not mentioned, because the engineering is what felt like the work. Adding it is accuracy, not spin.

Follow-up Q&A

"What is the difference between a senior and a staff interview?"

The question being asked. Senior asks whether you can solve a problem; staff asks whether you can pick the problem, frame it, and get other people to solve it with you. That shows up on six axes: scope, from owning a service to owning a problem space across teams; ambiguity, from executing a spec to producing one; judgment, from picking a good option to explaining three and the reversal criteria; influence, from convincing your team to convincing peers who do not report to you; multiplier, from delivering to making others faster; and risk, from handling known risk to naming the one nobody else named.

"What is the most common way strong candidates fail a staff loop?"

Telling senior-level stories, extremely well. The story is about what they built rather than how the organisation changed, so an interviewer scoring scope hears one service, scoring influence hears nobody outside the team, and scoring multiplier hears one person's output. Every clause is true and the story argues for the level they already have. In one case two engineers described the same eighteen-month migration; the slightly stronger engineer spent 35 of 45 minutes on the technical design and received a senior offer, and the other spent 8 and received a staff offer.

"How do you make influence visible in a story?"

With a named disagreement and what it cost you. "I convinced the team" evidences nothing; "the platform lead thought it was the wrong layer and he was partly right, so I moved the boundary he objected to, which cost a quarter, and he then co-signed it, which is what got the other two teams to move" evidences all of it. A story where everyone agreed contains no influence, and interviewers hear that immediately.

"What is the strongest single thing to add on the judgment axis?"

The reversal criteria. Most candidates give the options and the choice; almost nobody says what would have to be true to change their mind. "I would revisit the single-writer design if write volume passed about forty thousand a second or if we needed sub-fifty-millisecond writes in Europe, and both were far enough away that I took the simpler thing" demonstrates that the decision was made against a model rather than a preference, which is the distinction the axis is measuring.

"How do you find the gaps in your own stories?"

Take your five best stories and mark which of the six signals each one evidences, honestly. It takes an hour. The two columns that are usually empty are influence and multiplier, and the fix is not to invent stories: that content is almost always already true and simply left out, because the engineering is the part that felt like the work. Quantify other people's output rather than your own, and name the disagreement you resolved.

"Why does what the interviewer can write down matter?"

Because the scoring artifact is a written assessment read by people who were not in the room, and at companies with a hiring committee or a calibration panel the packet is what is evaluated. Vague warmth does not survive transcription. A sentence with a boundary and a number does: "owned the event schema standard across four teams", "two consuming teams retired their own ingest, about one and a half engineers of recurring capacity". Give them quotable lines rather than a good impression.

Common misconceptions

"Staff is harder senior." It is a different question. Answering the senior question exceptionally well is the most common way to fail a staff loop.

"Depth is the signal." Depth is the price of entry. Demonstrate it quickly, offer more explicitly, and spend the remaining attention on what depth does not cover.

"Speaking to the rubric is gaming." The rubric describes the role. An answer omitting influence and multiplier is answering a different question, not being modest.

"I need a story for each of the six signals." Three or four stories carrying three or four signals each is the right shape. Six thin stories is worse than four strong ones.

"Admitting a mistake is risky." A story with no regret reads as unreflective or sanitised. The mistake with its cost and what you changed scores on judgment and risk.

"My influence content isn't interesting enough to mention." It is the content the level is defined by, and it is the column most commonly left empty by strong candidates.

Interview delivery note

Say this verbatim, when asked what you would bring at this level: "Senior is whether I can solve the problem. Staff is whether I can pick it, frame it, and get people who don't report to me to solve it with me. So the story I'd tell about that migration is less about the sharding scheme and more about the two teams who disagreed and the design change that resolved it." It states the distinction and then demonstrates that you know which story to tell.

The senior-versus-staff separator here is recursive and worth stating plainly: it is offering the depth rather than defaulting to it. Saying "I can go as deep as you like on the sharding scheme, and I'd rather spend the time on why we did this and what it cost to get agreement" gives the interviewer the choice, proves you have the depth available, and reallocates the room's attention to the axes that are actually being scored. In the worked example that single change, with no new content, moved an offer from senior to staff.

The second signal is the reversal criteria. Naming what would make you change your mind, with a threshold, is the cheapest and least-used way to demonstrate that a decision was reasoned rather than preferred, and it converts a judgment answer from an advocacy into an analysis.

Further reading

• Will Larson, Staff Engineer, and Tanya Reilly, The Staff Engineer's Path, for the scope-and-influence definition of the level.
• Published engineering career ladders (Rent the Runway, CircleCI, Dropbox, Square) and the progression.fyi collection, for the rubric the interview rubric follows.
• The architecture deep dive page, which is where these signals are most often won or lost, and the SCOR, STAR and the scar-tissue story page for the story structure that carries them.

The staff-level design interview

What it is

A 45 to 60 minute conversation in which you are given a deliberately vague problem and asked to design a system. What is being scored is not the design. It is whether you can take an ambiguous goal and produce the spec, which is the single largest behavioural difference between senior and staff.

The senior version of this round is: given requirements, produce a good architecture. The staff version is: given a sentence, produce the requirements, then the architecture, then name what you are trading away and under what conditions you would revisit.

Commonly confused with a whiteboarding test of knowledge. Knowledge is necessary and it is not what separates candidates; almost everyone at this level knows what a message queue is. What separates them is sequencing, committing to a decision, and saying what it costs.

The problem it solves

Most candidates run the round as: hear the prompt, draw boxes, connect the boxes, answer questions. That produces a design with no numbers in it, no stated requirements, and no evidence of judgement, and the feedback is invariably "solid engineer, didn't demonstrate staff scope".

The structure below exists to force three things the freeform version omits: requirements as numbers, the partition key decided deliberately, and the tradeoff stated rather than implied.

The structure

Timings for a 45-minute round. Say the plan out loud at the start; interviewers take notes in your structure, and announcing it buys you the benefit of the doubt for the next forty minutes.

1. Clarify and scope (5 minutes)

Not "who are the users" as a ritual. The questions whose answers change the design:

• "What is the read to write ratio?" (Decides caching, replication, whether you need a read model.)
• "How stale can a read be?" (Decides consistency, and therefore half the architecture.)
• "What is the p99 target and is that at the edge or at the service?"
• "What happens if we lose the last minute of writes? Is that an inconvenience or a financial loss?"
• "What is explicitly out of scope? Auth? Billing? Mobile?"

Write the answers on the board as numbers. A design round with no numbers on the board is a design round you lost, because every subsequent decision then has no justification.

If the interviewer will not give you a number, supply one and label it: "I'll assume 10 million daily actives and check that assumption if it starts driving the design." That is better than proceeding without, and it demonstrates the exact behaviour the round is testing.

2. Capacity math (3 minutes)

Out loud, on the board, with round numbers.

10M DAU x 20 actions/day  = 200M writes/day
200M / 86,400             = 2,300 writes/sec average
Peak 3-5x                 = ~10,000 writes/sec
Reads 50:1                = ~500,000 reads/sec  <- this is the design driver

2 KB/record x 200M/day    = 400 GB/day = 146 TB/year
Replication 3x            = 440 TB/year

500k reads/sec cannot come from a primary database.
=> the read path is a cache or a materialised read model. That decision is
   now made by arithmetic, not preference.

The value is not the numbers. It is that the arithmetic produced a constraint, and now every later decision can be justified by pointing at it. Interviewers consistently report that doing capacity math out loud is the single clearest separator, and it takes three minutes.

3. API contract (3 minutes)

Before any boxes.

POST /v1/posts            {content, media_ids}  -> {post_id, created_at}
GET  /v1/feed?cursor=&limit=  -> {items[], next_cursor}
POST /v1/posts/{id}/like  Idempotency-Key: <uuid>  -> {like_count}

Three things you get for free by doing this: pagination (cursor, not offset, and say why), idempotency on anything that mutates, and versioning. Each is a small thing that signals production experience, and all three take thirty seconds.

4. Data model and partition key (5 minutes)

This is where designs live or die and it deserves the time.

State the key and the reason in one sentence: "Partition by user_id because every read is scoped to one user, which keeps a feed read to a single partition. The risk is a celebrity with 50 million followers creating a hot partition, and I'll handle that with a separate path for high-fanout accounts."

The pattern to demonstrate: choose the key, name the failure mode it creates, say how you would detect and handle it. Choosing a key without naming its hot-key risk is the most common way to lose this section.

5. High-level architecture (10 minutes)

Draw at container level in C4 terms, and say you are doing so: deployable units and datastores, not classes and not individual machines. Label every arrow with a protocol and a rough rate.

Keep it to seven or eight boxes. A diagram with twenty boxes says you have not decided what matters, and you will not have time to defend any of them.

6. Deep dive (12 minutes)

Hand the choice to the interviewer: "The two hard parts here are fan-out on write versus read, and the hot-partition problem for celebrity accounts. Which would you like me to go into?"

That sentence does three things: it demonstrates you know which parts are hard, it respects their time, and handing someone a choice is itself a leadership behaviour being scored. Then go genuinely deep: actual data structures, actual failure handling, actual numbers.

7. Failure modes and operations (5 minutes)

The section almost nobody reaches, and the one that most distinguishes the answer.

• What pages? Not "we'd monitor it". Name the SLI and the alert: burn-rate alerting on the read-path availability SLO.
• What degrades, in what order? "Under load I'd drop personalised ranking before I'd drop the feed itself, and serve a chronological fallback. That's a product decision I'd want confirmed, and it's the kind of thing to agree before the incident."
• Blast radius. "Fan-out workers are partitioned by user, so a poison message affects one partition rather than the fleet."
• The rollout. "I'd ship this behind a flag, dual-write for a week, compare the outputs on a sample, then cut reads over by percentage."

8. Tradeoffs and 10x (2 minutes)

Close with the sentence the whole round is listening for, and say it at least twice during the session:

"The alternative here was X. I'm not choosing it because Y. If Z changed, I'd revisit."

Concretely: "The alternative to fan-out on write is fan-out on read, which I'm not choosing because the read:write ratio is 50 to 1 and read latency is the product requirement. If the follower graph got much denser, or if write volume grew faster than reads, I'd revisit. The crossover is roughly where average fanout exceeds the read amplification."

A worked micro-example: the first four minutes

Prompt: "Design a notification system."

Weak opening: "So we'd have a service that takes events, puts them on a queue, and workers send them out. Let me draw that."

Strong opening:

"Before I draw anything, let me pin down scope, because 'notification system' spans three very different products. Are we doing transactional notifications (your order shipped) or engagement notifications (someone liked your post)? The first is low-volume and must not be lost; the second is high-volume and can be dropped under load. Which are we building?"

"Say both. Then I want four numbers: peak notifications per second, the channels (push, email, SMS, in-app), the latency requirement per channel, and whether we own delivery or hand off to a provider. I'll assume 50,000 per second at peak, four channels, sub-30-second delivery for push, and third-party providers for push and email."

"One more: what's the delivery guarantee? At-least-once with client-side dedupe is much cheaper than exactly-once, and for engagement notifications a rare duplicate is acceptable while a missed order confirmation isn't. I'll design at-least-once with idempotency keys, and treat the transactional path as the one with the strict requirement."

Four minutes, and the interviewer now knows you can produce a spec. Everything after that is downhill, because every decision has a stated requirement to point at.

Production evidence

Google's hiring guidance for L6 and above is explicit that hiring committees read a written packet, which means your interviewer must be able to write down your scope and judgement. Answers that are hard to summarise score badly regardless of quality, which is the practical reason for structure and for quotable sentences.

Amazon's bar raiser process weights whether the candidate identified the right problem, not only whether they solved the stated one, and their Leadership Principles include "Dive Deep" specifically to test whether the reasoning survives three layers of follow-up.

The C4 model (Simon Brown) gives you the vocabulary to say which zoom level you are drawing at, which removes an entire class of confusion in a design conversation. Narrating "I'm drawing at container level" is cheap and reads as structured communication.

Kleppmann's Designing Data-Intensive Applications is the shared reference for the technical content of these rounds, particularly chapters 5 to 9, and its vocabulary (partitioning, replication, consistency models) is the one interviewers use.

The debate

The case against a rigid structure: it can read as rehearsed, and a good design conversation is collaborative rather than a presentation. Some interviewers explicitly want to see how you think when you are not following a script, and a candidate marching through eight phases while the interviewer is trying to probe something specific has stopped listening.

The case for it: without structure, most candidates omit capacity math, never state the partition key rationale, and run out of time before failure modes. Those three omissions are the most common feedback in this round, and structure fixes all three.

My position: use the structure as a checklist, not a script. Announce it at the start so the interviewer knows where you are going, then abandon it instantly when they steer. The one thing to protect regardless of how the conversation goes is the capacity math, because it is the cheapest and most reliable signal you can produce, and it makes every later decision defensible.

The structure is the wrong approach when the interviewer opens with a specific deep question ("how would you shard this?"), in which case answer it and work outward; or in a domain deep-dive where the point is depth in one component rather than breadth across a system.

Follow-up Q&A

"Walk me through how you'd run a design round." Clarify and scope for five minutes, getting non-functional requirements as numbers on the board. Capacity math out loud for three, because the arithmetic produces the constraint that justifies everything after it. API contract before boxes. Data model and partition key with the hot-key failure named. Architecture at container level, seven or eight boxes, arrows labelled with protocol and rate. Then hand the interviewer the choice of deep dive. Then failure modes, degradation order and blast radius. Then the tradeoff sentence.

"What if the interviewer won't give you requirements?" Supply them and label them. "I'll assume 10 million daily actives; tell me if that's the wrong order of magnitude." Refusing to proceed without numbers reads as inflexible, and proceeding without any is what the round is testing you against. Stating an assumption and checking it when it becomes load-bearing is exactly the behaviour being scored.

"How do you handle a question you can't answer?" State the boundary, reason from adjacent knowledge, and name how you would find out. "I haven't run Scylla in production. Here's what I'd expect to transfer from Cassandra, here's where the shard-per-core model should change the tuning story, and here's what I'd benchmark first." Never bluff: at this level interviewers probe two layers past your claimed knowledge specifically to find it, and one caught bluff outweighs several strong answers.

"You're running out of time and you're only halfway through the architecture." Say so and hand over the tradeoff: "We have ten minutes. I can finish the architecture at a high level, or go deep on the ranking service, which I think is the harder problem. Which is more useful?" Managing the clock out loud is a leadership behaviour and it is being scored; running out of time silently is not.

"What's the single biggest differentiator in this round?" Doing capacity math out loud, and then using the result to justify a decision. It takes three minutes, almost nobody does it, and it converts every subsequent choice from preference into consequence. Second place is naming the failure mode of your own partition key before being asked.

Common misconceptions

The most common is that this round tests knowledge of components. It tests whether you can produce a specification from ambiguity and defend a decision under pressure. A candidate who knows fewer technologies but states requirements as numbers and commits to a tradeoff will out-score one who names more systems.

The second is that more boxes is more thorough. A twenty-box diagram means you have not decided what matters and cannot defend any of it in the time available.

The third is that saying "it depends" is safe. It is safe and it is worthless unless immediately followed by the variables it depends on and a committed default. Conditional then decisive: "it depends on read:write ratio and staleness tolerance, and for what you've described I'd pick X."

Interview delivery note

Open by announcing the structure: "I'll spend about five minutes on requirements, three on capacity math, then the API and data model before I draw anything, and I'd like to leave ten minutes for failure modes. Stop me whenever you want to go deeper."

Then protect two things above all: the capacity math, because it is the cheapest signal available and it makes every later decision defensible; and the tradeoff sentence, said at least twice: "the alternative was X, I'm not choosing it because Y, and if Z changed I'd revisit."

The depth signal in this round is naming the failure mode of your own choice before being asked. Anyone can defend a design. Volunteering "the risk with this partition key is a hot partition on celebrity accounts, here's how I'd detect it and here's the separate path I'd build" is what a staff-level answer sounds like.

Further reading

• Kleppmann, Designing Data-Intensive Applications, chapters 5 to 9, for the technical vocabulary these rounds are conducted in.
• Simon Brown's C4 model, for naming the zoom level you are drawing at.
• Public engineering blogs from Uber, Netflix, Discord, Cloudflare and Stripe, read for the shape of how they present a design rather than for the specific systems.
• Public design documents (Kubernetes KEPs, Kafka KIPs, Rust RFCs) as training material for the design-review round, which uses the same skills in reverse.

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.

Further reading

• Public RFC processes, Rust RFCs, Kubernetes KEPs and Kafka KIPs, as free and realistic practice material for the design-doc-review format.
• Conventional Comments (conventionalcomments.org), for the comment taxonomy the code review round scores.
• Google's SRE Book chapter on managing incidents, for the mitigate-before-diagnose principle and the role structure to name.
• The incident management page for the loop in operational depth, and PR review as a leadership lever for the review order and taxonomy applied to a real team.

Company loop formats

What it is

Loops differ less in what they ask than in what they weight, and the weighting is a consequence of what each company has decided its failure mode is. Knowing the shape tells you where to spend preparation time, which is the only actionable thing about it.

A warning that belongs at the top rather than in a footnote: formats change, often within a year, and the only current source is your recruiter. Everything below is the shape as publicly reported and as commonly described by candidates. Ask the recruiter for the round list and the rubric before you plan anything, and treat what follows as a prior to be updated rather than a schedule.

The durable question, per company, is not "how many rounds"
but:

  what does this company believe goes wrong when they hire
  badly, and which round is the one that exists to catch it?

What this is confused with: loop trivia as preparation. Knowing that a company runs two coding rounds does not help. Knowing that its coding rounds are two problems in forty-five minutes, so speed rather than depth is the failure mode, changes what you practise.

Also confused: the loop and the bar. Two companies with identical formats can have very different bars, and the format tells you what to prepare rather than how hard it will be.

The problem it solves

Preparation time is finite and defaults to whatever you are already comfortable with.

A candidate with 60 hours of preparation, spread evenly:
  20h algorithms
  20h system design
  20h behavioural

Against a loop that is 10 to 16 leadership-principle
questions plus a bar raiser, this allocation is wrong by a
factor of about three on the axis that decides the outcome.

Against a loop that is two problems per 45-minute coding
round, the 20 hours of algorithms were spent on depth when
the failure mode is speed.

Same 60 hours. The allocation is the whole decision, and it
should be made from the loop rather than from habit.

And the second failure: preparing for a format that does not exist there.

Drilling distributed-systems design for a loop whose design
round is a product-shaped question about a matching system
with geographic constraints. Both are "system design" and
they reward different preparation.

Mechanics

The shapes, and what each is defending against

These are reported shapes, not guarantees. Verify with the recruiter.

GOOGLE (staff / L6, TLM)
  Reported shape: two coding rounds, one or two system
  design, one leadership-and-"Googleyness".
  WHAT IT DEFENDS AGAINST: hiring someone whose scope cannot
  be written down. A hiring committee reads a packet and was
  not in the room, so your interviewers must be able to
  RECORD your scope in a sentence.
  Consequence for you: give quotable lines. "Owned the event
  schema across four teams" survives transcription; a good
  impression does not.
  Design rounds reported to go deep on data modelling and
  failure handling.
  Rough weighting: coding 30, design 40, leadership 30.

META (E6, engineering manager)
  Reported shape, IC: two coding rounds with TWO PROBLEMS
  EACH in 45 minutes, one system design, one behavioural.
  EM: system design, people management, a project
  retrospective, sometimes coding.
  WHAT IT DEFENDS AGAINST: slowness. The two-problems-in-45
  format is the format, and candidates fail it on pace
  rather than on ability.
  Consequence: practise the pace explicitly, timed, two
  problems, not one hard problem slowly.
  E6 requires org-level impact: "I built X" reads as E5,
  "I changed how three teams do X" reads as E6.

AMAZON (principal / L7, SDM)
  Reported shape: leadership principles dominate, 10 to 16
  LP questions across the loop, plus a Bar Raiser, plus
  system design and for senior levels a technical-vision
  discussion.
  WHAT IT DEFENDS AGAINST: a hiring manager lowering the bar
  under headcount pressure, which is what the Bar Raiser
  exists for, and unsubstantiated claims, which is what
  "Dive Deep" enforces.
  Consequence: two stories per principle, sixteen
  principles, and EVERY answer carries data. "Dive Deep"
  means they will ask for the number three layers down, and
  "we improved latency significantly" fails.
  This is the most story-intensive loop in the industry and
  it is the one where preparation volume most directly
  converts into outcome.

STRIPE
  Reported shape: an integration round building against a
  real API, a debugging round fixing a broken repository,
  system design, and a values round.
  WHAT IT DEFENDS AGAINST: candidates who can whiteboard and
  cannot ship. Practical over algorithmic.
  Consequence: your editor fluency, your debugging method
  and your comfort in an unfamiliar codebase are all
  visible. Rough weighting: debugging and pragmatic coding
  50.

NETFLIX (senior / staff)
  Reported shape: deep technical conversation, culture-memo
  alignment as a genuine filter, and an expectation that you
  justify autonomy.
  WHAT IT DEFENDS AGAINST: someone who needs process. The
  culture is context-not-control and the keeper test, and a
  candidate who describes their success in terms of the
  process around them reads as a poor fit.
  Consequence: prepare to describe decisions you made
  without asking, and be able to discuss the culture memo
  substantively rather than reciting it.
  Rough weighting: deep dive 40, culture 30, design 30.

DATABRICKS / SNOWFLAKE / CONFLUENT
  Reported shape: hard distributed-systems internals plus
  genuinely hard coding.
  WHAT IT DEFENDS AGAINST: shallow familiarity. Expect query
  execution, storage formats, consistency models and
  concurrency at a level where "eventually consistent" as a
  phrase is not an answer.
  Consequence: storage and streaming internals are roughly
  half the preparation.

UBER / LYFT / DOORDASH
  Reported shape: high-scale system design with real domain
  constraints, geo, matching, dispatch, pricing; coding
  medium-hard.
  WHAT IT DEFENDS AGAINST: generic design answers. The
  design round is the differentiator and it has domain
  physics in it: a matching system has a spatial index, a
  supply-demand imbalance, and an interference problem that
  a generic "put a queue in front of it" answer does not
  touch.

SHOPIFY (Toronto)
  Reported shape: a "Life Story" interview walking through
  your career, pair programming in a real repository, and a
  technical deep dive.
  WHAT IT DEFENDS AGAINST: a rehearsed highlight reel. The
  life-story format wants a narrative arc with reasons, not
  a list of jobs.
  Consequence: prepare the arc, including the transitions
  and why you made them. Pair programming in a real repo
  means the same unfamiliar-codebase skill Stripe tests.

OPENAI / ANTHROPIC / AI LABS
  Reported shape: practical coding, often agentic, working
  in a real codebase with real tools; a take-home with a
  follow-up deep dive; strong emphasis on judgment and
  safety-mindedness.
  WHAT IT DEFENDS AGAINST: people who cannot move in
  unfamiliar code, and people with no considered position on
  risk.
  Consequence: practise contributing a real fix to an
  open-source repository you have never seen, timed. And
  have a considered, non-performative view on where the
  systems you build can cause harm.

NVIDIA / CISCO / SYSTEMS COMPANIES
  Reported shape: performance, concurrency, memory,
  profiling; C++ and systems questions where the role is
  close to the metal.

Turning a shape into an allocation

Ask the recruiter, in one message:
  - the round list, with durations
  - whether coding is one problem or two per round
  - whether the design round is distributed-systems or
    product/domain shaped
  - whether there is a take-home, a debugging round, or a
    pairing round
  - who the bar-raising or committee function is, if any
  - the level being interviewed for, and the band

Most recruiters answer all of it. The information changes
your allocation more than any amount of general study.

Then allocate:
  the round most likely to fail you   40%
  the round with the most weight      30%
  everything else                     30%

Those are often different rounds, which is the point of
asking.

The universal preparation, which is most of it

Whatever the shape:

  4 to 6 STORIES that each carry three or four of the six
    signals, tellable in three minutes.
  ONE DEEP DIVE, 45 minutes, at three zoom levels, with
    numbers, alternatives and regrets.
  DESIGN FLUENCY: capacity arithmetic out loud, three
    consistency models and when each is acceptable, a
    multi-region write path, a migration and rollback plan.
  CODING at the pace the loop requires, which you established
    by asking.
  THE QUESTIONS you will ask, per interviewer.

That set covers 80% of every loop above. The company-specific
work is the last 20% and it is an allocation decision rather
than new material.

A worked example: the same candidate, three loops

A senior engineer targeting staff, interviewing at three companies over four months, with roughly the same 50 hours of preparation available before each.

Loop 1, a large consumer company, prepared by habit:

Allocation: 20h algorithms, 20h system design, 10h stories.

The loop, as it turned out: two coding rounds at two
problems per 45 minutes, one design, one behavioural.

Result: failed both coding rounds on pace. Solved the first
problem in each round well and ran out of time on the
second.

The candidate's post-mortem: "I'd practised hard problems
slowly. The round is medium problems fast, and those are
different skills. I never asked."

Loop 2, a company with a principle-based loop, prepared after asking:

Recruiter's answer to one email: fourteen leadership-
principle questions across five rounds, a bar raiser, one
system design.

Reallocation: 35h stories, 10h design, 5h coding.

Preparation specifics:
  - two stories per principle, sixteen principles, which is
    thirty-two story slots filled by about eleven underlying
    projects told from different angles
  - every story rebuilt to carry a NUMBER, because "dive
    deep" means the follow-up asks for the metric three
    layers down
  - practised the follow-up chain out loud: "how much did it
    improve" -> "how did you measure that" -> "what was the
    baseline" -> "who else could confirm that number"

Result: offer.

The candidate's note: "the third and fourth follow-up is
where people fall apart. I'd never rehearsed past the second."

Loop 3, a practical-shaped loop, prepared after asking:

Recruiter's answer: an integration round against a real API,
a debugging round on a broken repository, one design, one
values round.

Reallocation: 20h unfamiliar-codebase practice, 15h design,
10h stories, 5h API integration.

The unfamiliar-codebase practice, which was the new thing:
  cloned four open-source repositories, had a friend
  introduce a bug in each, fixed them timed, narrating the
  hypothesis-and-disproof loop out loud.

Result: offer, and the debugging round was the strongest
score in the loop.

The candidate's note: "I've debugged for eleven years and
had never done it out loud in someone else's code with a
clock running. Four practice runs was the difference."

Across three loops with the same total preparation time, two offers and one failure, and the failure was the one where the allocation was made from habit rather than from the format.

What the one email was worth:

Time to write the recruiter email:        ~5 minutes
Time to read the answer:                  ~2 minutes
Change in allocation it produced:         substantial in
                                          both cases
Cost of not sending it in loop 1:         the loop

There is no preparation activity with a better ratio, and
almost nobody does it.

Production evidence

Amazon's Leadership Principles and Bar Raiser program are publicly documented by Amazon, including the Bar Raiser's authority to block a hire independently of the hiring team, which is the mechanism behind the loop's story intensity and its data requirement.

Google's hiring committee model, where a packet is assembled and reviewed by people who did not conduct the interviews, is publicly described and is the direct reason interviewers must be able to write down a candidate's scope in a transcribable sentence.

Netflix's culture memo is published and is explicitly used as a filter; its "context not control" and keeper-test framing are the substance a Netflix loop expects a candidate to engage with rather than recite.

Stripe's engineering blog and its published interview guidance describe an integration round and a debugging round against real code, with a stated preference for practical over algorithmic assessment.

Shopify's "Life Story" interview is publicly described in its own hiring materials as a structured walk through a candidate's career rather than a competency grid.

AI labs' emphasis on agentic and unfamiliar-codebase work is visible in their published role descriptions and in candidate reports, and it follows directly from the work: the job involves moving quickly in large codebases with tooling assistance.

All of the above shift. Public reporting lags by months to years, which is why the recruiter is the only current source and why this page's most important content is the instruction to ask.

The debate

Is it worth learning company-specific formats? Worth asking about, not worth memorising. The company-specific work is roughly the last twenty percent of preparation and it is an allocation decision rather than new material, and the eighty percent, stories, a deep dive, design fluency, coding at the required pace, is shared.

Is Amazon's loop excessive? It is the most story-intensive in the industry and it is also the most predictable, which cuts both ways. The volume is genuinely large, and the return on preparation is higher there than anywhere else because the rubric is published and the format is stable. The critique that lands is that it rewards preparation time, which is not evenly available.

Do two-problems-per-round formats measure the right thing? They measure speed on medium problems, which is a real and narrow skill. The defence is that it correlates with fluency; the objection is that it selects against people who think before typing, which is a disposition many good engineers have. Either way it is the format, and losing to it while being capable of the problems is a preparation failure rather than an ability one.

Are practical loops (Stripe, Shopify, AI labs) better? They resemble the job more closely and they are harder to prepare for by drilling, which is arguably the point. The asymmetry is that a candidate who has never worked in an unfamiliar codebase under time will underperform their ability, and four timed practice runs closes most of that gap.

Should you tailor stories per company? The framing yes, the facts no. The same project told against Amazon's principles, Meta's org-impact bar and Netflix's autonomy expectation emphasises different clauses, and inventing content to fit is both dishonest and detectable, because the follow-up chain goes three or four questions deep.

Is the recruiter a reliable source? For format and level, yes, and they are usually willing. For difficulty and for what the specific interviewer will ask, no. The failure is not asking at all, which in one case cost a loop that the candidate was technically capable of passing.

Follow-up Q&A

"How do you prepare for a loop whose format you do not know?"

Ask the recruiter, in one email: the round list with durations, whether coding is one problem or two per round, whether the design round is distributed-systems or product-shaped, whether there is a take-home, debugging or pairing round, whether there is a bar-raising or committee function, and the level and band. Most recruiters answer all of it. Then allocate roughly 40 percent to the round most likely to fail you, 30 to the round with the most weight, and 30 to everything else, which are frequently different rounds. Five minutes of email changes the allocation more than any amount of general study.

"What is the durable question about a company's loop?"

Not how many rounds, but what that company believes goes wrong when they hire badly and which round exists to catch it. Amazon's Bar Raiser defends against a hiring manager lowering the bar under headcount pressure. Google's committee model defends against a hire whose scope nobody can write down, which is why quotable lines matter more than a good impression. A two-problems-per-45-minutes coding round defends against slowness. Stripe's debugging round defends against candidates who can whiteboard and cannot ship. Each implies a different preparation.

"What is specific about preparing for a principle-based loop?"

Volume and data. Two stories per principle across sixteen principles is thirty-two slots, usually filled by about a dozen underlying projects told from different angles. Every story must carry a number, because "dive deep" means the follow-up asks for the metric three layers down. And rehearse the follow-up chain past the second question: how much did it improve, how did you measure it, what was the baseline, who else could confirm that number. In one loop the candidate's note was that the third and fourth follow-up is where people fall apart and they had never rehearsed that far.

"How do you prepare for a debugging or pairing round in an unfamiliar codebase?"

By practising in an unfamiliar codebase, which most people never do because they debug their own code daily and assume it transfers. Clone four open-source repositories you have never seen, have someone introduce a bug in each, and fix them timed while narrating the hypothesis-and-disproof loop out loud. In one case four practice runs turned a format the candidate had never performed into the strongest score in their loop, after eleven years of debugging professionally without ever doing it out loud with a clock running.

"Should you tell different stories at different companies?"

Same stories, different emphasis. The same migration told against Amazon's principles foregrounds the data and the dive-deep detail; told against Meta's E6 bar it foregrounds how three teams changed; told at Netflix it foregrounds the decisions you made without asking permission. Inventing content to fit is both dishonest and detectable, because the follow-up chain goes three or four questions deep and fabricated detail does not survive it.

"How current is any published information about loops?"

Not current enough to rely on. Formats change within a year, public reporting lags by months to years, and the only reliable source is the recruiter for that role at that moment. Treat any written description, including this one, as a prior to be updated by one email rather than as a schedule, and note that this also applies to advice from a friend who interviewed there eighteen months ago.

Common misconceptions

"Knowing the round count is preparation." It is trivia. Knowing that the coding round is two problems in forty-five minutes, so pace rather than depth is the failure mode, changes what you practise.

"System design is system design." A distributed-systems design round and a domain-shaped design round about matching or dispatch reward different preparation, and both are called system design.

"The behavioural round is the easy one." At a principle-based loop it is ten to sixteen questions with a data requirement and a follow-up chain three or four questions deep, and it is where the loop is decided.

"I debug every day, so a debugging round is free." You debug your own code. The round is unfamiliar code, under time, narrated, which is a different performance.

"Published loop descriptions are accurate." They lag by months to years, and formats change. The recruiter is the only current source.

"Preparation time is fungible." Sixty hours allocated by habit against a loop whose failure mode you did not ask about is the most common way a capable candidate fails.

Interview delivery note

There is no line to deliver here; the deliverable is the email. Send the recruiter one message asking for the round list with durations, whether coding is one problem or two per round, whether the design round is distributed-systems or domain-shaped, whether there is a take-home or debugging round, and the level and band. It takes five minutes, most recruiters answer all of it, and it changes your allocation more than any other single activity.

The senior-versus-staff separator is allocating preparation from the format rather than from habit. A senior candidate studies what they enjoy studying. A staff candidate asks what the loop is, identifies which round is most likely to fail them (which is usually not the one with the most weight), and puts forty percent of the time there. In one case the same fifty hours produced a failure and then two offers, and the only difference was that the allocation for the second and third loops was made from the recruiter's answer.

The second signal is treating every published description, including this page, as a prior. Saying "the shape as reported is X, and I asked the recruiter and it is now Y" demonstrates the same disposition as re-measuring a number in a DR document rather than trusting the one written two years ago.

Further reading

• Amazon's published Leadership Principles and its description of the Bar Raiser role.
• Netflix's culture memo, which is a genuine filter rather than a document to recite.
• Stripe's and Shopify's published hiring and interview materials, for the practical and life-story formats.
• Your recruiter, who is the only current source and who will usually answer all of it in one message.
• The what gets scored page for the signals every loop shares, and the rounds nobody prepares for for the formats this page tells you to expect.

Differentiators, and interview-day mechanics

What it is

Two things that sit either side of the interview itself: the small number of behaviours that make a director remember you, and the physical and logistical mechanics that decide whether you perform at your actual level on the day.

DIFFERENTIATORS, roughly by how few candidates do them:

  bring an artifact                       almost nobody
  send a 30/60/90 plan after the onsite   almost nobody
  know their public engineering output    few
  speak in operational metrics            few
  name your own gap before they find it   few
  hold a defended technical opinion       some
  send a follow-up that ADDS something    some
  prepare the questions you would ask the
    team in week one                      almost nobody

MECHANICS, which decide whether the above lands:

  whiteboard and remote setup
  the order you draw things in
  stamina across a five-hour loop
  what you do in the ten minutes between rounds

What this is confused with: differentiators as flourishes. They are cheap and they are decisive at the margin, which is where most staff decisions live: a loop where four interviewers say "hire" and one says "not sure" is decided by whatever the hiring manager remembers.

Also confused: mechanics as trivia. A candidate who is exhausted by round four performs a level below themselves in the two rounds that are usually the leadership ones, and those are the rounds a staff decision turns on.

The problem it solves

Most staff loops end with a set of positive assessments that are hard to distinguish.

Five candidates, all technically adequate, all with good
stories. The debrief:

  "Strong. Good design round."
  "Solid. Nothing concerning."
  "I'd hire."
  "Good communicator, deep on the storage question."
  "Strong. I liked them."

The hiring manager has to pick. What they pick on is whatever
is MEMORABLE and SPECIFIC, and in the absence of anything
memorable they pick on rapport, which is the mechanism by
which loops select for similarity.

An artifact, a 30/60/90 plan, a defended opinion and a
follow-up that continues the design discussion are four
memorable, specific things, and they cost a total of about
four hours.

And the mechanics problem is measurable in a way people do not expect:

A five-round onsite, 09:00 to 15:00.

Rounds 1 and 2: sharp.
Round 3: fine.
Rounds 4 and 5: noticeably slower, more hedging, worse
  recall of numbers.

Rounds 4 and 5 at most companies are the leadership and
hiring-manager rounds, which is where a staff decision is
made.

The candidate's ability did not change. Their blood sugar,
hydration and cognitive load did, and none of that was
planned for.

Mechanics

The eight differentiators

1. Bring an artifact.

A one-page architecture diagram of something you built,
sanitised. Or a design doc you can share. Or the
before-and-after of a migration.

Why it works: the deep-dive round is you describing a system
from memory while an interviewer tries to hold it in their
head. A diagram removes that load entirely and changes the
conversation from reconstruction to discussion.

Practical: bring it as a PDF you can screen-share and as a
paper copy if in person. Sanitise properly, remove customer
names, internal hostnames and anything under NDA, and SAY
that you have sanitised it, which is itself a signal about
judgment.

Almost nobody does this.

2. Send a 30/60/90 plan after the onsite.

One page, for THEIR team, sent within 48 hours.

  FIRST 30: listen and map. Name what you would read, who you
    would meet, what you would measure. Specificity is the
    whole thing: "read the last two quarters of incident
    reports and the on-call handover notes" beats "get up to
    speed".
  60: one visible fix. Something small, real and derived from
    what you learned in the loop.
  90: a proposal. A direction, with the evidence you would
    have gathered by then to support it.

Include the caveat that makes it credible: "this is written
from the outside, so half of it is probably wrong; the point
is how I would approach the first quarter."

For a lead role this is close to decisive, and the reason is
that it is the only artifact in the whole process that shows
what you would DO rather than what you have done.

3. Know their public engineering output.

Their engineering blog, conference talks, open source, RFCs.

Reference it SPECIFICALLY: "in your post on the sharding
migration you mentioned the dual-write window ran longer than
planned; how did that land?"

Two hours of reading. It changes the interviewer's model of
you from "candidate" to "someone who is already interested in
our problems", and the specific reference is what does it: a
general "I read your blog" does the opposite.

4. Speak in operational metrics.

p99, error budget, DORA metrics, cost per query, on-call
pages per week, toil percentage, cycle time.

A lead who talks about cost and toil sounds senior
immediately, because those are the two things engineers
under-report and managers care about.

  weak:   "we improved performance"
  strong: "p99 went from 800ms to 120ms, which mattered
           because checkout conversion moves measurably below
           about 400ms, and it cut our compute bill by 22%
           because we stopped over-provisioning for the tail"

5. Name your own gap before they find it.

"The gap in my background is that I have never run a team
 through a reorganisation, and here is how I would approach
 it in the first quarter."

Why it works: the gap is going to be found. Naming it first
converts a concern into evidence of self-awareness, and it
lets you frame the mitigation rather than defend against the
objection.

The failure mode is naming a fake weakness ("I care too
much"), which is worse than saying nothing.

6. Hold a defended technical opinion.

Not a hot take. A position, in their domain, with the
reasoning and the conditions under which you would change it.

  "I think most teams adopt a service mesh a year too early.
   The cost is per-pod memory and a debugging surface nobody
   has skills for, and the benefit only exceeds a library
   approach once you have more than about two languages or a
   policy that changes faster than code ships. I would ask
   which of those is true here."

Directors hire people with a point of view, and the
reversal condition is what distinguishes an opinion from an
attitude.

7. Send a follow-up that adds value, not thanks.

Within 24 hours, because the debrief is fast.

  weak:   "Thank you for your time, I enjoyed our
           conversation."
  strong: one paragraph continuing the design discussion, or
          the diagram you sketched on the whiteboard, cleaned
          up and attached.

And the highest-value version: if you asked whether anything
about your background gave them hesitation, this is where you
answer it. If you flubbed something and know it, correct it
in one line: "I said X for the quorum math; on reflection
it's Y." That correction has rescued candidacies, because it
demonstrates exactly the self-correction the loop is trying
to measure.

8. Prepare the questions you would ask the team in week one.

A short list, shared at the end of the hiring-manager
conversation or in the follow-up:

  "What is the thing everyone knows is broken and nobody has
   time to fix?"
  "When were you last paged at night, and what was it?"
  "What decision is currently stuck?"
  "What would you want a new lead to NOT change in the first
   month?"

Sharing this signals that you already think like the lead,
and it is the cheapest of the eight.

Whiteboard and remote mechanics

DRAWING ORDER, which matters more than drawing quality:

  1. the USER and the request, at the left
  2. the boxes, left to right, in request order
  3. the data stores, below the services that own them
  4. the arrows, labelled with the PROTOCOL and the
     approximate volume
  5. only then the detail

Reserve space before you start. The most common whiteboard
failure is running out of room and redrawing, which costs
three minutes and the interviewer's attention.

WRITE THE ASSUMPTIONS IN A CORNER and keep them visible:
QPS, data size, latency target, consistency requirement.
You will refer back to them, and an interviewer who can see
them can follow your reasoning.

SAY WHAT YOU ARE DRAWING while you draw it. Silence with a
marker is the least informative state in the interview.

REMOTE SETUP, and this is a preparation task, not a
last-minute one:

  - test the tool THEY use, not the one you like. Excalidraw,
    Miro, CoderPad and a shared Google Doc all behave
    differently and the first two minutes of a round is a
    bad time to learn one.
  - a second monitor, so the diagram and the faces are both
    visible
  - a wired connection if at all possible
  - camera at eye level, light in front of you rather than
    behind
  - your notes on paper, not on screen, because reading from
    a screen is visible and reading from paper is not
  - a glass of water and something to eat, in reach
  - phone silenced, notifications off at the OS level,
    including calendar popups that will show your other
    interviews

PRACTISE DRAWING IN THE TOOL. Diagramming fluency in
Excalidraw is a skill with a learning curve, and spending it
during the round costs you the design round.

Stamina

A five-round onsite is four to six hours of sustained
performance, which almost nobody trains for.

  EAT BEFORE, and eat something in the middle. A 45-minute
    round at hour five on no food is measurably worse.
  WATER, continuously.
  THE TEN MINUTES BETWEEN ROUNDS: stand up, look out of a
    window, do not review notes. Reviewing notes between
    rounds raises anxiety and changes nothing, and the
    recovery is worth more.
  RESET DELIBERATELY. Each round has a new interviewer who
    has not seen the previous one. A bad round is not
    carried forward unless you carry it. Say to yourself,
    explicitly, that the last round is over.
  THE FIRST MINUTE of each round: ask what they would like to
    cover and how long they have. It buys you thirty seconds
    of orientation and it makes you look organised.

SCHEDULE, where you have a choice: not first thing Monday,
not last thing Friday, not the day after a release. And put
NOTHING else in that day.

IF A ROUND GOES BADLY, say so once at the end, briefly, and
move on: "I don't think I did that problem justice; I'd
approach it differently with more time." Then reset. Nothing
is gained by carrying it and something is lost.

A worked example: two candidates, one memorable

Two candidates at final stage for a team lead role, both assessed as technically capable, both with good stories. The hiring manager had one headcount.

Candidate A's loop:

Five rounds, all "hire" or "strong hire". Good design round,
solid deep dive, competent leadership answers.

Follow-up email, same day: three sentences of thanks.

Debrief comments:
  "Strong. Good communicator."
  "Would work well with the team."
  "Hire."

Candidate B's loop:

Five rounds, four "hire" and one "strong hire". Marginally
weaker on the coding round.

BUT:

Brought a sanitised one-page architecture diagram to the deep
dive, screen-shared it, and said "I've removed the customer
names and internal hostnames; happy to go into anything on
here."
  -> the deep dive spent 30 minutes on the diagram's
     failure-handling section rather than 15 minutes on the
     candidate reconstructing the system from memory

Referenced the company's engineering blog specifically:
"your post on the ingestion rewrite mentioned the backfill
took three weeks longer than planned; was that the schema
inference or the throughput?"
  -> the interviewer, who had written the post, spent ten
     minutes on it and mentioned it in the debrief

Named their own gap unprompted: "I've never run a team
through a reorg, and if that's a concern here I'd want to
talk about how I'd approach it."
  -> the hiring manager's note: "raised the thing I was
     going to ask about, before I asked"

Held a defended opinion on a technology the team was
evaluating, including the condition that would change their
mind.

Sent, 36 hours after the onsite:
  - a one-page 30/60/90 plan for the team, with the caveat
    that half of it was probably wrong
  - the whiteboard diagram from the design round, redrawn
    cleanly
  - one paragraph continuing a disagreement from the design
    round, conceding a point the interviewer had made

Debrief comments:
  "Brought a diagram. Nobody does that."
  "The 30/90 plan is the first one I've received. Half of
   it is wrong and the half that's right is the half I'd
   have wanted them to notice."
  "Raised their own gap before I did."

Candidate B was offered, and the hiring manager's stated reason was the 30/60/90 plan.

The cost accounting, which is the point:

diagram (sanitising an existing one)        ~1.5 hours
reading their engineering blog              ~2 hours
30/60/90 plan                               ~2 hours
follow-up email with the redrawn diagram    ~45 minutes
-------------------------------------------------------
                                            ~6 hours

Against roughly 60 hours of technical preparation, and it
was the deciding factor between two candidates the loop
could not separate.

And the honest part, recorded by the hiring manager afterwards:

"A was probably the slightly better engineer. B showed me
what they would do with the job, and A showed me what they
had done with the last one. For a lead role that is the
question I was actually asking, and only one of them
answered it."

The stamina finding, from the same candidate's earlier failed loop:

Four months earlier, B had failed a loop at a different
company. Their own reconstruction:

  09:00 coding        strong
  10:00 coding        strong
  11:00 system design good
  12:00 (no break; lunch was a 30-minute call with the
        recruiter)
  13:00 deep dive     "I couldn't remember numbers I know
                       cold. I said 'roughly' four times."
  14:00 leadership    "I rambled. I could hear myself
                       rambling."

Debrief: strong on the technical rounds, weak on the two
that decide a staff hire.

What changed for the next loop: ate before, ate at the
break, refused the working lunch, stood up between every
round, and did not look at notes after 09:00.

The two afternoon rounds in the successful loop were the two
strongest scores.

"The two rounds that decide a staff hire are the two you are most tired for" is a scheduling fact, not a performance one, and it is fixable with food, water and a refusal to take a working lunch.

Production evidence

Amazon's Bar Raiser process and Google's hiring committee both make the written debrief the decisive artifact, which is the structural reason a memorable, specific detail outweighs a marginally stronger performance: the committee reads what was written down, and "brought a diagram" is written down.

Structured-interview research consistently finds that in the absence of distinguishing evidence, evaluators fall back on similarity and rapport, which is the mechanism a differentiator interrupts: it supplies a specific, non-rapport reason to prefer one candidate.

The 30/60/90 plan is standard practice in sales and executive hiring and is unusual in engineering, which is precisely why it lands: it is the only artifact in the process that demonstrates what the candidate would do rather than what they have done.

Cognitive fatigue over sustained performance is well established: sustained demanding cognitive work degrades working memory and self-monitoring over hours, and the degradation is reduced by breaks, hydration and food. The practical consequence is scheduling rather than psychology: the rounds late in a loop are typically the behavioural and hiring-manager rounds.

Follow-up correction rescuing candidacies follows from the debrief timing: independent written feedback is typically submitted within a day, so a correction that arrives inside that window can change the written assessment, and one that arrives after the decision cannot.

Sanitisation as a judgment signal is real in regulated and enterprise contexts, where a candidate sharing an unsanitised internal document is a demonstrated confidentiality risk, and saying explicitly what you removed is the behaviour that distinguishes the two.

The debate

Are differentiators gimmicks? They would be if they were empty, and each of the eight supplies real information: an artifact removes reconstruction load, a 30/60/90 shows how you would approach the job, a defended opinion with a reversal condition shows how you reason. The gimmick version is the same behaviour without content, a generic plan or a diagram of nothing, and interviewers detect it immediately.

Is a 30/60/90 plan presumptuous? With the caveat, no. "This is written from the outside, so half of it is probably wrong; the point is how I would approach the first quarter" removes the presumption and keeps the signal, and in the worked example the hiring manager's comment was that the half that was right was the half they would have wanted the candidate to notice.

Should you name your own weakness? Yes, if it is real and if you have a mitigation. Naming a fake weakness is worse than saying nothing, and naming a real one before the interviewer finds it converts an objection into evidence of self-awareness. The judgement call is which weakness, and the answer is the one they are going to find anyway.

Is bringing an artifact risky for confidentiality? It is a demonstration of judgment in either direction. A sanitised diagram with an explicit statement of what was removed is a positive signal; an unsanitised internal document is a disqualifying one, and the difference is entirely in the preparation.

Does interview-day logistics really matter? Measurably, and the specific mechanism is that the rounds late in a loop are the behavioural and hiring-manager rounds, which is where a staff decision is made. A candidate who is sharp for the two coding rounds and vague for the deep dive has optimised the wrong half of the day, and it is fixed by food, water, breaks and refusing a working lunch.

Should you review notes between rounds? No. It raises anxiety, changes nothing, and consumes the recovery time that has a measurable effect. Stand up, look at something far away, and let the previous round end.

Follow-up Q&A

"What actually makes a director remember a candidate?"

Something specific and non-rapport, because in the absence of distinguishing evidence evaluators fall back on similarity. The eight that work, roughly in order of how few candidates do them: bring a sanitised artifact; send a one-page 30/60/90 plan for their team after the onsite; reference their published engineering work specifically; speak in operational metrics like p99, error budget, cost per query and on-call load; name your own gap before they find it; hold a defended technical opinion with a reversal condition; send a follow-up that continues the discussion rather than thanking them; and prepare the questions you would ask the team in week one.

"Why is a 30/60/90 plan close to decisive for a lead role?"

Because it is the only artifact in the entire process that shows what you would do rather than what you have done, and for a lead role that is the question actually being asked. One page: first 30 days listen and map, naming what you would read and who you would meet and what you would measure; 60, one visible fix derived from what you learned in the loop; 90, a proposal with the evidence you would have by then. Include the caveat that it is written from the outside and half of it is probably wrong, which removes the presumption. In one case the hiring manager's stated reason for the offer was the plan.

"What makes a follow-up email worth sending?"

Adding something. A generic thank-you is read and ignored. A paragraph continuing the design discussion, the whiteboard diagram redrawn cleanly, or an answer to a concern the interviewer raised is evidence your advocate can use, and it must arrive within about 24 hours because the debrief is fast. The highest-value version is a one-line correction if you know you got something wrong: "I said X for the quorum math; on reflection it is Y." That demonstrates exactly the self-correction the loop exists to measure.

"How should you use a whiteboard?"

Reserve space before you start, because running out of room and redrawing costs three minutes and the interviewer's attention. Draw in request order: the user at the left, then the services left to right, data stores below the services that own them, then arrows labelled with protocol and approximate volume, and only then detail. Write the assumptions in a corner and keep them visible, QPS, data size, latency target, consistency requirement, because you will refer back to them and an interviewer who can see them can follow your reasoning. And narrate while drawing: silence with a marker is the least informative state in the interview.

"What is the most under-prepared part of a remote loop?"

The tool. Test the one they use rather than the one you like, because Excalidraw, Miro, CoderPad and a shared document all behave differently and the first two minutes of a design round is a bad time to learn one. Diagramming fluency has a learning curve and spending it during the round costs you the round. Then the physical setup: a second monitor so the diagram and the faces are both visible, notes on paper rather than on screen because reading from a screen is visible, and notifications disabled at the operating-system level including the calendar popups that would show your other interviews.

"Why does stamina matter more than people think?"

Because the rounds late in a loop are usually the behavioural and hiring-manager rounds, which is where a staff decision is made, so a candidate who is sharp for the morning coding rounds and vague by the afternoon deep dive has optimised the wrong half of the day. One candidate's reconstruction of a failed loop: strong on two coding rounds, then a 30-minute recruiter call instead of lunch, then "I couldn't remember numbers I know cold" in the deep dive and audible rambling in the leadership round. The fix was food, water, standing up between rounds, refusing the working lunch, and not reviewing notes, and in the next loop the two afternoon rounds were the strongest scores.

Common misconceptions

"Differentiators are gimmicks." Each supplies real information. The gimmick version is the same behaviour with no content, which interviewers detect immediately.

"A 30/60/90 plan is presumptuous." With the caveat that it is written from outside and half is probably wrong, it is the only artifact showing what you would do rather than what you have done.

"A thank-you email is the follow-up." It is read and ignored. A paragraph continuing the discussion, a cleaned-up diagram, or a correction is evidence that changes a debrief.

"Whiteboard quality matters." Order and legibility matter. Running out of space and redrawing is the common failure, and narration matters more than neatness.

"I'll set up the remote tooling on the day." Diagramming fluency has a learning curve, and paying it during the design round costs you the design round.

"Reviewing notes between rounds helps." It raises anxiety, changes nothing, and consumes the recovery that measurably affects the afternoon rounds.

Interview delivery note

Say this verbatim when opening a deep dive: "I've brought a one-page diagram of the system, sanitised, so I've removed customer names and internal hostnames. Happy to go into anything on it." It removes the interviewer's reconstruction load, changes the round from recall to discussion, and the sanitisation sentence is itself a judgment signal. Almost nobody does it.

The senior-versus-staff separator is the 30/60/90 plan sent after the onsite. A senior candidate describes what they have done. A staff or lead candidate sends one page describing what they would read, who they would meet and what they would measure in the first thirty days, one visible fix by sixty, and a proposal by ninety, with an explicit caveat that half of it is wrong from the outside. It is the only artifact in the process that answers the question a hiring manager is actually asking, and in one case it was the stated reason for the offer between two candidates the loop could not separate.

The second signal is treating the day as a performance to be scheduled. Knowing that the rounds late in a loop are the ones that decide a staff hire, and therefore eating, hydrating, standing up between rounds and refusing a working lunch, is not a soft concern: one candidate's failed loop was strong on the two morning coding rounds and weak on the deep dive and leadership rounds, and the difference in the successful loop was food and breaks.

Further reading

• Amazon's Bar Raiser and Google's hiring committee descriptions, for why the written debrief makes a memorable specific detail decisive.
• Google's re:Work materials on structured hiring, for what evaluators fall back on in the absence of distinguishing evidence.
• The questions you ask, by interviewer page, for the hesitation question whose answer this page's follow-up email should address.
• The architecture deep dive page, which is the round the artifact transforms.

The architecture deep dive on past work, at three zoom levels

What it is

The interview round where you present a system you built and are questioned on it. It is usually 45 to 60 minutes, it is the round that most reliably distinguishes staff from senior, and it fails for a specific reason: candidates prepare one level of detail and are asked for three.

THE THREE ZOOM LEVELS, and each is a different presentation

LEVEL 1  CONTEXT           2 minutes
         What the business needed, what the constraints
         were, what "good" meant. No boxes yet.

LEVEL 2  ARCHITECTURE      5 minutes
         The components, the data flow, the boundaries,
         and the two or three decisions that shaped it.

LEVEL 3  MECHANISM         however long they want
         One component, in depth: the algorithm, the
         schema, the failure handling, the numbers.

Commonly confused with a system design round. A design round evaluates how you approach an unfamiliar problem; a deep dive evaluates the depth and honesty of your actual experience. The questions are different: a design round asks "how would you", a deep dive asks "why did you", and "why did you" has a right answer that you either know or do not.

Also commonly confused with a presentation. It is a conversation you are seeding, and a candidate who delivers twenty uninterrupted minutes has controlled the room and learned nothing about what the interviewer wanted to explore.

The problem it solves

For the interviewer, it is the only round where they can verify that your résumé is real.

Everything else is hypothetical. A design round shows how
you think about a problem you have not solved. A behavioural
round is stories you have chosen and rehearsed.

The deep dive is the round where they can ask "why 20
connections and not 50" and find out in one question whether
you were the person who chose it.

And the failure mode this produces: a candidate who was adjacent to the work. They can describe the architecture accurately because they have seen the diagram, and they cannot say why any specific decision was made, because they did not make it. Two follow-up questions expose that reliably, which is why the round exists.

Mechanics

Choosing the system

Not the most impressive one. The one where you can go three levels deep on your own decisions.

GOOD CANDIDATES
  You made the significant decisions, or you can clearly
  separate yours from the team's.
  It had real constraints (latency, cost, compliance,
  deadline) that forced trade-offs.
  Something went wrong and you can say what and why.
  Recent enough that you remember the numbers.
  You can draw it from memory in ninety seconds.

BAD CANDIDATES
  The most technically impressive system you were near.
  Anything where the interesting decisions predate you.
  Something under NDA that you have to keep abstracting.
  Anything you would have to reconstruct from a document.

The test: pick a component and ask yourself "why is it that way, and what was the alternative?" If you cannot answer that for at least three components, choose a different system. A system you cannot defend at level 3 is worse than a less impressive one you can.

Level 1: context, and why candidates skip it

TWO MINUTES, NO ARCHITECTURE

  What the business needed and why it mattered.
  The constraints that shaped everything: scale, latency
  budget, compliance, team size, deadline, existing systems
  you had to live with.
  What "good" meant, ideally as a number.
  Your role, explicitly.

EXAMPLE
  "We ran product search for a marketplace: nine locales,
  fifty million items, about four thousand queries a second
  at peak. The constraint that shaped everything was a 200
  millisecond p99 budget, because the search box was on the
  home page and a slow search measurably cost conversion.
  I was the tech lead, so I owned the architecture and the
  ranking decisions, and a colleague owned the indexing
  pipeline."

Candidates skip this and go straight to boxes, and it costs them twice: the interviewer has no frame for evaluating the decisions, and the constraints that justify the design are never stated, so every choice looks arbitrary.

Naming your role explicitly, at the start, is the second thing candidates omit. It is not immodest; it is what lets the interviewer calibrate every subsequent "we".

Level 2: architecture, and the decisions rather than the components

FIVE MINUTES

  Draw it. Six to ten boxes maximum, and if you need more
  you are at the wrong altitude.
  The data flow: follow one request through it.
  The boundaries: what is a service and why.
  And THE TWO OR THREE DECISIONS THAT SHAPED IT, each with
  its alternative.

The last item is the whole level. A component list is a description; a decision with its rejected alternative is engineering.

WEAK
  "There's an API layer, a ranking service, an OpenSearch
   cluster, a feature store and a Redis cache."

STRONG
  "The decision that shaped everything was keeping item
   features in the serving process rather than in a remote
   store. Four thousand queries a second times five hundred
   candidates is two million feature lookups a second, which
   isn't servable from Redis at any sensible cost. Two
   million items at 256 fp16 features is about a gigabyte,
   so it broadcasts to every replica. That's why the ranking
   service is stateful and why deploys are slower than
   you'd expect."

Notice the second version includes a cost. "That's why deploys are slower than you'd expect" is the sentence that signals you lived with the decision rather than made it on a whiteboard.

Level 3: mechanism, and being ready for any component

The interviewer picks the component, not you. So you need depth on several, and the question is always some form of "why is it like that".

FOR EACH MAJOR COMPONENT, HAVE READY

  the algorithm or data structure, and why that one
  the schema or data model, and the access pattern that
    drove it
  the numbers: throughput, latency, size, cost
  the failure mode and what happens when it occurs
  the thing you would change

EXAMPLE, if they pick the cache
  "Read-through, Redis, keyed by normalised query plus
   filters plus locale. Sixty second TTL. Hit rate about 35
   percent, which sounds low and is fine because search
   traffic is heavily skewed: the top one percent of queries
   are around forty percent of volume, so a small cache
   catches most of what repeats.

   The failure handling is the interesting part. We had a
   stampede when a popular query expired: about nine hundred
   requests hit OpenSearch in the same second and took it to
   a hundred percent CPU for forty seconds. We added a
   single-flight lease so one request regenerates and the
   rest serve the previous value.

   What I'd change: we keyed by the raw filter string, so
   semantically identical filter orderings produced
   different keys. Canonicalising them would have added
   maybe five points of hit rate for an afternoon of work."

The "what I'd change" is not optional. A system presented as having no regrets reads as either dishonest or as insufficiently examined, and volunteering a specific improvement with its cost is the cheapest credibility available.

Moving between levels deliberately

The skill being scored is the movement, not the depth.

SIGNPOST THE LEVEL YOU ARE AT
  "At a high level..."     -> level 2
  "Going one level down..." -> level 3
  "Stepping back..."       -> back to 1 or 2

ASK WHICH THEY WANT
  "I can go deeper on the ranking model or on the indexing
   pipeline. Which is more useful?"
  This is not deferring; it is respecting that they have a
  thing they want to probe and you do not know what it is.

WATCH FOR THE SIGNALS
  "Can you go deeper?"          -> they want level 3
  "So at a high level..."       -> you are too deep
  A question about business
  impact                        -> they want level 1

Asking which component to go deep on, once, early, is a strong move, because the round has limited time and spending it on the component they did not care about is a wasted round.

The questions that separate the levels

These are the standard follow-ups, and they map to the three levels.

LEVEL 1 PROBES
  "Why did this matter to the business?"
  "What would have happened if you hadn't built it?"
  "How did you know 200 ms was the right budget?"

LEVEL 2 PROBES
  "Why is that a separate service?"
  "What would you have done with twice the team?"
  "Where's the bottleneck?"
  "What breaks first as traffic grows?"

LEVEL 3 PROBES
  "Why 20 connections and not 50?"
  "Walk me through what happens when that call times out."
  "What's the p99 and where does it come from?"
  "Why that data structure?"

THE HONESTY PROBES, which appear at every level
  "What went wrong?"
  "What would you do differently?"
  "What was the hardest part?"
  "What did you get wrong at first?"

The honesty probes are scored more heavily than they look. A candidate with no failures, no regrets and no hard parts has described a project they did not struggle with, which at staff level means either the project was easy or they were not close to it.

A worked example: the same system, three depths

LEVEL 1 (2 minutes)
  "Product search for a marketplace. Nine locales, 50
  million items, 4,000 queries a second at peak. The
  constraint was a 200 millisecond p99, because the search
  box was on the home page. I was tech lead and owned the
  architecture and ranking."

LEVEL 2 (5 minutes, drawing)
  "Request comes in, query understanding, then two retrieval
  arms in parallel: BM25 over per-locale OpenSearch indexes,
  and dense retrieval over a shared multilingual embedding
  space. Fused with reciprocal rank fusion, then a
  cross-encoder rerank on the top fifty, then business
  ranking.

  Three decisions shaped it. Per-locale lexical indexes,
  because analysis is language-specific and a shared
  analyzer costs real recall on morphologically rich
  languages. One shared multilingual embedding space, so
  cross-lingual matching works and so we don't have nine
  near-duplicate vectors per product. And rank fusion rather
  than score fusion, because BM25's IDF is per index, so the
  same term is worth about 28 percent more in a small French
  index purely because it's smaller."

LEVEL 3 (if they pick the reranker)
  "Cross-encoder, roughly BERT-base scale, over the top
  fifty. About 35 milliseconds batched on GPU, which is 40
  percent of the remaining budget after retrieval, so it's
  the first thing we drop under load.

  Fifty was measured rather than chosen: twenty gave NDCG
  0.712 at 18 milliseconds, fifty gave 0.741 at 35, a
  hundred gave 0.749 at 68. The curve bends around fifty to
  a hundred, and doubling to two hundred bought 0.003 for
  another 66 milliseconds, which isn't a trade you make in a
  200 millisecond budget.

  The failure handling: we circuit-break on the reranker's
  p99 rather than on errors, because the realistic failure
  is slow rather than dead, and on break we serve the fused
  order.

  What I'd change: we reranked every query. About 22 percent
  were exact-identifier lookups where BM25's top result was
  already correct, and an intent classifier skipping those
  would have bought latency headroom for the queries that
  actually benefit."

The movement is what is being scored. Level 1 has no components. Level 2 has three decisions with alternatives and no implementation detail. Level 3 has measured numbers, a failure mode and a regret, and it is about one component.

Production evidence

Amazon's, Google's and Meta's staff-and-above loops all include a round of this shape (variously "deep dive", "architecture review", "technical experience"), and their published candidate guidance consistently emphasises depth on your own contribution rather than breadth of exposure.

Structured interview research finds that past-behaviour questions with specific probing predict job performance better than hypothetical questions, which is the reason this round exists alongside a design round rather than instead of it.

Will Larson's Staff Engineer contains interview accounts noting that the deep dive is where candidates most often fail, and specifically that the failure is being unable to justify decisions rather than being unable to describe systems.

The "curse of knowledge" literature (Heath and Heath, and the underlying research) explains why level-1 context gets skipped: the candidate has held the constraints in their head for years and cannot easily model an interviewer who has not.

The debate

The case for choosing your most impressive system: it demonstrates scope, and scope is what staff level is about. A candidate who presents a small system has capped their own ceiling.

The case for choosing the one you know best: the round is won at level 3, and level 3 on a system you were adjacent to fails in two questions. Impressiveness you cannot defend is worse than modest scope you can.

The case for preparing a script: the round has a predictable shape and rehearsing it removes the risk of rambling.

My position: choose the system you can defend three levels deep on your own decisions, prepare all three levels separately, and ask early which component they want.

The choice is the decision that determines the outcome, and the test is concrete: pick any component and ask "why is it that way, and what was the alternative". If you cannot answer that for three components, the system is wrong regardless of how impressive it is. Two follow-up questions expose an adjacent candidate reliably, and that is precisely what this round is for.

Preparing the levels separately matters because they are different presentations, not one presentation truncated. Level 1 has no boxes at all. Level 2 is three decisions with their rejected alternatives, and almost no implementation. Level 3 is one component with measured numbers, a failure mode and a regret. A candidate who prepares "the architecture" has prepared level 2 and will be asked for the other two.

The move I would insist on is asking early which component they want to go deep on. The round has forty-five minutes, they have something specific they want to probe, and spending twenty minutes on the component they did not care about is a wasted round. Asking is not deferring; it is acknowledging that you cannot know what they are looking for.

And volunteer a regret, specifically, with its cost. "We reranked every query, and 22 percent were exact-identifier lookups where it bought nothing" is worth more than any success in the presentation, because a system presented as having no regrets reads as either dishonest or insufficiently examined. The honesty probes are scored more heavily than they appear.

Where I would push back on the impressiveness argument: scope is established at level 1 in two sentences, "fifty million items, four thousand queries a second, nine locales", and after that the round is entirely about whether you made the decisions. A larger system you cannot defend signals less scope than a smaller one you can, because the interviewer's conclusion is that you were near it rather than responsible for it.

Follow-up Q&A

"What is this round actually testing?" Whether your experience is real and whether you made the decisions. Every other round is hypothetical: a design round shows how you approach an unfamiliar problem, a behavioural round is stories you chose. This is the only round where they can ask "why twenty connections and not fifty" and find out in one question whether you were the person who chose it. The failure mode it catches is the candidate who was adjacent to the work and can describe the architecture accurately because they have seen the diagram.

"How do you choose which system to present?" Not the most impressive one. The test I would apply is: pick any component and ask "why is it that way, and what was the alternative". If I cannot answer that for at least three components, it is the wrong system, however impressive. Scope gets established at level one in two sentences, and after that the round is entirely about whether I made the decisions, so a bigger system I cannot defend signals less than a smaller one I can.

"What are the three levels?" Context, architecture, mechanism, and they are different presentations rather than one truncated. Level one is two minutes with no boxes at all: what the business needed, the constraints, what good meant as a number, and my role explicitly. Level two is five minutes of components, data flow, and crucially the two or three decisions that shaped it, each with its rejected alternative. Level three is one component in depth with measured numbers, a failure mode and a regret.

"What do candidates get wrong?" Preparing one level and being asked for three. Most prepare level two, the architecture, and then cannot supply the constraints that justify it or the mechanism underneath it. The second most common is skipping level one entirely and going straight to boxes, which costs twice: the interviewer has no frame for evaluating the decisions, and every choice looks arbitrary because the constraints were never stated.

"How do you make level two strong rather than a component list?" By making it decisions rather than components. "There's an API layer, a ranking service and a cache" is a description. "The decision that shaped everything was keeping item features in the serving process, because four thousand queries a second times five hundred candidates is two million lookups a second, which isn't servable remotely, and that's why the ranking service is stateful and deploys are slower than you'd expect" is engineering. The cost clause at the end is what signals you lived with it.

"How do you know which component to go deep on?" Ask, once, early. "I can go deeper on the ranking model or the indexing pipeline, which is more useful?" The round is forty-five minutes, they have something specific they want to probe, and spending twenty minutes on the wrong component wastes it. That is not deferring, it is acknowledging you cannot know what they are looking for.

"What are the signals you are at the wrong altitude?" Too deep: they ask something you already covered, or they say "so at a high level". Too shallow: they ask "but why", or they start proposing alternatives you already ruled out. And signposting removes most of the problem: "at a high level", "going one level down", "stepping back" tells them where you are and lets them steer.

"How important is the 'what would you do differently' question?" More than it looks. A system presented as having no failures, no regrets and no hard parts describes a project the candidate did not struggle with, which at staff level means either it was easy or they were not close to it. So I would volunteer a specific regret with its cost, unprompted: "we reranked every query, and 22 percent were exact-identifier lookups where it bought nothing, and an intent classifier skipping those would have been an afternoon's work". That is cheaper credibility than any success in the presentation.

"What if the system is under NDA?" Abstract the domain, not the engineering. "A financial services company" instead of naming it, "a compliance requirement that data stay in-region" instead of the specific regulation. What you must not abstract is the numbers and the decisions, because those are the content of the round. If you cannot give numbers at all, pick a different system, because a deep dive without figures is a description.

Common misconceptions

"Present the most impressive system." Impressiveness you cannot defend at level three signals that you were adjacent to it. Scope is established in two sentences at level one.

"It's a system design round about your own work." A design round asks "how would you"; this asks "why did you", and the second has a right answer you either know or do not.

"Prepare the architecture." That is one of three levels. The other two get asked for and are different presentations.

"Deliver it uninterrupted." It is a conversation you are seeding. Twenty uninterrupted minutes means you controlled the room and learned nothing about what they wanted to explore.

"Don't volunteer failures." The honesty probes are scored heavily, and a project with no hard parts reads as one you were not close to.

Interview delivery note

Open with level one and keep it to two minutes, because it is the part candidates skip and it frames everything: "Product search for a marketplace, nine locales, fifty million items, four thousand queries a second at peak. The constraint that shaped everything was a two-hundred millisecond p99, because the search box was on the home page and a slow search measurably cost conversion. I was tech lead and owned the architecture and the ranking decisions."

Note the role statement in that. Say it explicitly and early, because it is what lets the interviewer calibrate every subsequent "we", and omitting it is the second most common mistake in this round.

Ask early which direction to go: "I can go deeper on the ranking model or on the indexing pipeline. Which is more useful for you?" Forty-five minutes is not enough for both, and they have something they want to probe.

At level two, give decisions with alternatives rather than components, and include the cost you lived with: "...and that's why the ranking service is stateful and deploys are slower than you'd expect."

At level three, lead with a measured number rather than a description: "Fifty candidates was measured, not chosen: twenty gave NDCG 0.712 at 18 milliseconds, fifty gave 0.741 at 35, a hundred gave 0.749 at 68."

And volunteer the regret before being asked: "What I'd change is that we reranked every query, and about 22 percent were exact-identifier lookups where BM25's top result was already right."

Further reading

• Will Larson, Staff Engineer, for interview accounts of this round and where candidates fail.
• Amazon's and Google's published candidate guidance on technical experience interviews.
• Barbara Minto, The Pyramid Principle, for the level-one-first structure and why leading with context works.
• SCOR, STAR and the scar-tissue story, for the narrative structure the level-one framing borrows from.

SCOR, STAR, and the scar-tissue story

"Rewrite one of your SCOR stories as STAR, on the spot." and "Give me a 30-second scar-tissue story that fits inside a caching answer."

What they are

Two story structures and one story type, and the reason to hold all three is that interviewers ask for different ones and you cannot afford to be rebuilding your material during the answer.

STAR is the format most behavioural interviews are scored against, and at large companies the rubric is literally organised by its four parts.

Situation  The context. Where, when, what was at stake.
Task       Your specific responsibility in it.
Action     What YOU did. First person singular. The bulk of the answer.
Result     The outcome, with a number, and what you learned.

SCOR front-loads the conflict, which makes it better for technical narration and for staff-level scope where the interesting part is the decision rather than the context.

Situation   The context, compressed.
Complication  What made it hard. The tension, the constraint, the tradeoff.
Options     What you considered, and the cost of each. THIS is the staff signal.
Resolution  What you chose, why, what happened, what you would change.

A scar-tissue story is neither a format nor a standalone answer. It is a 20 to 40 second embedded anecdote dropped inside a technical answer as evidence that you have operated the thing rather than read about it. It has one job: to convert a claim into experience.

Commonly confused: SCOR and STAR are not competing. STAR is a scoring rubric; SCOR is a narration order. You can tell a SCOR story that a STAR rubric scores perfectly, provided the four STAR elements are present and findable. That relationship is the whole answer to the "rewrite it on the spot" drill.

The problem they solve

Interviewers score against a rubric you cannot see. At companies with structured behavioural loops, the interviewer is filling in fields: what was the situation, what was their role, what did they personally do, what was the outcome. If your story does not contain a findable answer for each, it scores low regardless of how impressive the work was. That is the failure mode STAR prevents.

Staff-level stories fail differently. They fail by being vague about the decision. A senior candidate narrates what happened; a staff candidate narrates what they considered and why they rejected it. STAR has no slot for that, which is why SCOR exists: the Options section is the one that carries the signal, and if you tell a pure STAR story you often skip it.

And technical answers fail by sounding theoretical. Two candidates give the same correct answer about cache stampedes. One of them mentions the 40 seconds their origin spent at 100 percent CPU. Only one of them sounds like they have done it. That is the job of scar tissue, and it costs 25 seconds.

Mechanics

Converting SCOR to STAR live

The mapping is mechanical once you see it, and it is worth rehearsing because the drill is asked exactly this way.

SCOR                    STAR
--------------------------------------------------------------
Situation          ->   Situation  (compress to 2 sentences)
Complication       ->   Situation + Task
                        The complication IS the task: "my job was
                        to resolve X" is the complication restated
                        in the first person.
Options            ->   Action, part 1
                        "I evaluated three approaches..." Do not
                        drop this. Compress it to one sentence per
                        option, but keep it.
Resolution         ->   Action, part 2 + Result
                        Split it: what you DID is Action, what
                        HAPPENED is Result.

Two things must be added when converting, and forgetting them is why conversions score badly:

1. Make the Task explicit and personal. SCOR often leaves your role implicit, because the complication is stated about the system. STAR scores "what was YOUR responsibility" as its own field. Add one sentence: "I was the tech lead for the service and I owned the decision."

2. Convert "we" to "I" in the Action. SCOR narrates a team resolving a problem. STAR scores individual contribution. This is not about taking credit; it is about the rubric having a field for it. Say what the team did, then say what you did: "The team split into two workstreams. I owned the migration path and wrote the rollback plan."

A worked conversion

The SCOR version (about 100 seconds):

Situation. We ran a multilingual product search over OpenSearch, about 4,000 queries per second at peak across nine locales.

Complication. After we added a personalisation layer, p99 latency went from 180 milliseconds to 1.4 seconds, but only for locales with fewer than 200,000 documents. Which is backwards: the small indices got slower. That inversion was the clue, and it took us two days to notice it because we were looking at the aggregate.

Options. Three. Scale the cluster, which was the fast answer and treated a symptom we did not understand. Cache personalised results, which for a personalised query has a hit rate close to zero, so it would have bought nothing. Or find the actual cause, which cost us another day of a visible regression.

We took the third, and the cause was that the personalisation layer was issuing one query per shard per user segment, and the small locales had been over-sharded at six shards for 80,000 documents, so they were doing six times the round trips for a fraction of the data.

Resolution. We reshard the small locales to one shard each and batched the segment queries. p99 went to 210 milliseconds, better than before personalisation. I would change one thing: we should have alerted on p99 per locale rather than in aggregate, and that inversion would have been visible on day one instead of day two.

The same story as STAR (about 90 seconds), converted live:

Situation. I was tech lead for product search at [company], running about 4,000 queries per second over OpenSearch across nine locales.

Task. We shipped a personalisation layer and p99 latency went from 180 milliseconds to 1.4 seconds. I owned the regression and the decision about how to respond, with the business asking daily whether we should roll personalisation back.

Action. I started by segmenting the latency by locale rather than looking at the aggregate, and found the inversion: the smallest indices were the slowest, which ruled out a capacity explanation. I evaluated three responses: scaling the cluster, which would have masked a cause we did not understand; caching personalised results, which I rejected because per-user results have a near-zero hit rate; and spending another day on root cause while the regression stayed visible. I argued for the third and got one day. The cause was one query per shard per user segment, against small locales that had been over-sharded at six shards for 80,000 documents. I reshard those to one shard and batched the segment queries.

Result. p99 came down to 210 milliseconds, better than the 180 before personalisation because the batching helped the large locales too. And I added per-locale p99 alerting, because the aggregate had hidden the inversion for two days. That alerting caught an unrelated regression six weeks later.

What changed, and what an interviewer notices: the Task became explicit and personal; the Options section survived inside Action, compressed to one sentence each; "we" became "I" for the decisions and stayed "we" for the team's work; and the Result gained a second consequence (the alerting catching something later), which is the strongest possible ending because it shows the fix outlived the incident.

What did NOT change: the numbers. 4,000 queries per second, 180 to 1,400 to 210 milliseconds, six shards, 80,000 documents, two days. The numbers are the story. Losing them in translation is the most common conversion failure.

Building the scar-tissue library

A scar-tissue story is 20 to 40 seconds, contains one number, and ends by connecting back to the technical point.

Shape:  [what we did]  ->  [what went wrong, with a number]
        ->  [the specific thing we now do]

Length: 3 sentences. 4 if the number needs setup.

Inside a caching answer:

"We learned that one the hard way. We had a 15-minute TTL on a popular-products query, and when it expired at peak, roughly 900 requests hit the origin in the same second and took the database to 100 percent CPU for about 40 seconds. What fixed it was a lease, so one request regenerates and the rest serve the previous value. That's why I always ask what happens at expiry rather than what the hit rate is."

Twenty-eight seconds, one number that only someone who watched the graph would know, and it lands on a reusable principle.

Inside a Kubernetes answer:

"We had a service where removing the CPU limit actually improved p99 by about 40 percent. It was CFS throttling: the container was hitting its quota within the 100-millisecond period and getting descheduled, while average utilisation looked fine at 30 percent. The signal we'd been missing was container_cpu_cfs_throttled_seconds, and now that's on the dashboard before anything else."

Inside a rollout answer:

"We shipped a schema change and the code together, and the rollback failed, because the old version couldn't read the new column. We got it back by rolling forward with a hotfix at two in the morning, which is not a strategy. Since then I check one thing before every deploy: what state does this version write that the previous one can't read."

The rules that make scar tissue work

It must contain a number only someone present would know. "It caused an outage" is generic. "40 seconds at 100 percent CPU" is a memory. This is the single strongest signal in the whole technique.

It must be a failure, or at least a surprise. A success story embedded in a technical answer reads as self-promotion. A failure reads as experience. The asymmetry is large.

It must be short and it must return to the point. If it becomes a two-minute story, you have changed the subject and the interviewer now has to steer you back, which costs you more than the anecdote gained.

Do not force one. Three or four well-placed scar-tissue stories across an interview is strong. One in every answer is a tic, and it starts to sound rehearsed, which is the one thing that undoes the entire benefit.

The preparation

Build a table. Eight to ten technical topics you expect, and one 30-second story for each:

Topic                 Scar tissue                         Number
--------------------------------------------------------------------------
Caching               stampede at TTL expiry              900 req/s, 40 s
Kubernetes            CFS throttling, limit removed       p99 -40%
Deployments           rollback blocked by schema          2am hotfix
Search relevance      offline NDCG up, online CTR down    -3% CTR
Kafka                 consumer lag from a slow handler    4h backlog
Postgres              tombstones / bloat / lock timeout   3 write timeouts
On-call               alert that never fired              1 pod, 2.5% traffic
RAG                   retrieval was fine, context wasn't  0.71 -> 0.94

That table takes an evening to build from real memory and it is worth more than rehearsing any single answer, because it converts every technical topic into one where you sound like an operator.

Production evidence

Amazon's Leadership Principles interview loop trains interviewers to collect STAR-structured evidence and to probe specifically for individual contribution, which is why the "we" to "I" conversion matters mechanically rather than stylistically. Amazon's own published candidate guidance names STAR explicitly.

Google's published interview guidance advises candidates to use the STAR method and tells them the interviewer is assessing "what you did", which is the same rubric field.

The situation-complication-resolution structure originates in Barbara Minto's The Pyramid Principle, developed at McKinsey for consulting communication, where the point of leading with the complication is that it makes the audience want the answer. SCOR is that structure with an explicit Options step added, and the Options step is what makes it fit engineering decisions.

Behavioural interview research consistently finds structured behavioural questions predict job performance better than unstructured ones, which is why the formats exist at all and why interviewers hold to them: the structure is what makes the interview comparable across candidates, and a story that will not fit the structure is genuinely harder to score.

The debate

The case for STAR everywhere: it matches the rubric, so it maximises your score. If the interviewer is filling in four fields, giving them four clearly delineated fields is simply cooperating with the process.

The case for SCOR at staff level: STAR has no slot for the decision, and at staff level the decision is the content. A STAR story about a technical judgement call often compresses the entire interesting part into one clause of Action. SCOR's Options step forces you to say what you rejected and why, which is what distinguishes a person who made a decision from a person who executed one.

My position: prepare in SCOR, deliver in STAR, and always keep the Options. Prepare in SCOR because it forces you to find the complication and the alternatives, and stories that lack those are the ones that fall flat. Deliver in STAR because that is what is being scored, and adding one explicit Task sentence plus first-person Actions costs nothing.

The concrete rule for the Options: compress each alternative to one sentence with its cost, and keep all of them. "I evaluated scaling the cluster, which would have masked a cause I didn't understand; caching, which has near-zero hit rate for personalised results; and another day of root-causing with the regression visible." That is 12 seconds and it is the highest-density staff signal in the entire story.

For scar tissue, my position is that it is the highest return per unit of preparation in the whole interview, because it costs 25 seconds inside an answer you were giving anyway and it is the difference between having read about something and having operated it. The constraint is that it must be true and it must have a number, which means you have to actually mine your own memory rather than construct something plausible. An interviewer who probes a fabricated anecdote will find the bottom of it in two questions, and that ends the interview.

Follow-up Q&A

"Rewrite that story as STAR." The mapping is mechanical. Situation compresses to two sentences. The Complication becomes the Task, restated in the first person as what I was responsible for. The Options move into the front of Action, one sentence per option with its cost, and I keep all of them because that is where the decision-making shows. The Resolution splits: what I did goes in Action, what happened goes in Result. Two things I add that SCOR left implicit: an explicit sentence about what was mine to decide, and converting "we" to "I" for the decisions while leaving "we" for the team's work.

"Why not just use STAR from the start?" Because STAR has no slot for the alternatives, and at staff level that is the content. A STAR story about a technical judgement typically compresses the whole interesting part into one clause. Preparing in SCOR forces me to identify the complication and the options, and once they exist they survive the conversion. Preparing in STAR tends to produce stories where I narrate what happened without ever saying what I rejected.

"What makes a story fail?" Four things, in rough order. No number, so nothing is verifiable and it sounds like a description of a category of event rather than a memory. No individual contribution, so the interviewer cannot fill in the field they are scoring. No decision, so it is a narration of events I was present for. And no retrospect, so I have not shown what I would do differently, which is the cheapest credibility available.

"What is a scar-tissue story and where does it go?" It is 20 to 40 seconds embedded inside a technical answer, not a standalone behavioural response. Three sentences: what we did, what went wrong with a number, and the specific thing we do now. Its job is to convert a claim into experience. Two candidates give the same correct answer about cache stampedes; the one who mentions the 40 seconds at 100 percent CPU is the one who has operated it.

"How many should you use?" Three or four across a whole interview. One per answer becomes a tic and starts to sound rehearsed, which undoes the benefit entirely. I build a table of eight to ten topics I expect with one story each, and use the ones that fit naturally rather than forcing every topic to have one.

"What if the story's outcome was bad?" Those are usually the better stories, as long as the retrospect is specific. "We chose wrong, here is what the signal was that I missed, here is the check I run now" is a stronger answer than a success, because it demonstrates calibration. What fails is a bad outcome with no lesson, or a lesson so generic it could apply to anything, like "communicate more".

"How do you keep numbers straight under pressure?" Rehearse the numbers rather than the sentences. For each story I hold four or five figures: the scale, the before, the after, and one detail only a participant would know. The prose can vary between tellings and should; the numbers should not, because inconsistency across an interview loop is noticed and it is the thing that makes an interviewer start probing.

Common misconceptions

"SCOR and STAR are competing frameworks." One is a narration order, the other is a scoring rubric. A SCOR story that contains all four STAR elements scores fine.

"The Result is the important part." The Action is the longest and most heavily scored section. The Result needs one number and one lesson.

"Saying 'I' instead of 'we' is taking credit." The rubric has a field for individual contribution. Say what the team did, then say what you did.

"Scar-tissue stories are the same as behavioural stories." They are 30 seconds long and live inside technical answers. A two-minute story in the middle of a technical answer has changed the subject.

"More detail is better." Beyond about 100 seconds, an interviewer stops tracking and starts waiting. Compress the Situation ruthlessly; the Situation is the part everyone over-tells.

Interview delivery note

For the conversion drill, say the mapping out loud before you tell the story, because it shows you understand what is being scored: "Sure. The complication becomes the task in first person, the options move into the front of the action, and the resolution splits into what I did and what happened. The one thing I'll keep is the options, because that's where the decision is." Then tell it.

Keep the numbers identical across both tellings. An interviewer who has heard the SCOR version and hears different figures in the STAR version notices immediately, and it is the single fastest way to lose credibility.

For scar tissue, the delivery is what makes it work: drop it mid-answer without announcing it, keep it under 30 seconds, and land on the principle. "We learned that one the hard way..." then the number, then "...which is why I always ask what happens at expiry rather than what the hit rate is." The return to the technical point is what stops it being a digression.

The preparation that pays most: a table of eight to ten expected topics with one 30-second true story and one real number for each. That is an evening of work and it changes how every technical answer sounds.

Further reading

• Barbara Minto, The Pyramid Principle, for the situation-complication-resolution structure and why leading with the complication works.
• Amazon's published interview preparation guidance on STAR and the Leadership Principles, for how the rubric is actually applied.
• Google's "How we hire" interview guidance, for the same rubric from a second source.
• Gayle Laakmann McDowell, Cracking the Coding Interview, on story preparation tables, which is the same mechanic applied to behavioural material.

Executive communication: BLUF, altitude, signposting, bounded uncertainty

What it is

Four techniques for talking to people whose time is expensive and whose context differs from yours. They are separable skills and each has a specific failure it prevents.

BLUF                  Bottom Line Up Front. The conclusion in
                      the first sentence, then the reasoning.
                      Prevents: the listener not knowing what
                      you want until minute three.

ALTITUDE CALIBRATION  Matching the level of detail to the
                      audience, and adjusting when you have
                      misjudged.
                      Prevents: explaining Kafka partitions
                      to a CFO, or hand-waving to a principal.

SIGNPOSTING           Announcing the structure before the
                      content. "Three things: the cause, the
                      fix, and what I need from you."
                      Prevents: the listener trying to work
                      out where you are going while you are
                      going there.

BOUNDED UNCERTAINTY   Saying what you know, what you do not,
                      and when you will know.
                      Prevents: false confidence, and the
                      equally bad "it's complicated".

Commonly confused with being brief. Brevity is a consequence, not the technique. A five-minute BLUF answer is fine if the first sentence was the conclusion; a thirty-second answer that buries the point is worse.

Also commonly confused with dumbing down. Altitude calibration is about which details are load-bearing for this listener's decision, not about simplifying. A CFO does not need less truth; they need different truth.

The problem it solves

Senior people make decisions from summaries, and a summary that requires them to do the synthesis has failed.

THE FAILURE MODE, in a status update to a director:

  "So we've been looking at the latency issue, and initially
   we thought it was the database, but then Sam found that
   the connection pool was actually the constraint, and we
   tried increasing it but that caused the memory issue, so
   we backed that out, and now we're looking at whether the
   batch job..."

  Three minutes in, the director still does not know: is
  this fixed, is it getting worse, or do they need to do
  something?

The narrative order (what happened, in sequence) is the wrong order for a decision-maker, and it is the order everyone defaults to because it is the order they lived it in.

And the second problem: engineers systematically over-hedge. "It might be the connection pool, but it could also be GC, and there are some other possibilities" is an accurate statement of uncertainty and it is unusable. The listener cannot act on it and concludes you do not know.

Mechanics

BLUF: the conclusion first

NARRATIVE ORDER (how you lived it)
  investigation -> findings -> conclusion -> what I need

BLUF ORDER (how they need it)
  conclusion -> what I need -> findings -> investigation

BEFORE
  "We've been investigating the checkout latency. We started
   with the database, ruled that out, then looked at the
   connection pool..."

AFTER
  "Checkout latency is fixed as of this morning, and I need
   one decision from you about the follow-up.

   The cause was connection pool exhaustion from a batch job
   sharing the pool. We've separated the pools, and p99 is
   back to 340 ms.

   The decision: the proper fix is a query timeout on the
   batch job, which is two days of work. I'd like to do it
   next sprint rather than this one. That leaves us exposed
   to a recurrence for about two weeks, at maybe a one in
   ten chance."

The structure: conclusion, ask, cause, evidence, decision with its cost. And notice that the "after" version is not shorter, it is reordered. Brevity comes from the listener being able to stop early once they have what they need, which they cannot do when the conclusion is last.

The test for whether you have done it: could the listener leave after your first two sentences and still act correctly? If not, the bottom line is not up front.

Altitude calibration

The mistake is thinking of it as one dial. It is two: technical depth, and organisational scope.

                    TECHNICAL DEPTH
                    low                high
ORG    narrow   |  a PM                a peer engineer
SCOPE           |  "the checkout       "the pool was sized
                |   page was slow       at 20 and the batch
                |   for an hour"        job held 18"
                |
       wide     |  a CFO / board        a principal / CTO
                |  "an outage cost      "we have a
                |   us roughly           systemic pattern
                |   $40k in orders"      of shared resource
                |                        pools across
                |                        services"

The second axis is the one people miss. A CTO wants high technical depth and wide scope, which means the answer is not "the connection pool was exhausted" (narrow) and not "we had an outage" (shallow), it is "this is the third incident from an unbounded shared resource, and I think we need a policy rather than three fixes".

The calibration signals to watch for, and the recovery:

YOU ARE TOO DEEP IF
  they ask a question you already answered
  they look at their phone
  they say "so at a high level..."
  -> Recovery: "Let me back up. The one-sentence version is X."

YOU ARE TOO SHALLOW IF
  they ask "but why?"
  they ask a question that presumes more detail
  they start proposing solutions you already ruled out
  -> Recovery: "Happy to go a level deeper on that."

*** Ask once, explicitly, rather than guessing: ***
  "Do you want the two-minute version or the detail?"
  It costs three seconds and it removes the whole problem.

Asking directly is under-used because it feels like weakness, and it is the opposite: it demonstrates that you know the answer has multiple altitudes and that you are choosing deliberately.

Signposting

"Three things: what happened, what we've done, and the one
 decision I need from you."

Then deliver exactly three things, in that order, and say
"first", "second", "third".

Why it works: the listener stops spending attention on working out the structure and spends it on the content. It also commits you to a structure, which prevents the drift that turns a two-minute update into six.

The variants worth having:

FOR A STATUS UPDATE
  "Green, with one risk. The risk is X, and here's the
   mitigation."

FOR BAD NEWS
  "I have bad news and a plan. The news is X. The plan is Y.
   What I need from you is Z."

FOR A RECOMMENDATION
  "I recommend X. Three reasons, and one thing that would
   change my mind."

FOR AN ANSWER YOU ARE UNSURE OF
  "Short answer is X. I'm about 70 percent confident, and
   here's what would move it."

"One thing that would change my mind" is the highest-value phrase in this list, because it demonstrates that the recommendation is a judgement rather than a preference, and it invites the listener to supply information rather than to argue.

Bounded uncertainty

The failure is symmetric: false confidence and unbounded hedging are both unusable.

FALSE CONFIDENCE
  "It's the connection pool."
  (when you are 60 percent sure)
  -> They act on it. If you are wrong, your next assertion
     is discounted.

UNBOUNDED HEDGING
  "It might be the pool, or GC, or the network, hard to say."
  -> Unusable. They conclude you do not know, and they ask
     someone else.

BOUNDED UNCERTAINTY
  "Most likely the connection pool, maybe 70 percent. The
   alternative is GC pressure. I'll know for certain within
   two hours, and the fix is the same for both, so I'm
   proceeding."
  -> Actionable. They know what you think, how sure you are,
     when it resolves, and that they need not decide now.

The four elements: the answer, the confidence, the alternative, and when you will know. All four, and the fourth is the one that converts uncertainty from a problem into a schedule.

And the version for when you genuinely do not know:

"I don't know, and here's how I'd find out."

That is a complete and strong answer. What is weak is
guessing, or filling the silence. See: handling what you
do not know.

Writing, which is the same skills with different constraints

An executive summary that works:

  ONE SENTENCE      the conclusion
  THREE BULLETS     the reasoning, one line each
  ONE ASK           what you need, specifically
  ------- everything below here is optional reading -------
  DETAIL            for whoever wants it

The line matters. Putting the detail below an explicit
boundary means the reader knows they can stop, which means
they read the top carefully instead of skimming everything.

And the rule for documents: if the recipient reads only the title and the first paragraph, have they got it? That is the same BLUF test applied to writing, and it is why titles like "Q3 Latency Update" fail and "Checkout latency fixed; one decision needed on the follow-up" works.

A worked example: the same incident at four altitudes

THE FACTS
  A batch job shared a connection pool with the checkout
  service. The pool held 20 connections; the batch job held
  18 for 40 minutes. Checkout p99 went from 340 ms to 8 s.
  Roughly 4% of checkout attempts abandoned. Fixed by
  separating the pools. The permanent fix is a query timeout
  on the batch job, two days of work.

TO A PEER ENGINEER
  "Connection pool exhaustion. The nightly reconciliation
   job shares checkout's pool, sized at 20, and it held 18
   with long-running scroll queries. Little's Law says with
   two usable connections and an 8 ms service time we cap at
   250 requests a second, and we were taking 400. Separated
   the pools; the real fix is a timeout on the scroll."

TO A PRODUCT MANAGER
  "Checkout was slow for 40 minutes last night, and about 4
   percent of people trying to check out gave up. It's fixed.
   The cause was a background job competing for a shared
   resource. There's a two-day piece of work to make sure it
   can't recur, and I'd like to schedule it next sprint."

TO A DIRECTOR
  "We had a 40-minute checkout degradation, roughly 4 percent
   abandonment, now resolved. The cause was a shared
   resource pool with no isolation between batch and
   interactive work. I'd flag that this is the second
   incident from the same pattern, so I'm proposing a policy
   that batch work never shares a pool with a user-facing
   path, which is about a week across the three services
   affected. The decision I need is whether that displaces
   something in the current sprint."

TO A CFO OR THE BOARD
  "A 40-minute checkout outage last night, estimated impact
   around $40,000 in abandoned orders. Resolved, and we've
   identified a systemic pattern behind it that we're
   addressing this quarter. No customer data was affected."

Notice what changes and what does not. The facts are identical. What changes is which facts are load-bearing for that listener's decision, and the scope: the peer gets the mechanism, the director gets the pattern across incidents, and the CFO gets the money and the reassurance about data.

And notice the director version is the only one that names a decision needed, because the director is the one who can make it. Asking a CFO to prioritise a sprint is an altitude error in the other direction.

Production evidence

BLUF originates in US military communication doctrine and is standard in situations where the recipient may stop reading at any point, which is the same constraint an executive summary operates under.

Barbara Minto's The Pyramid Principle is the canonical treatment: answer first, then supporting arguments, then evidence, developed at McKinsey precisely because clients would not read to the end.

Amazon's six-page narrative memo culture is the opposite convention and the exception worth knowing: no slides, a written narrative read silently at the start of the meeting. It works because the reading is enforced, and it does not transfer to organisations where documents are skimmed.

Research on expert-novice communication consistently finds that experts systematically over-estimate what novices know, which is the mechanism behind altitude errors and why asking directly is more reliable than judging.

Studies on hedging in professional communication find that unbounded hedging reduces perceived competence while calibrated confidence statements do not, which is the empirical basis for bounded uncertainty over both false confidence and vague qualification.

The debate

The case for BLUF everywhere: senior people's time is the scarcest resource in the organisation, and requiring them to synthesise a conclusion from a narrative is a transfer of work from you to them. It also forces you to have a conclusion, which is a useful discipline in itself.

The case against: for genuinely complex or contentious decisions, leading with the conclusion can trigger an immediate reaction before the reasoning lands, and some audiences disengage from a conclusion they disagree with. Narrative order can be the right choice when you need someone to reach the conclusion themselves.

The case for maximum detail: withholding detail from a technical leader is patronising, and some decisions genuinely require the mechanism to be understood.

My position: BLUF by default, ask about altitude explicitly rather than guessing, and always bound your uncertainty with all four elements.

The default matters because the narrative order is what everyone reverts to under pressure, since it is the order they lived it in, and the cost is that a director spends three minutes not knowing whether they need to act. Making BLUF the default costs nothing when the audience wants detail, because the detail follows immediately.

Asking directly about altitude, "do you want the two-minute version or the detail", is the technique I would push hardest because it is the most under-used. It feels like weakness and it is the opposite: it demonstrates you know the answer has several altitudes and you are choosing deliberately rather than guessing. Three seconds, and it removes the whole problem.

On uncertainty, all four elements or the statement is unusable: the answer, the confidence, the alternative, and when you will know. Engineers reliably give the first and the third and omit the second and fourth, which produces "it might be the pool or it might be GC", and the listener correctly concludes they cannot act on it. Adding "70 percent, and I'll know within two hours" converts the same uncertainty into a schedule.

And the phrase I would put in every recommendation: "one thing that would change my mind." It converts a preference into a judgement, it invites the listener to supply information rather than argue, and it is the difference between a recommendation someone can engage with and one they have to accept or reject.

Where I would concede the counter-argument: for a contentious decision where you need someone to arrive at the conclusion themselves, narrative order is legitimate. But that is a deliberate choice for a specific reason, and it is not what is happening when an engineer walks a director through their debugging session chronologically.

Follow-up Q&A

"What is BLUF and why does it matter?" Bottom line up front: the conclusion in the first sentence, then the ask, then the reasoning. It matters because senior people decide from summaries, and a summary requiring them to synthesise the conclusion has transferred work to them. The failure it prevents is specific: three minutes into a narrative update, the listener still does not know whether this is fixed, getting worse, or something they need to act on. And the test is whether they could leave after two sentences and still act correctly.

"Isn't that just being brief?" No, and the distinction matters. A five-minute answer is fine if the first sentence was the conclusion; a thirty-second answer that buries the point is worse. Brevity is a consequence: the listener can stop early once they have what they need, which they cannot do when the conclusion is last. The BLUF version of an update is often the same length, reordered.

"How do you calibrate altitude?" By asking, which is the most under-used technique here. "Do you want the two-minute version or the detail" costs three seconds and removes the guessing. And I would think of it as two dials rather than one: technical depth and organisational scope. A CTO wants high depth and wide scope, so the answer is neither "the connection pool was exhausted" nor "we had an outage", it is "this is the third incident from the same pattern and I think we need a policy rather than three fixes".

"What are the signals that you have it wrong?" Too deep: they ask something you already answered, they check their phone, or they say "so at a high level". Too shallow: they ask "but why", or they start proposing solutions you already ruled out. Either way the recovery is one sentence, "let me back up, the one-sentence version is X" or "happy to go a level deeper", and recovering explicitly is better than adjusting silently and hoping.

"How do you communicate uncertainty without sounding like you do not know?" Four elements, all of them. The answer, the confidence, the alternative, and when you will know. "Most likely the connection pool, about 70 percent, the alternative is GC pressure, and I'll know within two hours" is actionable. Engineers reliably give the answer and the alternative and omit the confidence and the timeline, which produces "it might be this or it might be that", and the listener correctly concludes they cannot act on it.

"What if you genuinely do not know?" Say so, and say how you would find out. "I don't know, and here's how I'd find out" is a complete and strong answer. What is weak is guessing to fill the silence, because a guess presented as an answer costs you on the next assertion too.

"What is signposting and why bother?" Announcing the structure before the content: "three things, what happened, what we've done, and the one decision I need from you". It works because the listener stops spending attention working out where you are going and spends it on the content. And it commits you to a structure, which prevents the drift that turns a two-minute update into six.

"Is there a phrase you would always include in a recommendation?" "One thing that would change my mind." It converts a preference into a judgement, it demonstrates you have thought about the conditions under which you would be wrong, and it invites the listener to supply information rather than to argue with you. It is the single highest-value phrase in this whole area.

"When is BLUF wrong?" For a contentious decision where you need someone to reach the conclusion themselves, leading with it can trigger a reaction before the reasoning lands. Narrative order is legitimate there, and it is a deliberate choice for a specific reason. What is not that is an engineer walking a director through their debugging session chronologically, which is the default everyone reverts to under pressure because it is the order they lived it in.

Common misconceptions

"Executive communication means less detail." It means different detail. A CFO does not need less truth; they need the truth that bears on their decision.

"BLUF means brief." It means reordered. Brevity follows because the listener can stop early.

"Hedging is honest." Unbounded hedging is unusable and reads as not knowing. Bounded uncertainty with a confidence and a timeline is both honest and actionable.

"Asking what level of detail they want looks unprepared." It demonstrates you know the answer has several altitudes. Guessing wrong is what looks unprepared.

"Altitude is one dial." It is two: technical depth and organisational scope, and the second is the one people miss.

Interview delivery note

This is assessed indirectly, in how you answer everything else, and directly in questions about communicating with leadership.

If asked directly, lead with the failure it prevents rather than the acronym: "The failure is that three minutes into a status update the director still doesn't know whether this is fixed, getting worse, or something they need to act on. That happens because we narrate in the order we lived it, and the decision-maker needs the conclusion first, then the ask, then the reasoning."

Then the technique with the test: "So: conclusion, ask, cause, evidence. And the test is whether they could leave after two sentences and still act correctly. Notice the reordered version isn't shorter, it's reordered, and the brevity comes from them being able to stop early."

Volunteer the altitude technique that is most under-used: "And for altitude I'd ask rather than guess. 'Do you want the two-minute version or the detail' costs three seconds and removes the problem entirely. It feels like weakness and it's the opposite: it shows you know the answer has several altitudes and you're choosing deliberately."

Give the uncertainty formula, because engineers systematically get this wrong in one of two directions: "And for uncertainty, four elements or it's unusable: the answer, the confidence, the alternative, and when you'll know. 'Most likely the pool, seventy percent, alternative is GC, I'll know in two hours' is actionable. 'It might be this or that' isn't, and the listener correctly concludes you don't know."

And demonstrate it throughout the interview rather than describing it, because that is what is actually being scored: lead every answer with the conclusion, signpost when you are about to give three things, and bound your uncertainty when you have any.

Further reading

• Barbara Minto, The Pyramid Principle, for answer-first structure and the pyramid of supporting arguments.
• The US Army's writing guidance on BLUF, for the original convention and its rationale.
• Amazon's published description of its narrative memo culture, as the instructive exception.
• Chip and Dan Heath, Made to Stick, on the curse of knowledge, which is the mechanism behind altitude errors.

Handling what you do not know

"You're asked something you genuinely don't know. What do you do?"

What it is

The set of responses to a question outside your knowledge, and the observation that this is tested deliberately. A staff interview will reach the edge of your knowledge, on purpose, because how you behave there predicts how you behave in production when a system does something nobody expected.

FOUR RESPONSES, and only two are good

BLUFF          Answer confidently and wrongly.
               Detected within one follow-up, and it
               retroactively discounts everything you said
               before it.

DEFLECT        "That's not really my area."
               True and useless. It ends the conversation
               and demonstrates nothing.

ADMIT AND STOP "I don't know."
               Honest, and it leaves the interviewer with
               nothing to score.

ADMIT AND      "I don't know. Here's how I'd find out, and
REASON         here's what I'd expect based on adjacent
               things I do know."
               The answer.

Commonly confused with a failure state. The interviewer is often not testing the fact; they are testing the edge. A candidate who reasons well from incomplete knowledge is more useful than one who has memorised more facts, because production regularly presents problems nobody has memorised.

The problem it solves

Bluffing is the single most expensive mistake available in a technical interview, and it is expensive in a specific way:

You bluff on question 4. The interviewer probes and finds
the bottom of it.

Now:
  - question 4 is a fail
  - questions 1 to 3 are re-examined: were those bluffs too?
  - questions 5 onward are heard sceptically
  - the interviewer's note says "confidently wrong", which
    is the worst thing that can be written about a staff
    candidate

*** One bluff costs more than three "I don't know"s. ***

And the reason it matters beyond the interview: a staff engineer who cannot say "I don't know" is dangerous. They make confident assertions in design reviews that others build on, and the cost lands months later.

Mechanics

The four-part response

1. SAY YOU DO NOT KNOW, PLAINLY AND QUICKLY.
   No hedging, no "well, it depends", no talking around it.
   "I don't know" or "I haven't worked with that."
   Getting this out fast is what buys credibility for the
   rest.

2. SAY WHAT YOU DO KNOW THAT IS ADJACENT.
   "I haven't used Cassandra, but I've worked with DynamoDB,
   and I'd expect the partition key considerations to be
   similar because both are..."
   This is where the reasoning is demonstrated.

3. REASON TOWARD AN ANSWER, LABELLED AS REASONING.
   "So my guess would be X, and here's why. I'd want to
   verify that."
   The label matters: an unlabelled guess is a bluff.

4. SAY HOW YOU WOULD FIND OUT.
   "I'd read the section of the docs on compaction, and I'd
   test it with a small experiment because the documentation
   for this kind of thing is often optimistic."
   Specific, not "I'd look it up."

Step 2 is where the value is. Almost nothing is genuinely disconnected from what you know, and reasoning from an adjacent system demonstrates exactly the transferable understanding a staff loop is trying to measure.

Worked, on a question outside the candidate's experience

Q: "How does Kafka's exactly-once semantics interact with
    compacted topics?"

BAD (bluff)
  "It works the same way, the transaction coordinator
   handles it." (Confidently wrong, probed in one question.)

BAD (deflect)
  "We didn't use compaction." (True, and it stops here.)

BAD (admit and stop)
  "I don't know." (Honest, unscoreable.)

GOOD
  "I don't know that specific interaction, so let me reason
   about it and then tell you what I'd check.

   What I do know: exactly-once in Kafka is the idempotent
   producer plus transactions, and consumers need
   read_committed to not see aborted messages. And log
   compaction keeps the latest value per key and removes
   older ones in the background.

   So the interesting question is what compaction does to
   the transaction markers, because a consumer needs those
   to know which messages are committed. My guess is that
   compaction has to preserve them, or at least preserve
   enough state that read_committed still works, because
   otherwise a compacted topic couldn't support
   transactional reads at all.

   What I'd check: whether transaction markers are exempt
   from compaction, and what happens to the last-stable-
   offset on a compacted topic. I'd look at the KIP that
   introduced transactions and test it with a small
   producer-consumer pair, because this is exactly the kind
   of thing where the documented behaviour and the actual
   behaviour diverge."

What that demonstrates, none of which required knowing the answer: that the candidate understands exactly-once's mechanism, understands compaction's mechanism, can identify where two mechanisms interact, can form a hypothesis with a reason, and has a verification instinct. That is more staff-level signal than the correct fact would have been.

Knowing which kind of unknown it is

Different unknowns deserve different responses, and misclassifying is a separate mistake.

A FACT I HAVE NOT MEMORISED
  "What's the default value of X?"
  -> Say you would look it up, and move on quickly. Do not
     reason at length about a lookup. Reasoning about a
     constant looks like padding.

A SYSTEM I HAVE NOT USED
  "How does Vitess handle resharding?"
  -> Full four-part response. Reason from the systems you
     do know.

A DOMAIN I HAVE NOT WORKED IN
  "How would you design for HIPAA compliance?"
  -> Say what you do not know, ask what constraints matter
     here, and reason about the general shape: data
     classification, access control, audit, retention. And
     say you would involve counsel, because "I'd get a
     lawyer" is the correct answer to a legal question and
     candidates avoid it.

A QUESTION WITH NO ANSWER
  Sometimes the interviewer is probing whether you will
  invent one.
  -> "I don't think there's a general answer to that. It
     depends on X and Y, and here's how I'd decide in a
     specific case."

The fact-versus-system distinction matters practically: reasoning at length about a default value wastes the interviewer's time and looks like you are avoiding admitting a gap. Reasoning at length about an unfamiliar system is exactly what they want.

Calibrating confidence out loud

Signalling how sure you are, continuously, is what makes the whole interview more credible.

"I'm confident about this."
"I'm fairly sure, maybe 80 percent."
"I think this is right but I'd verify it."
"I'm speculating here."
"I don't know."

Using the full range rather than only the extremes is the signal. A candidate who says everything with equal confidence is either bluffing sometimes or under-selling their strong answers, and both are worse than accurate calibration.

And the consequence is asymmetric in your favour: a candidate who has said "I'm speculating" three times has earned belief when they say "I'm confident about this."

When you realise you were wrong mid-answer

"Actually, let me correct myself. I said X, and thinking
 about it, that's wrong because Y. It's actually Z."

This is a POSITIVE signal, not a recovery. It demonstrates
that you monitor your own reasoning, which is exactly what
you want in someone making architectural decisions.

What is negative is defending an answer you have realised is
wrong, and interviewers can usually tell the difference
between someone thinking and someone digging in.

The one time to guess

If the interviewer explicitly asks you to:
  "I know you haven't seen this. What's your instinct?"

Then guess, and label it: "My instinct is X, and I'd put
maybe 60 percent on it, for this reason."

Refusing to guess when invited reads as risk-aversion, which
is its own negative signal at staff level. The invitation is
usually a test of whether you can commit to a position under
uncertainty, which is a large part of the job.

A worked example: the same gap handled two ways

Q: "Walk me through how you'd debug a Kubernetes pod that's
    being OOM-killed, when the JVM heap looks fine."

THE CANDIDATE HAS NOT DEBUGGED THIS SPECIFIC THING.

VERSION A (bluffs, then unravels)
  "You'd look at the heap settings and increase the memory
   limit."
  Q: "Heap is fine and at 40% of the limit. What else?"
  "Maybe a memory leak?"
  Q: "In what?"
  "...the application?"
  -> Three questions to the bottom. Note reads
     "surface-level".

VERSION B (reasons from adjacent knowledge)
  "I haven't debugged this exact case, so let me reason
   about it.

   The key fact is that the container's memory limit counts
   ALL memory in the cgroup, not just heap. So heap being
   fine and the container being killed means the memory is
   somewhere outside the heap.

   The candidates, roughly in order of how often I'd expect
   them: metaspace, which isn't in the heap and grows with
   loaded classes; direct byte buffers, which NIO and Netty
   use heavily and which are off-heap by design; thread
   stacks, which at 1 MB default times a few thousand
   threads is gigabytes; and native allocations from
   something like a compression or crypto library.

   How I'd narrow it: NativeMemoryTracking on the JVM to
   get the breakdown, and compare the container's RSS
   against the JVM's reported total, because the gap is the
   native allocation. If NMT accounts for it, it's one of
   the JVM regions; if it doesn't, it's a native library.

   And the thing I'd check first, because it's the cheapest:
   whether MaxRAMPercentage is set, because a JVM that
   doesn't know it's in a container will size the heap
   against the host's memory rather than the limit."

Version B does not know the answer either. It knows that the cgroup counts more than heap, which is one fact, and everything else is derived. That is the demonstration, and it is worth more than having debugged this exact case before.

Production evidence

Structured interview research consistently finds that assessing reasoning process predicts job performance better than assessing knowledge recall, which is why interviewers deliberately push to the edge of a candidate's knowledge rather than staying within it.

Amazon's "Are Right, A Lot" leadership principle is explicitly paired with "seek diverse perspectives and work to disconfirm their beliefs", and Amazon's interviewer guidance treats willingness to be wrong as part of the signal rather than a deduction.

Google's published interview guidance tells candidates to think aloud and states that the process is being assessed, not only the answer, which is the same instruction as labelling your reasoning.

The Dunning-Kruger literature and the broader work on calibration is the basis for the confidence-signalling advice: accurate self-assessment is itself a measurable skill, and people who use the full confidence range are better calibrated than those who use only the extremes.

Postmortem culture in SRE practice rests on the same behaviour: an engineer who cannot say "I was wrong about the cause" makes incident reviews useless, which is why the trait is assessed rather than tolerated.

The debate

The case for admitting gaps immediately: honesty is cheap, bluffing is catastrophic when detected, and the reasoning demonstration is worth more than the fact. Interviewers explicitly value it.

The case against over-admitting: a candidate who says "I don't know" to six questions has demonstrated a knowledge gap regardless of how well they reasoned, and at some point the cumulative signal is that the candidate does not know enough for the level. There is a real threshold.

The case for attempting an answer: some interviewers read an immediate "I don't know" as giving up, particularly if the question was answerable by reasoning, and attempting it is what they wanted.

My position: say you do not know quickly, then reason from adjacent knowledge, and label the reasoning as reasoning.

The speed matters. Hedging around a gap for thirty seconds before admitting it is worse than admitting it in three, because the hedging reads as an attempted bluff that failed, and the interviewer has watched you decide whether to try it.

The labelling is what separates reasoning from bluffing, and it is a single phrase: "so my guess would be X, and I'd want to verify that". Without it, the same words are a confident assertion and are scored as a bluff if wrong. An unlabelled guess is a bluff regardless of intent.

On the cumulative-gaps objection, which is real: the answer is not to admit fewer gaps, it is that reasoning well converts a gap into a partial pass. Six "I don't know"s is a fail; six "I don't know, here's how I'd reason about it" answers where three of the reasonings are good is a mixed but recoverable signal, and the difference is entirely in what follows the admission.

The behaviour I would highlight as a positive rather than a recovery is correcting yourself mid-answer. It demonstrates that you monitor your own reasoning, which is precisely what you want in someone whose design-review assertions others will build on. Defending an answer you have realised is wrong is the negative, and interviewers can usually tell the difference.

Where I would push back on the conventional advice: when explicitly invited to guess, guess. "I know you haven't seen this, what's your instinct" is a test of whether you can commit to a position under uncertainty, and refusing reads as risk-aversion, which at staff level is its own negative. Label the confidence and commit.

Follow-up Q&A

"What do you do when you don't know something?" Four things, in order. Say I don't know, plainly and fast, because hedging around it for thirty seconds is worse than admitting it in three. Say what I know that is adjacent, which is where the reasoning gets demonstrated. Reason toward an answer and label it as reasoning, because an unlabelled guess is a bluff regardless of intent. And say specifically how I would find out, not "I'd look it up" but which document and what experiment.

"Why is bluffing so costly?" Because it is detected in one follow-up and it is retroactive. Question four is a fail, questions one to three get re-examined as possible bluffs, everything after is heard sceptically, and the note says "confidently wrong", which is the worst thing that can be written about a staff candidate. One bluff costs more than three admissions. And beyond the interview, a staff engineer who cannot say "I don't know" makes confident assertions in design reviews that others build on.

"Doesn't admitting too much look bad?" There is a real threshold, and the answer is not to admit fewer gaps but that reasoning well converts a gap into a partial pass. Six flat "I don't know"s is a fail. Six "I don't know, here's how I'd reason about it" answers where several reasonings are good is a mixed but recoverable signal, and the entire difference is in what follows the admission.

"Give me an example of reasoning from adjacent knowledge." For a JVM being OOM-killed in a container with the heap looking fine: I might not have debugged that exact case, and I know that the container's limit counts everything in the cgroup, not just heap. So the memory is outside the heap, and the candidates are metaspace, direct byte buffers, thread stacks and native library allocations. Then NativeMemoryTracking to get the breakdown, comparing container RSS to the JVM's reported total, because the gap is native. That is one fact plus derivation, and it is more signal than having seen it before.

"Are all unknowns the same?" No, and misclassifying is its own mistake. A fact I have not memorised, like a default value, deserves "I'd look it up" and moving on quickly, because reasoning at length about a constant looks like padding. A system I have not used deserves the full four-part response. A domain I have not worked in, like HIPAA, deserves saying what I do not know, asking which constraints matter, reasoning about the general shape, and saying I would involve counsel, which candidates avoid and which is the correct answer to a legal question.

"What if you realise mid-answer that you were wrong?" Say so immediately: "let me correct myself, I said X and that's wrong because Y". That is a positive signal rather than a recovery, because it demonstrates you monitor your own reasoning, which is exactly what you want in someone making architectural decisions. The negative is defending an answer you have realised is wrong, and interviewers can usually tell the difference between thinking and digging in.

"Should you ever guess?" Yes, when explicitly invited. "I know you haven't seen this, what's your instinct" is a test of whether you can commit to a position under uncertainty, and refusing reads as risk-aversion, which at staff level is its own negative. Guess, label the confidence, and give the reason: "my instinct is X, maybe sixty percent, for this reason".

"How do you signal confidence during the rest of the interview?" By using the full range rather than only the extremes. "I'm confident about this", "fairly sure, maybe eighty percent", "I think so but I'd verify", "I'm speculating", "I don't know". A candidate who says everything with equal confidence is either bluffing sometimes or under-selling their strong answers. And it compounds in your favour: someone who has said "I'm speculating" three times has earned belief when they say "I'm confident".

Common misconceptions

"Admitting a gap is a fail." It is unscoreable only if you stop there. Reasoning from adjacent knowledge converts it into a demonstration of exactly what a staff loop measures.

"Reasoning out loud sounds like waffling." Not if you label it: "this is a guess and here's why" is a completely different act from an unlabelled assertion.

"Interviewers ask things they expect you to know." They deliberately reach the edge, because behaviour at the edge predicts behaviour in production.

"You should attempt every question." For a memorised constant, reasoning at length is padding. Say you would look it up and move on.

"Correcting yourself looks bad." It is a positive signal. Defending an answer you know is wrong is the negative one.

Interview delivery note

The whole point is behavioural, so the delivery note is the technique itself.

The phrase to have ready, so you are not composing it under pressure: "I don't know that one. Let me reason about it and then tell you what I'd check." Then the adjacent knowledge, then the labelled guess, then the specific verification.

Get the admission out fast, because hedging around a gap is what reads as an attempted bluff: "I haven't worked with that" in three seconds is much better than thirty seconds of "well, it depends on the configuration" before arriving at the same place.

Label every guess: "so my guess would be X, and I'd want to verify that". That single phrase is what separates reasoning from bluffing, and without it the same words are scored as a confident assertion.

Use the confidence range throughout the rest of the interview, not just at the gaps, because it is what makes the range meaningful: "I'm confident about this one" only carries weight if you have also said "I'm speculating here" somewhere.

And if you realise you were wrong, say so immediately and plainly: "Let me correct myself." It is a positive, and hoping the interviewer did not notice is the worse bet.

Further reading

• Google's "How we hire" guidance on thinking aloud and on process being assessed alongside the answer.
• Amazon's leadership principles, particularly "Are Right, A Lot" paired with the disconfirming-evidence framing.
• The calibration literature (Lichtenstein, Fischhoff and Phillips on calibration of probabilities), for why using the full confidence range is itself a skill.
• Schön, The Reflective Practitioner, for reasoning under uncertainty as the defining professional skill rather than an exception to it.

Track A: the coding round

Staff and TL loops still have coding rounds. Google, Meta, Stripe, Databricks, Uber and most AI labs keep at least one, and the candidates who fail them are usually the ones who assumed seniority made them optional. The bar is not harder problems than a senior loop gets. It is cleaner code, better tests, and no flailing.

That makes this chapter two different things at once. The first page is about behaviour: the five things a staff candidate does that a senior candidate does not, which are worth more marks than any single algorithm and are trainable in a way that inventing algorithms under pressure is not. The remaining six pages are the pattern checklist, twelve patterns that between them cover the overwhelming majority of what gets asked, grouped so that patterns which share an idea are taught together rather than as a list to memorise.

Read the first page even if you skip the rest. The five behaviours (contract before algorithm, tests unprompted, complexity stated before coding, an answer ready for "make it production", and restraint about abstraction) are where experienced candidates actually lose these rounds.

Every page here carries runnable code, included verbatim from the section's code/ directory, and every output block on these pages was produced by running it. The volume target from the source is about 70 to 90 problems total at roughly 20 percent easy, 65 percent medium and 15 percent hard, not the 400-problem grind. The drill format is 35 minutes, timed, out loud, in a plain editor, with one session a week recorded and watched back.

What this chapter covers

• [done] What changes about coding rounds at staff level
• [done] Hash maps, two pointers, sliding windows and prefix sums
• [done] Binary search, search on the answer, and monotonic stacks
• [done] Graph traversal, topological sort and union-find
• [done] Heaps, top-K, intervals and the sweep line
• [done] Backtracking with pruning, and tries
• [done] Dynamic programming: 1D, 2D, knapsack, LIS, edit distance

Source: §4.

What changes about coding rounds at staff level

What it is

Staff and TL loops still have coding rounds. Google, Meta, Stripe, Databricks, Uber and most AI labs all keep at least one, and candidates who assume seniority exempts them from it are the ones who fail it. The bar is not harder problems. It is cleaner code, better tests, and no flailing. A staff candidate and a senior candidate are usually given the same question, and the separation happens in the five minutes before any algorithm is written and the five minutes after it works.

Concretely, five behaviours separate the two, and each of them is trainable independently of your algorithm knowledge:

1. Talk about the API before the algorithm. Name the types, name the contract.
2. Write tests unprompted. Even three assertions. This is a differentiator at every level above senior.
3. State complexity before coding, then verify after.
4. Handle the "make it production" follow-up: what breaks at 100 times the input, where does it go concurrent, what is the failure mode.
5. Do not over-abstract. Staff candidates lose points for building a factory when a function was asked for.

Don't be confused: "staff coding rounds are easier" is a misreading of a true observation. The problems are often no harder, and are sometimes easier, than what a new grad gets. What changes is the rubric. A senior candidate is graded mostly on whether the algorithm is correct and reasonably efficient. A staff candidate is graded on that plus judgement: did you clarify the contract, did you test, did you know your own complexity, did you recognise the production failure mode, did you resist over-engineering. You can solve the problem perfectly and still be rated below the bar for skipping all five, and this is the most common way strong engineers fail these loops.

The problem it solves

The coding round exists at this level for a reason that is not "can you code". It is a sampling of how you will behave when you write code that other people depend on. Every one of the five behaviours maps to something a team actually needs: contracts before implementations, tests as a default rather than an afterthought, honest cost estimates, awareness of scale limits, and restraint about abstraction. The interviewer is extrapolating from forty minutes to two years.

That framing is also what makes the round trainable. You cannot reliably become better at inventing algorithms under pressure in eight weeks. You can absolutely become someone who always states the contract first, always writes three assertions, and always volunteers the complexity, and those are worth more marks than the one hard problem you might have missed.

Mechanics

The five behaviours on a deliberately small problem, so nothing is hidden by the algorithm. The question, as an interviewer would give it: "Given a list of log lines, return the k endpoints with the most requests."

"""What a staff-level coding answer looks like, on a deliberately small problem.

Runnable: `python3 staff_coding_style.py`. The problem is trivial on purpose.
What is being demonstrated is the ORDER of work and the surrounding behaviour,
because at staff level those are what the round measures.

The problem, as an interviewer would state it:
    "Given a list of log lines, return the k endpoints with the most requests."
"""

import heapq
import random
from collections import Counter
from dataclasses import dataclass


# --- Step 1: the contract, before any algorithm ------------------------------
# Naming the types first is the single cheapest way to surface the ambiguities.
# Writing these four lines out loud produced three questions that changed the
# implementation, which is the point.
@dataclass(frozen=True)
class LogLine:
    endpoint: str
    status: int
    latency_ms: float


# Questions the contract surfaced, and the answers assumed here:
#   1. Ties at the k-th position: broken by endpoint name ascending, so the
#      result is deterministic. An unstable answer is untestable.
#   2. Do failed requests count? Assumed yes, since the question said requests,
#      not successful requests. Flagged rather than silently decided.
#   3. k larger than the number of distinct endpoints: return all of them,
#      rather than raising. Padding with nulls would push the problem onto the
#      caller.


def top_endpoints(lines, k):
    """The k endpoints with the most requests, most frequent first.

    Ties are broken by endpoint name ascending. Returns fewer than k entries if
    there are fewer than k distinct endpoints.

    Time:  O(n + m log k) for n lines and m distinct endpoints.
    Space: O(m) for the counter, O(k) for the heap.
    """
    if k <= 0:
        return []
    counts = Counter(line.endpoint for line in lines)
    # Negate the name so that within the min-heap, the endpoint that loses a tie
    # is the one that sorts LATER alphabetically. Strings cannot be negated, so
    # rank by count and resolve the final order in the sort below.
    return heapq.nsmallest(k, counts.items(), key=lambda kv: (-kv[1], kv[0]))


# --- Step 2: tests, written before being asked -------------------------------
# Three assertions was the bar named in the source. These are five, and they are
# chosen to be the cases most likely to be wrong rather than the cases easiest
# to write: empty, ties, k over-large, k non-positive, and a real distribution.
def test_top_endpoints():
    def L(ep):
        return LogLine(ep, 200, 1.0)

    assert top_endpoints([], 3) == [], "empty input"
    assert top_endpoints([L("/a")], 0) == [], "k of zero"
    assert top_endpoints([L("/a")], -1) == [], "negative k"

    # k larger than the distinct count returns everything, not a padded list.
    assert top_endpoints([L("/a"), L("/b")], 5) == [("/a", 1), ("/b", 1)], "k too large"

    # Ties resolve alphabetically, so this is deterministic across runs.
    tied = [L("/z"), L("/z"), L("/a"), L("/a"), L("/m")]
    assert top_endpoints(tied, 2) == [("/a", 2), ("/z", 2)], "tie broken by name"

    real = [L("/search")] * 5 + [L("/health")] * 3 + [L("/index")] * 1
    assert top_endpoints(real, 2) == [("/search", 5), ("/health", 3)], "ordinary case"
    return 6


# --- Step 3: the "make it production" follow-up ------------------------------
# The interviewer asks: what breaks at 100x input? Answering with code beats
# answering with adjectives.
class StreamingTopK:
    """The same question over a stream that does not fit in memory.

    What changed and why:
      - Counter over all endpoints is O(m) memory and m is unbounded when the
        endpoint set includes path parameters (/user/12345). That is the failure
        at 100x, and it is a memory failure, not a speed one.
      - So: bound the tracked set. This is the Space-Saving algorithm, which
        keeps `capacity` counters and, on overflow, evicts the current minimum
        and gives the newcomer that count plus one. The result is approximate,
        with a bounded overestimate, and it never exceeds `capacity` entries.
      - The honest caveat: it can miss a true heavy hitter that arrives late,
        and it over-counts. Both are acceptable for a top-endpoints dashboard
        and are not acceptable for billing. Say which one you are building.
    """

    def __init__(self, capacity=100):
        self.capacity = capacity
        self.counts = {}

    def add(self, endpoint):
        if endpoint in self.counts:
            self.counts[endpoint] += 1
        elif len(self.counts) < self.capacity:
            self.counts[endpoint] = 1
        else:
            victim = min(self.counts, key=self.counts.get)
            self.counts[endpoint] = self.counts.pop(victim) + 1

    def top(self, k):
        return heapq.nsmallest(k, self.counts.items(), key=lambda kv: (-kv[1], kv[0]))


# --- Step 4: what NOT to do --------------------------------------------------
# The over-abstraction failure, shown rather than described. Everything below is
# a faithful reimplementation of top_endpoints, in 4 classes instead of 4 lines.
# It was asked for as a function.
class AbstractCounterStrategy:
    def count(self, lines):
        raise NotImplementedError


class EndpointCounterStrategy(AbstractCounterStrategy):
    def count(self, lines):
        return Counter(line.endpoint for line in lines)


class TopKSelectorFactory:
    @staticmethod
    def create(strategy):
        return TopKSelector(strategy)


class TopKSelector:
    def __init__(self, strategy):
        self._strategy = strategy

    def select(self, lines, k):
        counts = self._strategy.count(lines)
        return heapq.nsmallest(k, counts.items(), key=lambda kv: (-kv[1], kv[0]))


if __name__ == "__main__":
    passed = test_top_endpoints()
    print(f"tests: {passed} assertions passed")

    sample = ([LogLine("/search", 200, 12.0)] * 5
              + [LogLine("/health", 200, 0.4)] * 3
              + [LogLine("/index", 500, 90.0)] * 2)
    print("top_endpoints(k=2)   :", top_endpoints(sample, 2))
    print("top_endpoints(k=99)  :", top_endpoints(sample, 99), "<- fewer than k, not padded")

    # The streaming version on a skewed stream with an unbounded key space, which
    # is the input that breaks the exact version's memory.
    rng = random.Random(7)
    stream = StreamingTopK(capacity=8)
    exact = Counter()
    for _ in range(20000):
        if rng.random() < 0.5:
            ep = rng.choice(["/search", "/health", "/index"])
        else:
            ep = f"/user/{rng.randrange(100000)}"     # unbounded key space
        stream.add(ep)
        exact[ep] += 1
    print()
    print("distinct endpoints seen  :", len(exact))
    print("exact counter entries    :", len(exact), "<- unbounded memory")
    print("streaming counter entries:", len(stream.counts), "<- bounded at capacity")
    print("streaming top 3          :", stream.top(3))
    print("exact top 3              :", heapq.nsmallest(
        3, exact.items(), key=lambda kv: (-kv[1], kv[0])))

    over = TopKSelectorFactory.create(EndpointCounterStrategy()).select(sample, 2)
    print()
    print("the over-abstracted version returns:", over)
    print("identical output, 4 classes instead of 4 lines, and a function was asked for")

Read that file in the order the work happens.

The contract comes first, and it is where the questions come from. Writing the LogLine dataclass and the docstring surfaced three ambiguities that the problem statement did not settle: how ties are broken, whether failed requests count, and what happens when k exceeds the number of distinct endpoints. Each of those is a question worth asking out loud, and none of them occurs to you until you try to name the types. That is the actual mechanism behind "talk about the API first": it is not a ritual, it is a generator of the clarifying questions interviewers are waiting to hear. The comment block records both the question and the assumption taken, which is what you would do in a code review.

The complexity line is in the docstring, written before the body. O(n + m log k) for $n$ lines and $m$ distinct endpoints. Stating it before coding commits you, and then verifying it afterwards catches the case where your implementation is not the algorithm you described. Writing it in the docstring rather than saying it aloud means it survives into the artifact.

The tests are chosen for the cases most likely to be wrong, not the cases easiest to write. Empty input, k = 0, negative k, k larger than the distinct count, and a tie. Notice that four of the six assertions are boundary conditions and only one is an ordinary case. A test suite that exercises the happy path three times demonstrates nothing; the selection of cases is the signal, not the count.

StreamingTopK is the production follow-up answered in code. The exact version's failure at scale is not speed, it is memory: a Counter grows with the number of distinct endpoints, and once endpoints include path parameters like /user/12345 that set is unbounded. The fix is the Space-Saving algorithm, which keeps a fixed number of counters and on overflow evicts the current minimum, giving the newcomer that count plus one. It is approximate with a bounded overestimate, and the docstring states exactly what that buys and costs.

The last section is the anti-pattern, shown rather than described. Four classes, an abstract base, a factory and a strategy, producing byte-identical output to a four-line function that was what the interviewer asked for. It is in the file because reading it next to top_endpoints makes the point more sharply than any advice about over-engineering.

Worked example

tests: 6 assertions passed
top_endpoints(k=2)   : [('/search', 5), ('/health', 3)]
top_endpoints(k=99)  : [('/search', 5), ('/health', 3), ('/index', 2)] <- fewer than k, not padded

distinct endpoints seen  : 9518
exact counter entries    : 9518 <- unbounded memory
streaming counter entries: 8 <- bounded at capacity
streaming top 3          : [('/health', 3363), ('/index', 3351), ('/search', 3315)]
exact top 3              : [('/health', 3362), ('/index', 3351), ('/search', 3315)]

the over-abstracted version returns: [('/search', 5), ('/health', 3)]
identical output, 4 classes instead of 4 lines, and a function was asked for

The three numbers that make the production argument are 9518, 9518 and 8. Twenty thousand events over an unbounded key space produced 9,518 distinct endpoints. The exact counter holds all of them and would hold ten million on a real day. The streaming counter holds 8, which is the capacity it was given, permanently, regardless of stream length. That is the difference between an approach that works on the interviewer's sample and one that works on Tuesday's traffic.

Look at /health: 3363 streaming against 3362 exact. The approximation is off by exactly one, in the upward direction, and that is not luck. Space-Saving's guarantee is that it never undercounts, because an evicted victim's count is inherited by the newcomer. So the reported count is an upper bound on the true count, and the error is bounded by the number of evictions. Being able to say "it overestimates, never underestimates, and here is why" is what makes it an engineering choice rather than a hopeful one, and it leads directly to the sentence that matters: this is fine for a top-endpoints dashboard and is not fine for billing.

The k=99 line exists to make an assumption visible in the output. Returning three results when 99 were asked for is a decision, and the alternatives (raise, or pad with nulls) are defensible too. The failure is not picking wrong, it is picking silently.

Production evidence

The five behaviours are visible in how strong teams actually work, which is why they are graded. Contract-first design is the premise of interface definition languages: protobuf and OpenAPI schemas exist so that the contract is written, reviewed and versioned before any implementation. When an interviewer asks you to name types first, they are asking for the thing your team already requires of a new service.

Space-Saving and its relatives are deployed, not academic. The heavy-hitters problem is solved in production by exactly this family of bounded-memory sketches: Space-Saving, Count-Min Sketch, and the topk structures in Redis's RedisBloom module. Any system reporting "top talkers", "top endpoints" or "top offending IPs" over high-volume traffic is running one, because the exact version does not fit.

Tests-with-the-first-commit is a norm at the companies running these loops. Google's public engineering practices documentation makes tests part of what a code review is expected to check, and the Beyoncé rule ("if you liked it, you should have put a test on it") is from Google's own Software Engineering at Google. When an interviewer notices you wrote assertions without being asked, they are checking for a habit their codebase depends on.

The over-abstraction failure has a name and a literature. "You aren't gonna need it" and "premature abstraction is worse than premature optimisation" are Extreme Programming maxims that predate the current interview format by two decades, and the reason they persist is that the cost of a wrong abstraction is paid by everyone who later has to work around it, while the cost of a duplicated function is paid once.

The debate

Should you write tests before the interviewer asks, given the clock? There is a real cost: three assertions take two or three minutes of a 35 to 45 minute round. The argument against is that a candidate who runs out of time with a tested partial solution scores worse than one who finishes untested. My position: write the tests, and write them after a working solution rather than before. The reason is that the marginal value of the test is highest once code exists (it can find a real bug live, which is a dramatic positive signal) and the risk of the clock is lowest at that point because the algorithm is already done. Test-first is better engineering and worse interview strategy, and it is worth being honest about that rather than pretending they align. If you are running badly out of time, say "here are the three cases I would assert on, in order of what I think is most likely broken" and name them. That captures most of the credit for none of the clock.

How much clarification is too much? Candidates over-corrected by advice to "ask clarifying questions" now spend eight minutes interrogating a twenty-minute problem, and it reads as stalling. The useful discipline: ask only questions whose answers would change your code, and say why each one matters. "Are ties broken by name or is any order fine? It changes whether the output is deterministic and therefore whether I can test it." That sentence is one question, ten seconds, and it demonstrates the reasoning. Three of those is plenty. Questions whose answer would not change anything are noise.

When is abstraction actually correct in a coding round? When the problem statement itself contains the variation. If the interviewer says "and later we will want to rank by latency instead of count", a parameter or a key function is warranted, and refusing to abstract at that point is its own failure. The rule is not "never abstract", it is abstract in response to a stated requirement, never in anticipation of an imagined one. The key=lambda kv: (-kv[1], kv[0]) in top_endpoints is exactly the right amount: it is one parameter's worth of flexibility, in the place the requirement pointed at.

Is the volume target realistic? The source's guidance is roughly 70 to 90 problems total, at a distribution of about 20 percent easy, 65 percent medium and 15 percent hard, rather than the 400-problem grind. I would defend that number as correct for this level and add the reason: at staff level, the marginal return on problem 200 is close to zero, because the round is not testing pattern recall at that depth, while the marginal return on recording yourself solving problem 30 and watching it back is large. Depth over count is not a comfort; it is what the rubric implies.

On which 70 to 90: a curated, pattern-organised list beats picking problems by difficulty tag, because the point is coverage of the twelve patterns rather than volume. NeetCode 150 is the list I would use, since it is explicitly grouped by pattern and its groups map almost one to one onto the six pages that follow, which makes gaps visible: if you have done no union-find problems, the list shows it, whereas a difficulty-sorted queue hides it. Work one pattern to the point where the recognition is automatic before moving on, rather than sampling across patterns, because the failure mode in a real round is not being unable to implement a pattern you recognise; it is not recognising which pattern the problem is.

Follow-up Q&A

What exactly is the drill format? Timed, 35 minutes, out loud, in a plain editor with no autocomplete and no language server. Record yourself once a week and watch the recording. Every element of that is doing work: the timer builds the pacing instinct, speaking out loud trains the narration you will be graded on, the plain editor removes the completion crutch you will not have in a shared doc, and the recording is the only way to see your own flailing, which is invisible from the inside. It is unpleasant and it is the single highest return practice in the whole track.

How do I narrate without either going silent or babbling? Narrate decisions, not keystrokes. "I am choosing a min-heap so eviction is at the top" is a decision. "Now I type a for loop" is a keystroke. When you need to think silently, say so: "give me twenty seconds to think about the state definition" is a completely acceptable sentence and is far better than either dead air or filler. Interviewers are taking notes during your silences anyway.

What do I do when I am genuinely stuck? Say what you have ruled out and why, then state the simplest thing that would work. "Brute force here is $O(n^2)$ and I can write it in two minutes. I think there is an $O(n \log n)$ using a sorted structure but I have not closed it. Shall I write the brute force first so we have something correct, and then optimise?" That is a staff-level response to being stuck: it is honest, it makes progress, it manages the clock, and it hands the interviewer a decision they are usually happy to make. Silent flailing for eight minutes is what fails.

The interviewer asks "how would you make this concurrent?" What are they looking for? Where the shared mutable state is, and what you would do about it. In top_endpoints, the counting phase is embarrassingly parallel (partition the lines, count independently, merge the counters, because addition is associative and commutative) and the top-k selection is cheap and serial. That decomposition, map-reduce with a named reason why the merge is valid, is the answer. The wrong answer is reaching for a lock around a shared counter, which serialises the parallel part. If asked about the streaming version, note that Space-Saving's merge is not exact, which is a genuine and interesting complication.

How do I answer "what breaks at 100 times the input?" if I have not thought about it? Work through the resources in order: memory, then time, then I/O, then coordination. Ask of each: what grows? In top_endpoints, memory grows with distinct endpoints and time grows with lines, so at 100 times, if the line count grows but the endpoint set does not, you are fine; if the endpoint set is unbounded, memory is the wall. Naming which of the two grew is the whole answer, and that checklist works on any problem.

Do these expectations differ between a staff IC loop and a TL loop? The coding bar is essentially identical; both want the five behaviours. The difference appears in the follow-up discussion, where a TL loop is more likely to push on "how would you get a team to maintain this" and "how would you review this PR", and a staff IC loop is more likely to push on the scale and correctness limits. Prepare the same way and expect the follow-up to tilt.

Common misconceptions

"At staff level they care about design, not coding, so I can skip practice." The round exists, it is scored, and it is the most common single point of failure for experienced candidates precisely because they under-prepare it relative to the design rounds. Light daily practice is maintenance; skipping it entirely is not a strategy.

"Writing tests will make me run out of time." Three assertions is two minutes. The candidates who run out of time do so because they started coding before understanding the problem, not because they tested.

"Stating complexity is a formality since the interviewer can see the code." They can, and they are checking whether you can. Stating a bound before coding and then discovering your implementation does not match it is a normal, recoverable event that reflects well on you if you catch it yourself. Never stating one means the question gets asked, and then you are answering rather than volunteering.

"Clean code means extracting helper functions." Sometimes. In a 35-minute round, extracting a helper used once usually costs clarity, because the reader now has to jump around a small file. Clean here means good names, no dead code, handled edge cases, and a correct docstring. It does not mean structure for its own sake, which is the over-abstraction failure in a different costume.

Interview delivery note

The opening thirty seconds are worth rehearsing until they are automatic, because they set the frame for everything after. Something close to: "Before I code, let me state the contract. Input is a list of log lines, each with an endpoint, a status and a latency. Output is the k endpoints with the highest request count, most frequent first. Two things the statement leaves open: how ties break, and what happens if k exceeds the number of distinct endpoints. I will assume ties break by name so the output is deterministic and testable, and that we return fewer than k rather than padding. Complexity target is O(n) to count plus O(m log k) to select. Sound right?"

That is one breath, it contains the contract, two clarifying questions with their justifications, an assumption stated rather than hidden, and a complexity commitment. Almost nobody does it, and every interviewer notices.

The senior-to-staff separator across this whole page is the direction of the information flow. A senior candidate answers well: asked about complexity, they give it; asked what breaks at scale, they reason it out. A staff candidate volunteers: the contract, the assumption, the complexity, the test cases and the scaling limit all arrive without being requested, in the order a colleague would want them. The content can be identical. What differs is who had to ask, and that is the thing the interviewer writes down.

Further reading

• Titus Winters, Tom Manshreck and Hyrum Wright. Software Engineering at Google. O'Reilly, 2020. The testing culture chapters, for why "tests unprompted" is a hiring signal rather than a preference.
• Ahmed Metwally, Divyakant Agrawal and Amr El Abbadi. "Efficient Computation of Frequent and Top-k Elements in Data Streams." ICDT 2005. The Space-Saving algorithm used above, including the proof that it never undercounts.
• Google's Code Review Developer Guide, for what "clean code" is actually graded against inside one of the companies running these loops.
• Steve McConnell. Code Complete, 2nd ed. Chapter 5, on the cost of abstraction chosen before the requirement that justifies it.

Hash maps, two pointers, sliding windows and prefix sums

What it is

Four patterns that between them account for more interview problems than every other pattern combined, and that share a single underlying move: replace a nested loop by carrying state across the outer loop. The brute force is always "for each position, scan the rest". Each pattern is a different answer to "what could I remember from the earlier positions that makes the inner scan unnecessary?"

Hash map / frequency counting remembers what has been seen, so a membership question costs $O(1)$ instead of a scan. Two pointers exploits sorted order so that a failed comparison rules out a whole region rather than one candidate. Sliding window maintains an aggregate over a contiguous range and updates it incrementally as the range moves. Prefix sums precompute cumulative totals so any range sum is one subtraction, and their dual, the difference array, does the reverse: it makes range updates cheap and pays once at the end.

Don't be confused: two pointers and sliding window are not the same pattern. They look identical (two indices moving through an array) and are often taught together, which hides the distinction that decides which one a problem wants. Two pointers usually moves its indices toward each other from the ends of a sorted array, and each step discards a candidate permanently. Sliding window moves both indices in the same direction over an array whose order is fixed by the problem, and it maintains an aggregate over the span between them. Sorting destroys a sliding window problem, because the contiguity it depends on is the input's order. If you catch yourself wanting to sort before a window problem, you have misread the problem.

The second distinction that matters: a fixed-size window and a variable-size window are different code. Fixed size adds the entering element and drops the leaving one in lockstep. Variable size advances the right edge greedily and advances the left edge only when an invariant breaks. Mixing them up produces code that passes the samples and fails on the edges.

The problem it solves

Concretely: "does any pair in this array sum to a target?" is $O(n^2)$ by nested loop. The hash map version is $O(n)$ because for each element you ask "have I already seen my partner" rather than "will I later find my partner", and the first question is answerable from state you already hold. That inversion, from a forward search to a backward lookup, is the entire trick and it generalises.

"What is the sum of elements 40,000 through 90,000?" costs 50,000 additions, and if the query repeats a million times the cost is unacceptable. One $O(n)$ pass building prefix sums makes every subsequent query a single subtraction. The mirror problem, "add 5 to every element between these two indices, a million times", costs $O(mn)$ done directly and $O(m + n)$ with a difference array.

Mechanics

"""Hash map counting, two pointers, sliding window, prefix sums, difference arrays.

Runnable: `python3 array_patterns.py`. These four patterns cover more interview
problems than any other group, and they share one idea: replace a nested loop by
carrying state across the outer loop.
"""

from collections import Counter, defaultdict


# --- Hash map / frequency counting -------------------------------------------
def two_sum(nums, target):
    """The canonical trade of time for space: instead of asking "is there a
    partner for nums[i] somewhere to my right", record what you have seen and
    ask "have I already seen my partner". One pass, O(n) time and space."""
    seen = {}
    for i, n in enumerate(nums):
        if target - n in seen:
            return (seen[target - n], i)
        seen[n] = i           # after the check, so nums[i] cannot pair with itself
    return None


def group_anagrams(words):
    """Frequency counting where the KEY is the interesting part. Sorting each
    word is O(k log k); a 26-slot count tuple is O(k) and is the better answer
    when words are long."""
    groups = defaultdict(list)
    for w in words:
        key = tuple(sorted(Counter(w).items()))
        groups[key].append(w)
    return [groups[k] for k in sorted(groups, key=lambda k: groups[k][0])]


# --- Two pointers ------------------------------------------------------------
def three_sum(nums):
    """Two pointers is what you get when sorting buys you a decision rule: with
    a sorted array, if the sum is too small only moving LEFT rightwards can help.
    That is what turns O(n^2) inner search into O(n)."""
    nums = sorted(nums)
    out = []
    for i in range(len(nums) - 2):
        if i and nums[i] == nums[i - 1]:
            continue                       # skip duplicate anchors
        lo, hi = i + 1, len(nums) - 1
        while lo < hi:
            s = nums[i] + nums[lo] + nums[hi]
            if s < 0:
                lo += 1
            elif s > 0:
                hi -= 1
            else:
                out.append((nums[i], nums[lo], nums[hi]))
                lo += 1
                while lo < hi and nums[lo] == nums[lo - 1]:
                    lo += 1                # skip duplicate seconds
                hi -= 1
    return out


# --- Sliding window ----------------------------------------------------------
def longest_unique(s):
    """Variable-size window. The invariant: the window [lo, hi] always holds
    distinct characters. When hi breaks it, lo advances just far enough to
    restore it. Each index is visited at most twice, so O(n) not O(n^2)."""
    last = {}
    lo = best = 0
    best_span = (0, 0)
    for hi, ch in enumerate(s):
        if ch in last and last[ch] >= lo:
            lo = last[ch] + 1              # jump, do not step
        last[ch] = hi
        if hi - lo + 1 > best:
            best = hi - lo + 1
            best_span = (lo, hi + 1)
    return best, s[best_span[0]:best_span[1]]


def max_sum_window(nums, k):
    """Fixed-size window. Add the entering element, drop the leaving one. The
    error to avoid is recomputing the sum each step, which is O(nk)."""
    if len(nums) < k:
        return None
    cur = sum(nums[:k])
    best, at = cur, 0
    for i in range(k, len(nums)):
        cur += nums[i] - nums[i - k]
        if cur > best:
            best, at = cur, i - k + 1
    return best, at


# --- Prefix sums -------------------------------------------------------------
def build_prefix(nums):
    """prefix[i] is the sum of the first i elements, so prefix[0] == 0. That
    leading zero is not decoration: it is what makes range_sum need no special
    case for a range starting at index 0."""
    prefix = [0] * (len(nums) + 1)
    for i, n in enumerate(nums):
        prefix[i + 1] = prefix[i] + n
    return prefix


def range_sum(prefix, lo, hi):
    """Sum of nums[lo:hi], half open, in O(1) after O(n) preprocessing."""
    return prefix[hi] - prefix[lo]


def subarrays_summing_to(nums, target):
    """Prefix sums plus a hash map. If prefix[j] - prefix[i] == target then
    prefix[i] == prefix[j] - target, so count how many earlier prefixes had that
    value. Handles negative numbers, which the sliding window cannot."""
    counts = Counter({0: 1})               # the empty prefix, so a match at the start counts
    running = total = 0
    for n in nums:
        running += n
        total += counts[running - target]
        counts[running] += 1
    return total


# --- Difference array --------------------------------------------------------
def apply_range_updates(n, updates):
    """The dual of a prefix sum. To add v to every element of [lo, hi), record
    +v at lo and -v at hi, then take a running sum at the end. Turns m range
    updates from O(m*n) into O(m + n)."""
    diff = [0] * (n + 1)
    for lo, hi, v in updates:
        diff[lo] += v
        diff[hi] -= v
    out, running = [], 0
    for i in range(n):
        running += diff[i]
        out.append(running)
    return out


if __name__ == "__main__":
    nums = [2, 7, 11, 15, 3]
    print("two_sum([2,7,11,15,3], 18) ->", two_sum(nums, 18), "= indices of", 7, "and", 11)
    print("group_anagrams          ->", group_anagrams(["eat", "tea", "tan", "ate", "nat", "bat"]))

    print()
    print("three_sum               ->", three_sum([-1, 0, 1, 2, -1, -4]))
    n, sub = longest_unique("abcabcbb")
    print("longest_unique(abcabcbb)->", n, repr(sub))
    n, sub = longest_unique("pwwkew")
    print("longest_unique(pwwkew)  ->", n, repr(sub))
    print("max_sum_window(k=3)     ->", max_sum_window([2, 1, 5, 1, 3, 2], 3), "(sum, start index)")

    print()
    arr = [3, -1, 4, 1, 5, -9, 2, 6]
    pre = build_prefix(arr)
    print("array                   :", arr)
    print("prefix                  :", pre)
    print("range_sum(2, 6)         ->", range_sum(pre, 2, 6), "= sum of", arr[2:6])
    print("subarrays summing to 5  ->", subarrays_summing_to(arr, 5))

    print()
    ups = [(1, 4, 10), (2, 6, 5), (0, 3, -2)]
    print("n=7, updates            :", ups)
    print("difference array result :", apply_range_updates(7, ups))

Four details worth defending under questioning.

In two_sum, the insert happens after the check. Write seen[n] = i before the if and an element pairs with itself, so two_sum([3, 5], 6) wrongly returns (0, 0). The ordering is the correctness argument, not a style choice.

The prefix array has a leading zero and is length $n+1$. prefix[i] is the sum of the first $i$ elements, so prefix[0] = 0 denotes the empty prefix. This is what lets range_sum be prefix[hi] - prefix[lo] with no special case when lo == 0. Build it without the leading zero and you will write a branch, and that branch is where the off by one lives.

longest_unique jumps the left edge, it does not step it. On seeing a repeat, lo moves to last[ch] + 1 directly. A loop that increments lo one character at a time is still $O(n)$ amortised, so it is not wrong, but the guard last[ch] >= lo is essential in the jumping version: without it, a character last seen before the current window drags lo backwards and the window grows to include duplicates.

subarrays_summing_to seeds the counter with {0: 1}. That entry represents the empty prefix and is what allows a qualifying subarray that starts at index 0 to be counted. Drop it and you undercount by exactly the number of qualifying prefixes, which is the kind of bug that passes half the tests.

Worked example

two_sum([2,7,11,15,3], 18) -> (1, 2) = indices of 7 and 11
group_anagrams          -> [['bat'], ['eat', 'tea', 'ate'], ['tan', 'nat']]

three_sum               -> [(-1, -1, 2), (-1, 0, 1)]
longest_unique(abcabcbb)-> 3 'abc'
longest_unique(pwwkew)  -> 3 'wke'
max_sum_window(k=3)     -> (9, 2) (sum, start index)

array                   : [3, -1, 4, 1, 5, -9, 2, 6]
prefix                  : [0, 3, 2, 6, 7, 12, 3, 5, 11]
range_sum(2, 6)         -> 1 = sum of [4, 1, 5, -9]
subarrays summing to 5  -> 4

n=7, updates            : [(1, 4, 10), (2, 6, 5), (0, 3, -2)]
difference array result : [-2, 8, 13, 15, 5, 5, 0]

Trace the difference array, because it is the pattern most people have never actually implemented. Three updates land on a 7-element array: add 10 to [1,4), add 5 to [2,6), add -2 to [0,3). The difference array records only six numbers, two per update, and the final running sum produces [-2, 8, 13, 15, 5, 5, 0]. Check index 2 by hand: it is inside all three ranges, so it should be $10 + 5 - 2 = 13$, and it is. Index 4 is inside only the second range, so it should be 5, and it is. Index 6 is outside all three, so 0. The array is length $n+1$ because the closing marker for a range ending at $n$ has to go somewhere, and dropping that slot is the standard crash.

longest_unique("pwwkew") returning 'wke' rather than 'pww' or 'wke w' is the case that catches the missing last[ch] >= lo guard: by the time the window reaches the second w at index 5, the character w was last seen at index 2, which is inside the current window, so lo correctly jumps to 3.

subarrays_summing_to(arr, 5) returning 4 on [3, -1, 4, 1, 5, -9, 2, 6] is the case that justifies the hash map over a sliding window: the array contains -9, and a sliding window requires that extending the window never decreases the aggregate. Negative numbers break that monotonicity, so the window approach silently returns a wrong answer here while the prefix-sum approach is correct. Interviewers add a negative number for exactly this reason.

Production evidence

Summed-area tables are 2D prefix sums. The Viola-Jones face detector (2001) computes an "integral image" once per frame, after which the sum of any rectangle is four array lookups regardless of rectangle size. That is the only reason the cascade could evaluate thousands of rectangle features per window in real time on 2001 hardware. OpenCV exposes it directly as cv::integral.

Sliding windows in stream processing. Flink and Kafka Streams both implement windowed aggregations by maintaining incremental state and updating it as records enter and leave the window, rather than recomputing over the window's contents. The fixed-size add-and-drop in max_sum_window is the same arithmetic, and the same reason: recomputation is $O(nk)$ and does not survive contact with a real event rate.

Sliding window rate limiters. The "sliding window counter" algorithm used by API gateways and CDN edge configurations keeps per-interval counts and weights the partial overlap, precisely to avoid the boundary burst that a fixed-window counter allows (two full quotas within one window length, straddling the reset).

Frequency counting at a scale where the hash map does not fit. When the key space is too large to count exactly, the production move is a Count-Min Sketch, which trades exact counts for a bounded overestimate in fixed memory. Naming this in an interview is the sign that you have thought past the whiteboard version, and it connects directly to the heavy-hitters problem the top-K pattern solves.

Two pointers is the merge step. The merge in merge sort, and the merge join in every relational database's execution engine, is two pointers over sorted inputs. Postgres chooses a merge join when both sides are already sorted or cheaply sortable, exactly because the pointer walk is linear once the ordering is paid for.

The debate

When do you sort first? Sorting costs $O(n \log n)$ and buys you the two-pointer decision rule. It is worth it when the alternative is $O(n^2)$, which is why three_sum sorts. It is not worth it when a hash map already gives you $O(n)$, which is why two_sum does not. The trap is that sorting also destroys index information, so any problem asking for original indices needs either a hash map or an explicit index-carrying sort. My rule: reach for the hash map first, and sort only when you need an ordering property that hashing cannot give you, namely "everything to my left is smaller".

Sliding window versus prefix sums for subarray problems. Sliding window is $O(1)$ extra space and one pass; prefix sums are $O(n)$ space. That makes the window look strictly better, and for positive-only inputs it is. But the window's correctness rests on monotonicity: extending the window must move the aggregate in one direction. Sums of non-negative numbers are monotonic; sums with negatives are not, and neither is a product that can include zero. My position: if the problem statement does not guarantee non-negative values, use prefix sums with a hash map, and say why. The extra $O(n)$ space is cheap and the alternative is a wrong answer that looks right on the sample input. If the constraints do guarantee non-negativity, take the window and state the dependency out loud, because that sentence is the whole signal.

Difference arrays versus a segment tree or Fenwick tree. A difference array handles range updates in $O(1)$ each but only answers queries after an $O(n)$ finalisation, so it is the right structure when all updates come before all queries. Interleave them and it degenerates. A Fenwick tree handles both in $O(\log n)$ and is the correct answer when updates and queries are mixed. Reach for the difference array first because it is ten lines and the batch pattern is common; name the Fenwick tree as the escalation before the interviewer does.

Follow-up Q&A

What is the actual complexity of the variable-size sliding window, and why is the inner while not a problem? $O(n)$. The inner loop advances lo, lo never decreases, and it is bounded by $n$, so across the whole run the inner loop body executes at most $n$ times total. This is an amortised argument and stating it correctly is the point: a candidate who says "there's a nested loop so it's $O(n^2)$" has not understood the pattern, and one who says "it's $O(n)$" without the monotonicity argument has memorised it.

group_anagrams sorts the letters of each word. Can you do better? Yes, and it matters when words are long. Sorting a length-$k$ word is $O(k \log k)$; a fixed 26-slot count vector is $O(k)$, giving $O(nk)$ overall instead of $O(nk \log k)$. The code uses a sorted Counter because it generalises past a 26-letter alphabet, which matters for a multilingual corpus where the alphabet is Unicode-sized and a fixed array is not an option. Say the tradeoff rather than asserting one is better.

How do you extend prefix sums to two dimensions? prefix[i][j] is the sum of the rectangle from the origin to $(i,j)$. Build it with inclusion-exclusion, prefix[i][j] = grid[i][j] + prefix[i-1][j] + prefix[i][j-1] - prefix[i-1][j-1], and query the same way with four terms. The subtraction of the doubly counted corner is the whole idea, and it is the integral image above.

Prefix sums with floating point over a long array: any issue? Yes, and it is a real one. Error accumulates along the running sum, so a range sum near the end of a long array is a difference of two large, similarly sized numbers, which is catastrophic cancellation. Depending on the data this can lose most of your significant digits. Mitigations: use Kahan summation when building, keep the accumulator at higher precision than the data (float64 for float32 input), or use a Fenwick tree, whose partial sums are over $O(\log n)$ elements rather than $O(n)$ and so accumulate far less error. Integers do not have this problem, which is why the pattern is usually taught with them and why the issue surprises people in production.

When would you use a difference array in real code, not a puzzle? Any "apply many overlapping interval effects, then read the result once" shape. Booking and capacity systems (how many resources are in use at each minute given a list of reservations), scheduling, and gain or volume envelopes over a timeline. It is the same computation as the sweep line over intervals, which is why those two patterns keep appearing in the same problems.

The interviewer says the array does not fit in memory. Now what? Prefix sums and difference arrays both stream: they need one pass and $O(1)$ state per element beyond the output. The problem is the output array, not the algorithm. If range queries must be served over a dataset larger than memory, the answer is a persisted, blocked structure: store prefix sums per block, keep block boundaries in memory, and read the one block that contains each endpoint. That is roughly how columnar formats accelerate aggregate queries with per-block min, max and sum statistics in the footer.

Common misconceptions

"Hash map lookups are $O(1)$, so the whole thing is guaranteed $O(n)$." Average case. Worst case is $O(n)$ per lookup under collisions, and adversarial key sets can force it, which is why languages randomise hash seeds. It has been exploited: the 2011 hash collision denial of service affected PHP, Python, Ruby, Java and others by posting form fields chosen to collide. For an interview, say "expected $O(n)$" and you are right; the follow-up about adversarial input is a gift.

"Sliding window works for any subarray problem." Only when the aggregate is monotonic in the window's extent, as above. Negative numbers, or a "product less than K" problem where an element is zero, break it.

"Two pointers requires a sorted array." The most common form does, but not all. The fast-and-slow pointer pattern (cycle detection in a linked list, finding a midpoint) uses two pointers moving at different speeds over an unsorted structure. What two pointers actually requires is a decision rule that lets one comparison eliminate a region, and sortedness is the most common source of one, not the only one.

"Prefix sums are just an optimisation." They change what is expressible. range_sum at $O(1)$ is what makes an $O(n^2)$ algorithm out of an $O(n^3)$ one in problems like maximum submatrix sum, where the range query sits inside two loops. That is a complexity class change, not a constant factor.

Interview delivery note

The sentence that earns the most per word here is the one that names the invariant before you write the loop: "The window between lo and hi always contains distinct characters; hi advances every step and lo advances only to restore that, so each index moves at most twice and this is $O(n)$." State the invariant, state why it gives the bound, then write. Interviewers who have seen fifty candidates code this pattern are listening for whether you understand it or have memorised its shape, and the invariant is what distinguishes those.

The senior-to-staff separator: naming the input that would break your approach, and saying what you would switch to. "I am using a sliding window, which assumes the values are non-negative so extending the window never lowers the sum. If negatives are possible, this is wrong and I would switch to prefix sums with a hash map of counts, same $O(n)$ but $O(n)$ space." A senior candidate produces working code. A staff candidate produces working code plus the boundary of its correctness, and that boundary is what a team actually needs from whoever writes the shared utility.

Further reading

• Paul Viola and Michael Jones. "Rapid Object Detection using a Boosted Cascade of Simple Features." CVPR 2001. Section 2 is the integral image, which is a 2D prefix sum.
• Cormen, Leiserson, Rivest and Stein. Introduction to Algorithms, 4th ed. Chapter 11 (Hash Tables), for the expected-versus-worst-case bound stated precisely.
• Graham Cormode and S. Muthukrishnan. "An Improved Data Stream Summary: The Count-Min Sketch and its Applications." Journal of Algorithms, 2005.
• cv::integral in the OpenCV docs, for the production form of the 2D prefix sum.

Binary search, search on the answer, and monotonic stacks

What it is

Two patterns joined by one idea: discard candidates in bulk using an ordering invariant.

Binary search halves a range each step because the range is ordered, giving $O(\log n)$. The version worth memorising is not "find this value" but "find the first position where a predicate becomes true", because that one function also gives you lower_bound, upper_bound, insertion point, count of a value, and every "smallest x such that" problem. Search on the answer applies the same machinery when the input is not sorted at all: what is monotonic is a feasibility predicate over the space of possible answers, so you binary search the answers and use a feasibility check where a comparison would normally go.

A monotonic stack keeps a stack whose values are sorted (increasing or decreasing from bottom to top) and pops anything that violates the order as new elements arrive. The popped elements are ones that can never win again, and the moment they are popped is exactly when their answer becomes known. It answers "for each element, what is the nearest element to its left or right that is larger or smaller" in $O(n)$.

Don't be confused: "the array must be sorted" is not the precondition for binary search. The precondition is that the predicate you are searching on is monotonic: once it becomes true it stays true. A sorted array is the most common way to get one, which is why the two get conflated, but a rotated sorted array is not sorted and is still binary searchable, and the answer space in min_capacity below is not an array at all. Say "monotonic predicate", not "sorted array", and you will spot the search-on-the-answer problems that everyone else brute forces.

Don't be confused: a monotonic stack is not a sorted stack you maintain for its own sake. The values in it are incidentally ordered; the point is that the stack holds exactly the elements whose answer is still unknown, and the ordering is what proves a new element resolves a contiguous block of them. If you cannot say which pending question each stack entry represents, you are pattern matching rather than reasoning, and the variants will catch you.

The problem it solves

Binary search's practical problem is not "search a sorted array"; a hash map does that faster. It is the family of questions a hash map cannot answer: where does this value belong, how many are less than this, what is the nearest value to this. Those are range and order questions, and they are why every database index is a B-tree rather than a hash table.

Search on the answer solves a class that looks intractable: "what is the minimum capacity that gets this done in $k$ days?" The direct approach requires inverting a complicated process. The binary search approach only requires simulating it, which is easy, and then searching. Turning an optimisation problem into a decision problem plus a search is one of the highest leverage moves in the whole pattern set.

The monotonic stack solves the $O(n^2)$ "for each element, scan for the nearest bigger one" shape. It comes up disguised: largest rectangle in a histogram, trapping rain water, stock span, and the sliding window maximum, which is the same idea with a deque.

Mechanics

"""Binary search, "search on the answer", and monotonic stacks.

Runnable: `python3 search_and_stacks.py`. Both families discard candidates using
an ordering invariant. Binary search discards half the range because the range is
sorted; a monotonic stack discards candidates that can never win again.
"""

import bisect


# --- Binary search: the boundary form, not the equality form -----------------
# Write ONE binary search and derive the rest. The version that returns "the
# first index where pred is True" handles find, lower_bound, upper_bound and
# insertion point; the version that compares for equality handles only one of
# them and has three places to put an off-by-one.
def first_true(lo, hi, pred):
    """Smallest x in [lo, hi) with pred(x) True, or hi if there is none.

    Requires pred to be monotonic: False...False True...True. That precondition
    is the whole algorithm; everything else is bookkeeping.
    """
    while lo < hi:
        mid = lo + (hi - lo) // 2      # not (lo+hi)//2: that overflows in Java/C++
        if pred(mid):
            hi = mid                   # mid might be the answer, so keep it
        else:
            lo = mid + 1               # mid is not, so discard it
    return lo


def lower_bound(arr, target):
    """First index with arr[i] >= target."""
    return first_true(0, len(arr), lambda i: arr[i] >= target)


def upper_bound(arr, target):
    """First index with arr[i] > target. count(target) = upper - lower."""
    return first_true(0, len(arr), lambda i: arr[i] > target)


def search_rotated(arr, target):
    """Rotated sorted array. Sortedness is broken globally but at least one half
    of any split is still sorted, and that is enough to decide which half to
    keep."""
    lo, hi = 0, len(arr) - 1
    while lo <= hi:
        mid = lo + (hi - lo) // 2
        if arr[mid] == target:
            return mid
        if arr[lo] <= arr[mid]:                      # left half is sorted
            if arr[lo] <= target < arr[mid]:
                hi = mid - 1
            else:
                lo = mid + 1
        else:                                        # right half is sorted
            if arr[mid] < target <= arr[hi]:
                lo = mid + 1
            else:
                hi = mid - 1
    return -1


# --- Search on the answer ----------------------------------------------------
# The input is not sorted and may not even be a list. What is monotonic is the
# PREDICATE over the answer space: if a capacity of 20 works, so does 21. So you
# binary search the answer, using a feasibility check as the comparison.
def min_capacity(weights, days):
    """Least ship capacity that moves all packages within `days` days, keeping
    order. Answer space is [max(weights), sum(weights)]."""

    def feasible(cap):
        used, load = 1, 0
        for w in weights:
            if load + w > cap:
                used += 1
                load = 0
            load += w
        return used <= days

    return first_true(max(weights), sum(weights) + 1, feasible)


def sqrt_floor(n):
    """Integer square root, to show the answer space need not come from a list."""
    return first_true(0, n + 1, lambda x: x * x > n) - 1


# --- Monotonic stack ---------------------------------------------------------
def next_greater(nums):
    """For each element, the next strictly greater element to its right, or -1.

    Invariant: the stack holds indices whose answers are still unknown, and
    their values are strictly decreasing from bottom to top. When a new value
    arrives it resolves every stacked index it beats. Each index is pushed once
    and popped once, so O(n) despite the nested loop.
    """
    out = [-1] * len(nums)
    stack = []                                   # indices, values decreasing
    for i, n in enumerate(nums):
        while stack and nums[stack[-1]] < n:
            out[stack.pop()] = n
        stack.append(i)
    return out


def largest_rectangle(heights):
    """Largest rectangle in a histogram. The classic payoff for the pattern.

    For each bar, the widest rectangle of that bar's height runs from the first
    bar to its left that is shorter, to the first bar to its right that is
    shorter. A monotonic increasing stack finds both boundaries in one pass:
    when bar i pops bar j, i IS j's right boundary and the new stack top is j's
    left boundary.
    """
    stack = []                                   # indices, heights increasing
    best = 0
    best_at = None
    for i, h in enumerate(heights + [0]):        # sentinel 0 flushes the stack
        while stack and heights[stack[-1]] >= h:
            height = heights[stack.pop()]
            left = stack[-1] + 1 if stack else 0
            width = i - left
            if height * width > best:
                best = height * width
                best_at = (left, i, height)
        stack.append(i)
    return best, best_at


def daily_temperatures(temps):
    """How many days until a warmer day. Same stack, but store the distance
    rather than the value, which is what most variants actually ask for."""
    out = [0] * len(temps)
    stack = []
    for i, t in enumerate(temps):
        while stack and temps[stack[-1]] < t:
            j = stack.pop()
            out[j] = i - j
        stack.append(i)
    return out


if __name__ == "__main__":
    arr = [1, 3, 3, 3, 5, 8, 8, 13]
    print("array               :", arr)
    print("lower_bound(3)      :", lower_bound(arr, 3))
    print("upper_bound(3)      :", upper_bound(arr, 3))
    print("count of 3          :", upper_bound(arr, 3) - lower_bound(arr, 3))
    print("lower_bound(4)      :", lower_bound(arr, 4), "(insertion point, 4 is absent)")
    print("agrees with bisect  :", (bisect.bisect_left(arr, 3), bisect.bisect_right(arr, 3)))

    rot = [12, 15, 18, 2, 5, 6, 8]
    print()
    print("rotated             :", rot)
    print("search_rotated(5)   :", search_rotated(rot, 5))
    print("search_rotated(12)  :", search_rotated(rot, 12))
    print("search_rotated(99)  :", search_rotated(rot, 99))

    w = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    print()
    print("weights             :", w, "sum =", sum(w))
    for d in (5, 3, 1):
        print(f"min_capacity(days={d:2}) :", min_capacity(w, d))
    print("sqrt_floor(2000)    :", sqrt_floor(2000), "since 44^2 =", 44 * 44, "and 45^2 =", 45 * 45)

    print()
    nums = [2, 1, 2, 4, 3]
    print("nums                :", nums)
    print("next_greater        :", next_greater(nums))
    temps = [73, 74, 75, 71, 69, 72, 76, 73]
    print("temperatures        :", temps)
    print("days until warmer   :", daily_temperatures(temps))
    hist = [2, 1, 5, 6, 2, 3]
    area, at = largest_rectangle(hist)
    print("histogram           :", hist)
    print("largest rectangle   :", area, "spanning [%d,%d) at height %d" % at)

Four details that decide whether your implementation is right.

mid = lo + (hi - lo) // 2, not (lo + hi) // 2. In Python they are equivalent because integers are arbitrary precision. In Java, C++ or Go they are not: lo + hi overflows for large arrays, and this exact bug sat in java.util.Arrays.binarySearch in the JDK for nine years before Joshua Bloch wrote it up in 2006. Writing the safe form in Python and saying why is a cheap, genuine signal.

The loop is while lo < hi with a half-open range, and the two branches are asymmetric. hi = mid keeps mid as a candidate, because pred(mid) was true and mid may be the first such index. lo = mid + 1 discards mid, because pred(mid) was false so mid definitively is not the answer. That asymmetry is what makes the loop terminate and be correct; a symmetric hi = mid - 1 alongside hi = mid is the classic infinite loop.

first_true returns hi when nothing satisfies the predicate, which is why lower_bound on an absent value returns the insertion point rather than -1. That is a feature, and it is why one function covers so many cases.

The sentinel in largest_rectangle. The loop iterates heights + [0], appending a zero-height bar. Without it, any bars still on the stack when the input ends are never resolved, and the answer is wrong whenever the tallest rectangle touches the right edge. The sentinel is not a hack; it is the standard way to say "the boundary condition is the same as a very short bar".

Worked example

array               : [1, 3, 3, 3, 5, 8, 8, 13]
lower_bound(3)      : 1
upper_bound(3)      : 4
count of 3          : 3
lower_bound(4)      : 4 (insertion point, 4 is absent)
agrees with bisect  : (1, 4)

rotated             : [12, 15, 18, 2, 5, 6, 8]
search_rotated(5)   : 4
search_rotated(12)  : 0
search_rotated(99)  : -1

weights             : [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] sum = 55
min_capacity(days= 5) : 15
min_capacity(days= 3) : 21
min_capacity(days= 1) : 55
sqrt_floor(2000)    : 44 since 44^2 = 1936 and 45^2 = 2025

nums                : [2, 1, 2, 4, 3]
next_greater        : [4, 2, 4, -1, -1]
temperatures        : [73, 74, 75, 71, 69, 72, 76, 73]
days until warmer   : [1, 1, 4, 2, 1, 1, 0, 0]
histogram           : [2, 1, 5, 6, 2, 3]
largest rectangle   : 10 spanning [2,4) at height 5

The counting trick. upper_bound(3) - lower_bound(3) = 4 - 1 = 3, and there are indeed three 3s. This is how you count occurrences in a sorted array in $O(\log n)$ without a second data structure, and it falls out of having written the boundary form rather than the equality form. The bisect line confirms the implementation matches Python's standard library exactly, which is the cheapest possible correctness test and worth writing in an interview.

Read min_capacity as the shape of search-on-the-answer. The answer space is $[\max(w), \sum w] = [10, 55]$. Its lower end is forced (a capacity below the heaviest package can never ship it) and its upper end is trivially feasible (one day, everything). Feasibility is monotonic: if capacity 15 finishes in 5 days, 16 certainly does too. So binary search over the integers between 10 and 55, not over the array. With 5 days the answer is 15; with 3 days, 21; with 1 day, 55, which is the total, as it must be. Note the predicate simulates greedily and the greedy simulation is provably optimal here because order is fixed, so there is no choice to make. That justification is the part candidates skip and interviewers wait for.

Trace the histogram. Bars [2, 1, 5, 6, 2, 3], answer 10, spanning indices [2,4) at height 5. That is bars 5 and 6, two wide at height 5, giving 10. The alternatives are worth checking by hand: bar 6 alone is 6; height 2 across the whole array is $2 \times 6 = 12$, except bar 1 has height 1 so that rectangle does not exist; height 1 across all six is 6. Ten is right. When bar 2 at index 4 arrives, it pops index 3 (height 6, width 1, area 6), then pops index 2 (height 5, and now the stack top is index 1, so left = 2 and width = 4 - 2 = 2, area 10). The popping element supplies the right boundary and the new stack top supplies the left, which is the sentence to say out loud.

daily_temperatures shows why storing the index beats storing the value. The answer at index 2 is 4, meaning the 75-degree day waits four days for the 76. You can only produce a distance if the stack held indices, so push indices by default and read values through them.

Production evidence

git bisect is search on the answer. The commit history is the answer space, the predicate is "is the bug present at this commit", and the predicate is assumed monotonic: the bug was introduced once and persists. That assumption is exactly the precondition discussed above, and when it fails (a flaky bug, or a fix and a re-break) git bisect returns a wrong commit, which is the same failure mode as binary searching a non-monotonic predicate. It finds the culprit among 10,000 commits in about 14 builds.

Kafka's offset index. Kafka stores a sparse index mapping message offsets to physical file positions, and a consumer seeking an offset binary searches that index to find the nearest preceding entry, then scans forward within the segment. Sparse plus binary search plus a short linear scan is the standard shape, and it is why the index stays small enough to memory-map.

LSM-tree block indexes. LevelDB and RocksDB SSTables are sorted files divided into blocks, with a per-file index of block boundaries. A read binary searches the index to find the block, then binary searches or scans within the decompressed block. Same two-level structure, same reason.

Python's bisect. The standard library ships bisect_left and bisect_right, which are lower_bound and upper_bound under different names, and the docs explicitly document the "sorted list of records, search on a key" use. Java's Collections.binarySearch and C++'s std::lower_bound are the same API in different clothes.

Monotonic deques for running extrema. The $O(n)$ sliding window maximum, which is the monotonic stack turned into a deque so it can also drop elements leaving the window on the left, is the standard algorithm for a running max or min filter, including 1D morphological dilation and erosion in image processing. The naive version is $O(nk)$, and for a structuring element of any real size that difference is the difference between usable and not.

The debate

Should you ever write the equality-form binary search? It is shorter for the single case "does this exact value exist", and if the array has no duplicates and you need nothing else, it is fine. My position: write first_true and derive everything, every time. The reason is not elegance, it is that binary search is famously easy to get subtly wrong (Jon Bentley reported that around 90% of professional programmers failed to write a correct one given hours), and having exactly one loop whose invariant you have internalised beats having four variants you re-derive under pressure. The cost is one lambda.

When is search on the answer the wrong tool? When the predicate is not monotonic, and this is the failure that actually happens. If "capacity 20 works" does not guarantee "capacity 21 works", the search silently returns a wrong answer with no crash and no warning. Before using it, state the monotonicity argument out loud. The second case: when evaluating the predicate is expensive and the answer space is small. Binary search over 8 candidates costs 3 predicate evaluations against 8 for a linear scan, and if each evaluation is a 10-minute build, the constant factors and the code risk may favour the scan. The third: when you need all feasible answers rather than the boundary.

Monotonic stack versus a heap for "nearest greater" style problems. A heap gives you the global maximum, not the nearest one, so for nearest-element questions the heap is simply the wrong structure and reaching for it is a tell. Where they genuinely compete is sliding window maximum: a heap with lazy deletion is $O(n \log k)$ and is easier to write correctly, while the monotonic deque is $O(n)$ and is fiddlier. For $k$ up to a few thousand I would write the heap version and say I know the deque is $O(n)$, because the log factor is small and the deque's edge cases (equal values, expiry by index) are where bugs live. For a hot path over large windows, take the deque.

Follow-up Q&A

Prove the monotonic stack is $O(n)$ when it contains a nested while loop. Every index is pushed exactly once, so at most $n$ pushes happen across the entire run. Every iteration of the inner while performs one pop, and you cannot pop more than you push, so the inner loop body executes at most $n$ times in total across all iterations of the outer loop. Total work is $O(n)$. This is an amortised argument, not a per-iteration one, and stating it that way is the point of the question.

How do you handle duplicate values in a monotonic stack? By deciding whether the comparison is strict, and the right choice depends on the question. In next_greater the condition is <, so equal values do not pop each other and "next greater" means strictly greater. In largest_rectangle the condition is >=, so equal heights do pop. That looks like it produces a wrong (too narrow) rectangle for the popped bar, and it does, but the last bar of a run of equal heights computes the full width, so the maximum is still correct. Being able to explain why the seemingly wrong intermediate value does not affect the answer is a strong signal; if you are unsure in the room, use >= and verify on a [2,2,2] input.

Binary search on a rotated array with duplicates: what changes? The worst case degrades to $O(n)$ and there is no way around it. The algorithm decides which half is sorted by comparing arr[lo] to arr[mid]; with duplicates, arr[lo] == arr[mid] == arr[hi] tells you nothing about either half, as in [2,2,2,0,2,2]. The standard fix is to shrink the range by one from each end in that case, which is correct but is linear when the array is mostly one value. Say the bound honestly rather than claiming $O(\log n)$.

Your min_capacity search space starts at max(weights). Why not 0? Because a capacity below the heaviest single package makes the problem infeasible at any number of days, so the predicate is false throughout that region and including it is harmless but wasteful. It is not merely an optimisation though: if the feasibility function had been written to loop forever or divide by zero on an impossible capacity, starting at 0 would be a crash. Tying the search bounds to the problem's own constraints is what keeps the predicate total.

How would you binary search over floating point? Do not iterate to exact equality; it may never terminate. Either fix an iteration count (100 iterations of bisection on a float64 exhausts its precision, so a for _ in range(100) loop is both simple and provably converged) or loop while hi - lo > eps with an epsilon chosen from the problem's required precision. Stating the fixed-iteration version shows you have hit this before.

Give a real system where you would use search on the answer. Capacity and cost tuning. "What is the smallest instance count that keeps p99 under 200 ms?" is monotonic in instance count over the useful range, the predicate is a load test, and the search finds the boundary in $\log$ many tests instead of a linear sweep. The caveat is the same one as always: verify monotonicity, because with certain autoscaler and cache-warming behaviours it does not hold, and then you are bisecting noise.

Common misconceptions

"Binary search needs a sorted array." It needs a monotonic predicate. The rotated-array and search-on-the-answer cases in this file are both counterexamples, and both are common interview problems specifically because they test whether you learned the rule or the example.

"$O(\log n)$ means it is always the fastest way to search." For small $n$, a linear scan wins, because it is branch-predictable and cache-friendly while binary search jumps around memory. Real implementations, including several standard libraries' sort routines, switch to linear or insertion-based approaches under a threshold of a few dozen elements. The asymptotics are about growth, not about which is faster at $n = 16$.

"The monotonic stack stores the answers." It stores the questions: the elements still waiting for an answer. The answers are written into the output array at pop time. Getting this backwards is why people cannot adapt the pattern to a new variant.

"Trapping rain water needs a different algorithm." It is the same monotonic stack, or the same two pointers, depending on which formulation you pick. Recognising that a problem you have not seen is a re-skin of one you have is most of what the pattern list is for.

Interview delivery note

For any binary search, say the invariant before the code: "I am searching for the first index where the predicate is true. The predicate is monotonic because [reason]. lo is always a position where it might be true or beyond; hi is always a position I know satisfies it or the end." Then write first_true. This takes fifteen seconds and removes the single most common source of visible flailing on a whiteboard.

The senior-to-staff separator is recognising search-on-the-answer in a problem that does not look like a search at all. A senior candidate who is given "minimum capacity to ship in $k$ days" often starts constructing a greedy or a DP and gets tangled. The staff move is to stop and say: "I do not know how to compute the answer directly, but I can check an answer easily, and checking is monotonic, so I will binary search the answer space and spend my effort on the checker." Converting an optimisation problem into a decision problem plus a search is a transferable engineering instinct, not a trick, and interviewers who set these problems are looking for exactly that sentence.

Further reading

• Joshua Bloch. "Extra, Extra: Nearly All Binary Searches and Mergesorts are Broken." Google Research Blog, 2006. The overflow bug in the JDK, from the person who fixed it.
• Jon Bentley. Programming Pearls, 2nd ed. Column 4, on writing and proving binary search correct.
• Python bisect documentation, including the "searching sorted lists" recipes that build find_lt, find_ge and friends on top of the two primitives.
• Kafka design documentation, for the sparse offset index and the binary-search-then-scan read path.

Graph traversal, topological sort and union-find

What it is

Three patterns that share a data structure and split on a single question: do you need the path, the order, or only the grouping?

BFS explores a graph in rings of increasing distance from a source, so the first time it reaches a node, it has reached it by a shortest path. DFS follows one branch to exhaustion before backtracking, which makes it the tool for questions about structure (cycles, articulation points, strongly connected components) rather than distance. Topological sort orders the nodes of a directed acyclic graph so every edge points forward, which is the answer to "what order can I do these tasks in". Union-find, also called disjoint set union or DSU, maintains a partition of elements into disjoint groups under two operations: merge two groups, and ask whether two elements are in the same group.

Don't be confused: union-find is not a graph traversal. Union-find never stores edges and cannot tell you a path. It answers exactly one question, "are these two in the same component", and it answers it in near constant time while edges are still arriving. BFS and DFS can also compute connected components, but they need the whole graph in memory first and they cost $O(V + E)$ per query unless you precompute and cache. The rule that decides it: if edges arrive incrementally and you are asked about connectivity, use union-find; if you need the actual path, you cannot.

The other confusion worth heading off: union-find is not a tree you should read as a tree. The parent pointers form a forest, but path compression rewrites that forest constantly, and the shape after a sequence of operations tells you nothing meaningful. Only the root identity matters.

The problem it solves

Take Kruskal's minimum spanning tree algorithm. You sort the edges by weight and walk them cheapest first, taking an edge only if it joins two pieces that are not already joined. The whole algorithm hinges on that test. Do it with BFS and each test costs $O(V + E)$, which over $E$ edges gives $O(E \cdot (V+E))$, quadratic or worse. Union-find turns each test into effectively constant time and the sort dominates, giving $O(E \log E)$.

The same shape recurs whenever a relation is an equivalence relation: reflexive, symmetric and transitive. "Is in the same network partition as", "is the same user account as" during identity resolution, "is the same type variable as" during type inference. Every one of those is union-find wearing a different hat.

Topological sort solves a different starvation: given a set of tasks with prerequisites, produce an order that never violates one, and prove that no such order exists when the prerequisites are circular. Without it, you either run tasks in a hand maintained order that silently rots, or you deadlock.

Mechanics

The full runnable file:

"""Graph traversal, topological sort and union-find, with the invariants stated.

Runnable: `python3 graphs_and_union_find.py`. Every number printed here appears
in the chapter, so the chapter cannot drift from the code.
"""

from collections import deque


# --- BFS: shortest path in an unweighted graph -------------------------------
# The invariant that makes BFS correct: the queue always holds nodes in
# non-decreasing distance order, so the first time you reach a node is via a
# shortest path. That is why you mark visited on ENQUEUE, not on dequeue: marking
# on dequeue lets a node enter the queue several times and the bound degrades.
def bfs_shortest(graph, start, goal):
    if start == goal:
        return [start]
    parent = {start: None}
    q = deque([start])
    while q:
        node = q.popleft()
        for nxt in graph[node]:
            if nxt in parent:            # already reached, and by a <= distance
                continue
            parent[nxt] = node
            if nxt == goal:
                path = [goal]
                while parent[path[-1]] is not None:
                    path.append(parent[path[-1]])
                return path[::-1]
            q.append(nxt)
    return None


# --- DFS: cycle detection needs three colours, not two -----------------------
# WHITE unvisited, GREY on the current recursion stack, BLACK finished. A GREY
# neighbour is a back edge and therefore a cycle. Using only "visited" finds
# cross edges too and reports cycles that are not there.
def has_cycle(graph):
    WHITE, GREY, BLACK = 0, 1, 2
    colour = {n: WHITE for n in graph}

    def walk(n):
        colour[n] = GREY
        for nxt in graph[n]:
            if colour[nxt] == GREY:      # back edge to the current stack
                return True
            if colour[nxt] == WHITE and walk(nxt):
                return True
        colour[n] = BLACK
        return False

    return any(colour[n] == WHITE and walk(n) for n in graph)


# --- Topological sort (Kahn) -------------------------------------------------
# Kahn's version is preferred in an interview because it detects the cycle for
# free: if the output is shorter than the node count, the remainder is a cycle.
def topo_sort(graph):
    indeg = {n: 0 for n in graph}
    for n in graph:
        for m in graph[n]:
            indeg[m] += 1
    q = deque([n for n in graph if indeg[n] == 0])
    order = []
    while q:
        n = q.popleft()
        order.append(n)
        for m in graph[n]:
            indeg[m] -= 1
            if indeg[m] == 0:
                q.append(m)
    if len(order) != len(graph):
        cyclic = sorted(n for n in graph if indeg[n] > 0)
        raise ValueError(f"cycle among {cyclic}")
    return order


# --- Union-find (disjoint set union) -----------------------------------------
class UnionFind:
    """Union by size + path compression.

    The two optimisations do different jobs and you need both. Union by size
    keeps the tree shallow by hanging the smaller tree off the larger. Path
    compression flattens the path you just walked. Together the amortised cost
    per operation is the inverse Ackermann function, which is below 5 for any n
    you will ever see, so it is constant in practice.
    """

    def __init__(self, n):
        self.parent = list(range(n))
        self.size = [1] * n
        self.components = n

    def find(self, x):
        # Iterative, because the recursive version blows the stack on a long
        # chain, which is exactly the input an interviewer reaches for.
        root = x
        while self.parent[root] != root:
            root = self.parent[root]
        while self.parent[x] != root:                # path compression
            self.parent[x], x = root, self.parent[x]
        return root

    def union(self, a, b):
        ra, rb = self.find(a), self.find(b)
        if ra == rb:
            return False                              # already together
        if self.size[ra] < self.size[rb]:             # union by size
            ra, rb = rb, ra
        self.parent[rb] = ra
        self.size[ra] += self.size[rb]
        self.components -= 1
        return True

    def connected(self, a, b):
        return self.find(a) == self.find(b)


def kruskal(n, edges):
    """Minimum spanning tree. The reason union-find exists in most interviews:
    sort the edges, take one if it joins two different components."""
    total, chosen, uf = 0, [], UnionFind(n)
    for w, a, b in sorted(edges):
        if uf.union(a, b):
            total += w
            chosen.append((a, b, w))
    return total, chosen, uf.components


if __name__ == "__main__":
    g = {"a": ["b", "c"], "b": ["d"], "c": ["d", "e"], "d": ["f"], "e": ["f"], "f": []}
    print("graph:", {k: v for k, v in g.items()})
    print("bfs a->f      :", bfs_shortest(g, "a", "f"))
    print("has_cycle     :", has_cycle(g))
    print("topo order    :", topo_sort(g))

    cyc = {"x": ["y"], "y": ["z"], "z": ["x"]}
    print("cyclic graph  :", cyc)
    print("has_cycle     :", has_cycle(cyc))
    try:
        topo_sort(cyc)
    except ValueError as e:
        print("topo raises   :", e)

    print()
    uf = UnionFind(10)
    for a, b in [(0, 1), (1, 2), (3, 4), (5, 6), (6, 7), (7, 8)]:
        uf.union(a, b)
    print("after unions, components:", uf.components)
    print("connected(0,2):", uf.connected(0, 2))
    print("connected(0,3):", uf.connected(0, 3))
    print("component sizes:", sorted((uf.size[uf.find(i)] for i in range(10)), reverse=True)[:4])

    edges = [(4, 0, 1), (8, 0, 7), (11, 1, 7), (8, 1, 2), (7, 7, 8),
             (1, 6, 7), (6, 8, 6), (2, 2, 8), (2, 6, 5), (4, 2, 5),
             (14, 3, 5), (9, 3, 4), (10, 5, 4), (7, 2, 3)]
    total, chosen, comps = kruskal(9, edges)
    print()
    print("kruskal MST weight:", total)
    print("edges chosen      :", len(chosen), "for 9 nodes ->", comps, "component")

Three details in that code are the ones interviewers probe.

BFS marks visited on enqueue, not on dequeue. The line is if nxt in parent: continue followed immediately by parent[nxt] = node. If you instead mark when you pop, a node with many in-edges enters the queue once per in-edge, and the queue can hold $O(E)$ entries instead of $O(V)$. The result is still correct; the memory bound is not.

Cycle detection by DFS needs three colours, not two. A node is WHITE (untouched), GREY (on the current recursion stack) or BLACK (fully explored). A cycle exists exactly when you find an edge to a GREY node, because GREY means "I am still inside this node's call, so there is a path from it back to here". If you collapse GREY and BLACK into one "visited" flag, the diamond a to b, a to c, b to d, c to d reports a cycle that does not exist, because d is visited when c reaches it. That diamond is in the test data precisely because it is the input that separates the two implementations.

Union-find needs both optimisations, and find should be iterative. Union by size keeps trees shallow by hanging the smaller tree under the larger. Path compression flattens the path you just walked so the next find on any of those nodes is one hop. With both, the amortised cost is $O(\alpha(n))$ where $\alpha$ is the inverse Ackermann function, which is under 5 for any $n$ that fits in the observable universe. With only one of them you get $O(\log n)$, which is fine but is not what the interviewer is listening for. The iterative find matters because a recursive one recurses to depth $n$ on a degenerate chain, and "build a chain of 100,000 nodes" is a normal hostile input.

Worked example

Running the file:

graph: {'a': ['b', 'c'], 'b': ['d'], 'c': ['d', 'e'], 'd': ['f'], 'e': ['f'], 'f': []}
bfs a->f      : ['a', 'b', 'd', 'f']
has_cycle     : False
topo order    : ['a', 'b', 'c', 'd', 'e', 'f']
cyclic graph  : {'x': ['y'], 'y': ['z'], 'z': ['x']}
has_cycle     : True
topo raises   : cycle among ['x', 'y', 'z']

after unions, components: 4
connected(0,2): True
connected(0,3): False
component sizes: [4, 4, 4, 4]

kruskal MST weight: 37
edges chosen      : 8 for 9 nodes -> 1 component

Read the union-find block carefully, because it demonstrates the invariant that gets misstated in interviews. Ten elements start as ten singletons. Six successful unions run, so the component count is $10 - 6 = 4$: the group ${0,1,2}$, the group ${3,4}$, the group ${5,6,7,8}$ and the singleton ${9}$. Every successful union reduces the count by exactly one, and an unsuccessful one leaves it unchanged, which is why union returns a boolean rather than nothing. Kruskal reads that boolean directly.

The component sizes line shows [4, 4, 4, 4], and the reason is worth pausing on: it is size[find(i)] for each of the ten elements, sorted descending and truncated to four. The four largest entries are the four members of the size-4 component, all reporting the same root. It is not four separate components of size 4. self.size is only meaningful at a root, and reading it at a non-root gives a stale value left over from before that node was absorbed. Candidates who keep a size array and forget this ship an off by a lot bug.

The Kruskal run takes the classic 9-node, 14-edge graph from Sedgewick and produces weight 37 using exactly 8 edges, which is $V - 1$ as any spanning tree of a connected 9-node graph must be, ending in 1 component.

Production evidence

Type inference. Hindley-Milner unification, the algorithm under the type checkers of OCaml, Haskell and the inference parts of Rust and TypeScript, maintains equivalence classes of type variables in a union-find structure. When the checker learns that 'a and 'b must be the same type, it unions them; asking "what is this variable's type" is a find to the class representative. The near constant time is what keeps whole program inference tractable.

LLVM. LLVM ships union-find as a first class container in its ADT library, llvm::EquivalenceClasses, and uses it for congruence and equivalence problems across the optimiser rather than for one special case.

Connected component labelling in image processing. The standard two pass algorithm, which is what scipy.ndimage.label and scikit-image implement, assigns provisional labels in a raster scan and uses union-find to record that two provisional labels are actually the same region, then resolves them in the second pass. This is the canonical "edges arrive incrementally" case: you cannot build the region graph first, because discovering the regions is the task.

Topological sort in build and infrastructure tooling. Terraform builds a directed graph of resources from the references between them and walks it in topological order, which is how it parallelises independent resources and why a circular reference is a plan-time error rather than a runtime hang. Build systems in the Make and Bazel lineage do the same over targets, and Airflow rejects a DAG whose tasks form a cycle. In every one of these, the cycle detection is as much the product as the ordering, which is the argument for Kahn's algorithm below.

The debate

Kahn's algorithm or DFS post-order for topological sort? Both are $O(V+E)$ and both are correct. The real tradeoff: DFS post-order is fewer lines and needs no in-degree map, but detecting a cycle requires the three-colour bookkeeping above and recovering which nodes form the cycle takes extra work. Kahn's gets cycle detection for free, because any node left with a positive in-degree when the queue empties is in or downstream of a cycle, and that set is a usable error message. Kahn's is also naturally parallel: everything at in-degree zero can run at once, which is exactly what a build system wants.

My position: default to Kahn's. In interviews and in production the question is almost never "give me an order" alone; it is "give me an order or tell me precisely why you cannot", and Kahn's answers both from the same state. Choose DFS post-order when you are already doing a DFS for another reason, or when the graph is given as a recursive structure you would have to materialise to compute in-degrees. Note the failure mode I coded around: in topo_sort the error names the offending nodes, because "cycle detected" without the node set is an error message that costs somebody an afternoon.

When union-find is the wrong choice. Three cases, and they are all disqualifying rather than merely suboptimal. First, if you need to remove an edge or split a group. Standard union-find has no split; the structure is one-way. The problems that need it (dynamic connectivity with deletions) go to link-cut trees or Euler tour trees, and the honest interview answer is to name the constraint and say the structure changes, not to try to patch a split onto DSU. Second, if you need the path or the distance, not the grouping. Third, if the "same group" relation is not transitive, for example a similarity threshold where A is near B and B is near C but A is far from C. Union-find will happily chain those into one giant component, which is the single most common way it is misapplied in production. In entity resolution that failure has a name, over-merging, and it collapses distinct customers into one record.

Follow-up Q&A

Why is the complexity called "effectively constant" rather than constant? Because it is $O(\alpha(n))$ amortised, not $O(1)$ worst case. A single find immediately after a long chain is built can cost $O(\log n)$; path compression pays that back by making every subsequent find on those nodes cheap. Amortised is the right word and using it correctly is a signal. The bound is Tarjan's, and it is tight: no structure in this model does better.

Can you get the same bound without union by size? Path compression alone gives $O(\log n)$ amortised, and union by size alone gives $O(\log n)$ worst case. You need both for the inverse Ackermann bound. Union by rank (tree height) instead of size gives the same asymptotic result; size is easier to reason about and gives you component sizes for free, which problems frequently ask for, so I use size.

How do you get the component sizes out? Read size[find(x)] and only at a root, as above. If you want a histogram of all component sizes, iterate every element, find its root, and count roots in a dictionary; that is $O(n \alpha(n))$ and is the only correct way, because the size entries at non-roots are stale.

How would you handle a graph too large for memory? Union-find over a disk or distributed set is genuinely hard, because path compression is a random write. The practical answer is to reframe: partition the edges, run union-find per partition, then merge the partition results by unioning their boundary elements, iterating until stable. That is essentially how large scale connected components jobs work. For a single machine, note that the parent array is just two integer arrays, so 100 million elements is about 800 MB with 32-bit ints, which is often enough to make the question moot.

Your BFS returns one shortest path. What if there are several and I want all of them? Change parent from a single value to a list, and append rather than skip when you reach a node at the same distance you already reached it at, which requires tracking distance explicitly instead of inferring it. Then enumerate paths backwards from the goal. Say the cost out loud: the number of shortest paths can be exponential in $V$, so "all of them" is only reasonable if the caller consumes them lazily or you are counting rather than listing. Counting is a small DP over the BFS layers and stays linear.

Give me a problem where union-find is the trick and it is not obvious. "Given a list of accounts each with a name and a set of emails, merge accounts that share any email." The naive reading is a grouping problem; the trap is that merging is transitive through a chain of shared emails. Map each email to an element, union all emails within an account, then group emails by root. Also: processing edge removals in reverse, since a problem that asks about connectivity as edges are deleted can be run backwards, turning deletions into insertions, which union-find handles.

Common misconceptions

"Path compression makes the trees permanently flat." It flattens only the path just walked. A subsequent union can hang a tree under that root and add depth again. The bound is amortised over the sequence, not a structural guarantee at any instant.

"BFS finds shortest paths in any graph." Only in unweighted graphs, or equivalently graphs where every edge has the same weight. Add weights and you need Dijkstra; add negative weights and you need Bellman-Ford. Saying "BFS gives shortest path" without the unweighted qualifier is one of the fastest ways to lose a point on a question you knew.

"A topological order is unique." Almost never. The example above admits several valid orders; ['a','b','c','d','e','f'] is the one Kahn's produces given this insertion order. If a problem's expected output is a specific order, it has additional tie-breaking rules (usually lexicographic, which you get by swapping the queue for a heap), and you should ask rather than assume.

"I'll use DFS recursion; the graph is small." The graph in the test is small. The graph in the follow-up is 100,000 nodes in a line, and Python's default recursion limit is 1,000. Write graph DFS iteratively, or say out loud that you are choosing recursion and would convert it for production.

Interview delivery note

Say this before writing anything: "Edges arrive incrementally and I only need connectivity, not the path, so this is union-find rather than a traversal. Union by size plus path compression, effectively constant per operation." That single sentence names the structure, justifies it against the alternative, and states the complexity, which is the three things the rubric is looking for.

The senior-to-staff separator on this topic is not knowing the algorithm; everyone at this level knows it. It is naming the constraint that would break your choice before being asked. A senior candidate writes a correct union-find. A staff candidate writes the same code and adds, unprompted, "note this has no split, so if edges can be removed later this structure is wrong and we would need Euler tour trees, and separately, if grouping comes from a similarity threshold rather than a true equivalence relation, transitivity will over-merge." That is the difference between someone who can implement a pattern and someone you trust to choose one.

Further reading

• Robert Tarjan. "Efficiency of a Good But Not Linear Set Union Algorithm." Journal of the ACM, 1975. The inverse Ackermann bound, from the source.
• A. B. Kahn. "Topological sorting of large networks." Communications of the ACM, 1962. Three pages, and the algorithm is on the first one.
• Cormen, Leiserson, Rivest and Stein. Introduction to Algorithms, 4th ed. Chapter 19 (Data Structures for Disjoint Sets) and Chapter 20 (Elementary Graph Algorithms).
• llvm::EquivalenceClasses, a production union-find with the API decisions visible.

Heaps, top-K, intervals and the sweep line

What it is

Two patterns that belong on one page because in several problems they are the same algorithm seen from two angles.

A heap is a partially ordered tree that gives you the minimum (or maximum) in $O(1)$ and insert or extract in $O(\log n)$, and gives you nothing else. It cannot search, it cannot tell you the second smallest without extracting the first, and its in-memory order is not sorted. Top-K is the pattern that uses one: keep a bounded heap of size $k$ and evict, so the cost is $O(n \log k)$ and the memory is $O(k)$ rather than $O(n)$.

Interval problems (merge overlapping ranges, insert a range, count overlaps) reduce to sorting by one endpoint and making a single pass. The sweep line is the general version: convert each interval into a start event and an end event, sort all events by time, and walk them while maintaining a running "active set". The heap shows up here because for questions like "which room does each meeting get", the active set has to be a priority queue keyed by end time.

Don't be confused: a heap is not a sorted structure. [1, 8, 2, 9, 10, 3] is a valid min-heap. The only guarantee is that each parent is no greater than its children, so the root is the global minimum and everything else is unordered relative to its siblings. Printing a heap looks like a bug and is not. If you want sorted output you must extract repeatedly, which is heapsort at $O(n \log n)$. The concrete consequence: never index into a heap expecting rank order, and note that top_k in the code below calls sorted() at the end precisely because the heap's internal order is not the answer.

Don't be confused: to find the k largest you use a min-heap, not a max-heap. This inverts in most people's heads. The heap holds the $k$ best candidates so far, and the operation you perform constantly is evicting the worst of them, so the worst must be at the top. A max-heap of size $k$ puts the wrong element within reach.

The problem it solves

"Give me the 10 highest scoring documents out of 50 million" cannot be answered by sorting; that materialises 50 million scored records to throw away all but ten. A bounded min-heap touches each record once, holds ten, and never allocates more. The complexity improvement from $O(n \log n)$ to $O(n \log k)$ is real but secondary. The memory improvement from $O(n)$ to $O(k)$ is what makes it work at all on a stream, and streams are where this pattern actually earns its keep.

Interval problems solve the "overlapping ranges" family that appears in booking systems, resource scheduling, IP address range consolidation, genomic feature sets and log time window analysis. The sweep line answers the harder version, peak concurrency, which is the question behind "how many servers do I need" and "how many meeting rooms".

Mechanics

"""Heaps, top-K, interval merging and the sweep line.

Runnable: `python3 heaps_and_intervals.py`. These sit together because both are
about processing items in an order that is not the input order, and in several
problems (meeting rooms) the heap IS the sweep line's active set.
"""

import heapq


# --- Top-K with a heap -------------------------------------------------------
def top_k(nums, k):
    """The k largest, using a MIN heap of size k.

    The counterintuitive part: to find the largest you keep the smallest at the
    top, because the top is the element you need to evict. Sorting is
    O(n log n) and O(n) space; this is O(n log k) and O(k) space, which is what
    lets it run over a stream you cannot hold in memory.
    """
    heap = []
    for n in nums:
        if len(heap) < k:
            heapq.heappush(heap, n)
        elif n > heap[0]:                 # beats the weakest survivor
            heapq.heapreplace(heap, n)    # one sift, not a pop plus a push
    return sorted(heap, reverse=True)


def k_closest_to(points, k, origin=(0, 0)):
    """Top-K where the comparison key is not the element. Push (key, item) and
    let the heap compare tuples. Negate the key to get a max-heap out of
    Python's min-heap, which is the standard workaround since heapq has no
    reverse option."""
    heap = []
    for x, y in points:
        d = (x - origin[0]) ** 2 + (y - origin[1]) ** 2   # no sqrt: monotonic
        if len(heap) < k:
            heapq.heappush(heap, (-d, (x, y)))
        elif -d > heap[0][0]:
            heapq.heapreplace(heap, (-d, (x, y)))
        # heap holds the k smallest distances, with the LARGEST of them on top
    return [p for _, p in sorted(heap, reverse=True)]


def merge_sorted_streams(streams):
    """K-way merge: the reason heaps exist in most production code. Holds one
    element per stream, so memory is O(k) regardless of stream length. This is
    the merge step of an LSM compaction and of an external sort."""
    heap = [(s[0], i, 0) for i, s in enumerate(streams) if s]
    heapq.heapify(heap)
    out = []
    while heap:
        val, si, idx = heapq.heappop(heap)
        out.append(val)
        if idx + 1 < len(streams[si]):
            heapq.heappush(heap, (streams[si][idx + 1], si, idx + 1))
    return out


# --- Intervals: merging ------------------------------------------------------
def merge_intervals(intervals):
    """Sort by start, then extend or emit. Sorting by START is what makes the
    single pass valid: once sorted, any interval that overlaps the one you are
    building must start before that one ends, so you only ever compare against
    the most recent output."""
    if not intervals:
        return []
    out = []
    for lo, hi in sorted(intervals):
        if out and lo <= out[-1][1]:      # <= merges touching intervals [1,2],[2,3]
            out[-1] = (out[-1][0], max(out[-1][1], hi))
        else:
            out.append((lo, hi))
    return out


def insert_interval(intervals, new):
    """Insert into an already-merged, sorted list. Three phases, in order:
    everything strictly before, everything overlapping (absorbed), everything
    strictly after. Writing it as three loops is clearer than one loop with
    flags, and it is what makes the boundaries checkable."""
    out, i, n = [], 0, len(intervals)
    lo, hi = new
    while i < n and intervals[i][1] < lo:
        out.append(intervals[i])
        i += 1
    while i < n and intervals[i][0] <= hi:
        lo = min(lo, intervals[i][0])
        hi = max(hi, intervals[i][1])
        i += 1
    out.append((lo, hi))
    out.extend(intervals[i:])
    return out


# --- Sweep line --------------------------------------------------------------
def max_overlap(intervals):
    """Peak concurrency: the classic "how many meeting rooms" question.

    Turn each interval into two EVENTS and sort them. The critical detail is the
    tie-break: an END at time t must be processed before a START at time t, or a
    meeting ending exactly when the next begins double-counts a room. Sorting
    (time, delta) with delta -1 for end and +1 for start gets this for free,
    since -1 sorts before +1.
    """
    events = []
    for lo, hi in intervals:
        events.append((lo, +1))
        events.append((hi, -1))
    events.sort()
    cur = best = 0
    at = None
    for t, delta in events:
        cur += delta
        if cur > best:
            best, at = cur, t
    return best, at


def min_rooms_with_heap(intervals):
    """The same answer via a heap, which is the form that also tells you WHICH
    room each meeting goes in. The heap holds the end time of every meeting
    currently running; its top is the soonest to free up."""
    ends = []
    assignment = []
    for lo, hi in sorted(intervals):
        if ends and ends[0][0] <= lo:
            _, room = heapq.heappop(ends)     # reuse the room that just freed
        else:
            room = len(ends)                  # need a new one
        heapq.heappush(ends, (hi, room))
        assignment.append(((lo, hi), room))
    return len(set(r for _, r in assignment)), assignment


if __name__ == "__main__":
    nums = [7, 2, 9, 4, 1, 8, 8, 3]
    print("nums              :", nums)
    print("top_k(3)          :", top_k(nums, 3))
    pts = [(1, 3), (-2, 2), (5, 8), (0, 1), (3, 3)]
    print("points            :", pts)
    print("k_closest_to(2)   :", k_closest_to(pts, 2))
    streams = [[1, 4, 9], [2, 3, 10], [5, 6, 7]]
    print("streams           :", streams)
    print("k-way merge       :", merge_sorted_streams(streams))

    print()
    iv = [(1, 3), (2, 6), (8, 10), (15, 18)]
    print("intervals         :", iv)
    print("merged            :", merge_intervals(iv))
    print("touching [1,2],[2,3] ->", merge_intervals([(1, 2), (2, 3)]))
    base = [(1, 3), (6, 9)]
    print("insert (2,5) into", base, "->", insert_interval(base, (2, 5)))

    print()
    meetings = [(0, 30), (5, 10), (15, 20), (25, 40), (28, 32)]
    print("meetings          :", meetings)
    peak, when = max_overlap(meetings)
    print("sweep line: peak  :", peak, "concurrent, first reached at t =", when)
    rooms, assign = min_rooms_with_heap(meetings)
    print("heap: rooms needed:", rooms)
    for m, r in assign:
        print("   meeting", m, "-> room", r)
    print("back-to-back (0,5),(5,10) needs:", max_overlap([(0, 5), (5, 10)])[0], "room")

Five details that separate a working implementation from a nearly working one.

heapreplace, not heappop then heappush. Both give the same result, but heapreplace performs one sift-down instead of a sift-up and a sift-down. In a hot loop over 50 million records that is a measurable difference, and knowing the API exists is a small signal that you have used heaps outside of interviews.

Push tuples (key, item), and negate the key when you need the other direction. Python's heapq is a min-heap only, with no key= parameter. The standard idiom is to push (-priority, item). The trap: if two keys tie, Python then compares the second tuple element, so the item type must be comparable or you get a TypeError at an unpredictable moment. The production fix is to push (key, counter, item) with a monotonic counter, which both breaks ties deterministically and guarantees the item is never compared.

k_closest_to compares squared distance and never calls sqrt. Square root is monotonic on non-negative inputs, so it cannot change the ordering, and skipping it removes a transcendental function from the inner loop along with the floating point error it introduces. This generalises: whenever you are ranking rather than reporting, strip any monotonic transform from the key.

merge_intervals sorts by start, and that choice is the correctness argument. Once sorted by start, any interval that overlaps the block you are currently building must begin before that block ends, so it suffices to compare against the single most recent output element. Sort by end instead and that property is gone and you would need to look further back. Say this rather than saying "we sort first".

The sweep line's tie-break decides the answer. Events are (time, delta) with +1 for a start and -1 for an end, and the sort puts -1 before +1 at equal times because $-1 < +1$. That means a meeting ending at 10 is processed before one starting at 10, so back-to-back meetings share a room. If your problem treats an interval as closed on both ends, so touching intervals conflict, flip the encoding. This is a one-character change that silently produces an off-by-one in the final answer, and interviewers test it with a back-to-back input.

Worked example

nums              : [7, 2, 9, 4, 1, 8, 8, 3]
top_k(3)          : [9, 8, 8]
points            : [(1, 3), (-2, 2), (5, 8), (0, 1), (3, 3)]
k_closest_to(2)   : [(0, 1), (-2, 2)]
streams           : [[1, 4, 9], [2, 3, 10], [5, 6, 7]]
k-way merge       : [1, 2, 3, 4, 5, 6, 7, 9, 10]

intervals         : [(1, 3), (2, 6), (8, 10), (15, 18)]
merged            : [(1, 6), (8, 10), (15, 18)]
touching [1,2],[2,3] -> [(1, 3)]
insert (2,5) into [(1, 3), (6, 9)] -> [(1, 5), (6, 9)]

meetings          : [(0, 30), (5, 10), (15, 20), (25, 40), (28, 32)]
sweep line: peak  : 3 concurrent, first reached at t = 28
heap: rooms needed: 3
   meeting (0, 30) -> room 0
   meeting (5, 10) -> room 1
   meeting (15, 20) -> room 1
   meeting (25, 40) -> room 1
   meeting (28, 32) -> room 2
back-to-back (0,5),(5,10) needs: 1 room

top_k returning [9, 8, 8] keeps the duplicate, which is correct and is worth checking deliberately, because an implementation built on a set instead of a heap returns [9, 8, 7] and looks plausible. If the problem wants distinct values, that is a different problem and you should ask.

k_closest_to(pts, 2) returns [(0,1), (-2,2)]. The squared distances are $(0,1) \to 1$, $(-2,2) \to 8$, $(1,3) \to 10$, $(3,3) \to 18$, $(5,8) \to 89$, so the two nearest are right. Notice the output is ordered farthest-first inside the sorted call because the heap stores negated keys; the final sorted(heap, reverse=True) on negated keys yields ascending true distance. Sign conventions in a negated heap are the most common source of a silently reversed result, so verify with a hand-checked input like this one every time.

The two meeting-room answers agree at 3, and they are not the same computation. The sweep line answers "what is the peak", and it tells you the peak is first reached at $t = 28$: at that moment (0,30), (25,40) and (28,32) are all running. It does not and cannot tell you which room anything goes in. The heap version answers the assignment question and the room count falls out of it. Pick the sweep line when you need the number and the heap when you need the schedule, and say which the problem asked for.

Read the assignment output closely: room 1 is reused three times, by (5,10), then (15,20), then (25,40). That is the heap doing its job. (15,20) starts at 15, the soonest-ending active meeting is (5,10) which ended at 10, so its room is free and gets reused rather than allocating a fourth. A greedy assignment that always allocated a new room would report 5.

back-to-back (0,5),(5,10) needs 1 room is the tie-break test described above. If the event sort had put +1 before -1, this would print 2, and every other number in the output would still look correct.

Production evidence

Lucene's top-K retrieval. Lucene collects hits into a bounded priority queue (HitQueue, a min-heap of size $k$) and discards any document whose score does not beat the queue's current worst. This is why asking for the top 10 of a 100-million-document index does not allocate 100 million results, and it is the direct production form of top_k. It also enables the WAND and block-max optimisations, which skip entire posting-list blocks whose maximum possible score cannot beat the heap's current threshold.

LSM-tree compaction is a k-way merge. RocksDB and LevelDB compact by opening an iterator over each input SSTable and merging them with a heap that holds one key per input, emitting in sorted order. Memory stays $O(\text{number of files})$ regardless of how large the files are, which is the property that makes compacting terabyte levels possible. External merge sort in a database's sort operator is the same algorithm.

Dijkstra's algorithm. The priority queue is the heap, and the choice of heap changes the published complexity: a binary heap gives $O((V+E) \log V)$, a Fibonacci heap gives $O(E + V \log V)$. In practice the binary heap almost always wins because the Fibonacci heap's constant factors and cache behaviour are poor, which is a useful example of an asymptotically better structure losing in production.

Sweep line in computational geometry. The Bentley-Ottmann algorithm finds all intersections among $n$ line segments in $O((n+k) \log n)$ for $k$ intersections by sweeping a vertical line and maintaining the active segments in a balanced structure ordered by their position along the sweep. It is the same event-sorted, active-set-maintaining shape as max_overlap, generalised from one dimension to two.

The debate

Heap or sorted()[:k] for top-K? For a list already in memory where $k$ is a significant fraction of $n$, just sort. The constant factor on a highly optimised sort (Python's Timsort is C code that exploits existing runs) beats a heap loop in the interpreter, and the code is one line. The heap wins decisively in exactly two situations: $k \ll n$, and the data is a stream that does not fit in memory. My position: state the crossover instead of asserting a winner. "If $k$ is small relative to $n$ or the input is a stream, bounded heap at $O(n \log k)$ and $O(k)$ space. If everything is in memory and $k$ is within an order of magnitude of $n$, sort and slice, because the constants dominate." A third option worth naming: heapq.nlargest in the standard library does exactly the bounded-heap thing, and Quickselect gives expected $O(n)$ if you need the top $k$ unordered and can tolerate a worst case of $O(n^2)$ or the complexity of median-of-medians.

Sweep line or heap for meeting rooms? They are $O(n \log n)$ either way, dominated by the sort. Take the sweep line when the question is a count, because the code is shorter and the events generalise (add a +1 for a start and a -1 for an end and you can mix in other event types for free). Take the heap when you need the assignment, or when intervals arrive online and you cannot sort up front. The sweep line has one property that decides several real cases: it extends to weighted events at no cost. Replace the deltas with arbitrary numbers and "peak concurrent connections" becomes "peak bandwidth" with no other change, which the heap version cannot do.

When are intervals the wrong model entirely? When ranges are dense over a small coordinate space, a difference array or a bitmap over the coordinate space is simpler and faster than sorting intervals, as covered under prefix sums. And when queries are interleaved with updates rather than batched, you want an interval tree or a segment tree, because re-sorting per query is $O(n \log n)$ each time. The honest interview answer names the batch-versus-online distinction as the deciding variable, rather than defending one structure.

Follow-up Q&A

Why is heapify $O(n)$ and not $O(n \log n)$? Because the cost is dominated by the nodes near the leaves, and there are many of those but each sifts down a short distance. At height $h$ from the bottom there are about $n/2^{h+1}$ nodes, each costing $O(h)$, and $\sum_h h/2^{h+1}$ converges to a constant. So building a heap from an existing list is linear, and it is strictly better than $n$ successive pushes. That is why merge_sorted_streams builds the initial list and calls heapify rather than pushing in a loop.

How do you delete an arbitrary element from a heap? You cannot, in $O(\log n)$, without an auxiliary index from element to heap position, which is a real amount of bookkeeping and must be maintained through every sift. The usual production answer is lazy deletion: mark the element dead in a side set, leave it in the heap, and discard it when it surfaces at the top. The cost is that the heap can grow with dead entries, so you either bound it or rebuild when the dead fraction crosses a threshold. This exact pattern is how a sliding window maximum with a heap works, and knowing to reach for lazy deletion rather than claiming an $O(\log n)$ arbitrary delete is the signal.

Your merge_intervals merges [1,2] and [2,3] into [1,3]. Is that right? It depends on whether the intervals are closed or half open, and this is a question to ask rather than assume. For closed intervals representing occupancy, they touch and merging is right, which is why the comparison is lo <= out[-1][1]. For half-open intervals [1,2) and [2,3) they do not overlap, and the comparison should be <. The output line in the run above exists to make the chosen convention visible instead of implicit. In an interview, state the convention before you write the comparison; it takes four seconds and it is a thing interviewers deliberately leave ambiguous.

How would you compute peak concurrency over a billion events that do not fit in memory? The sweep line needs sorted events, and external merge sort handles that in $O(n \log n)$ I/O-bounded passes. But usually you do not need exact event ordering: bucket events by time granularity (per second, per minute), which turns the problem into a difference array over buckets, and that is one streaming pass with $O(\text{buckets})$ memory and is trivially parallel by time range. Give up exactness at sub-bucket resolution and the problem becomes easy. Naming that tradeoff explicitly is better than describing a distributed sort.

Two heaps for a running median: how? Keep a max-heap of the lower half and a min-heap of the upper half, rebalanced after each insert so their sizes differ by at most one. The median is then the top of the larger heap, or the mean of the two tops when the sizes are equal. Each insert is $O(\log n)$. The bug to avoid is rebalancing by size only without checking the ordering invariant across the two heaps, since a new element can belong on the other side; insert by comparing against a top first, then rebalance.

In min_rooms_with_heap, why push (hi, room) rather than just hi? Because the room identity has to travel with the end time, and the heap is ordered by the first tuple element. If two meetings end at the same time, Python compares the second element, which is an integer room number and is therefore safely comparable. Had the payload been a non-comparable object, this would raise a TypeError only on the input where a tie occurs, which is the sort of bug that reaches production.

Common misconceptions

"A heap gives me the k largest in sorted order." It gives you them in heap order. top_k sorts before returning, and that final sort is $O(k \log k)$, which is negligible but is not free and is not automatic.

"heapq has a max-heap." It does not. Negate the key, or use heapq._heapify_max and accept that you are calling a private function. Negation fails on non-numeric keys, which is when you write a wrapper class with __lt__ reversed.

"Sorting by start is arbitrary; I could sort by end." For merging, sorting by start is what makes the one-comparison-back pass valid. Sorting by end is correct for a different problem, the activity selection or "maximum non-overlapping intervals" greedy, where you want to finish as early as possible to leave room. Two interval problems, two different sort keys, and using the wrong one gives a wrong answer rather than a slow one.

"The sweep line needs the intervals sorted." It needs the events sorted, which is twice as many items and a different ordering. Sorting the intervals and then generating events in that order does not produce sorted events, because an early-starting interval can end after a later one starts.

Interview delivery note

The sentence for top-K: "I will keep a min-heap of size k, so the top is the weakest survivor and eviction is $O(\log k)$. That gives $O(n \log k)$ time and, more importantly, $O(k)$ memory, so it works on a stream I cannot hold." Leading with the memory bound rather than the time bound is what marks someone who has actually run this at scale, because at scale the memory is the reason.

The sentence for intervals: "Sort by start. After that, anything overlapping the block I am building must start before that block ends, so I only ever compare against the last output element." State the invariant, then write four lines.

The senior-to-staff separator here is noticing that the two meeting-room formulations answer different questions and asking which one is wanted before coding. A senior candidate implements one and it is usually right. A staff candidate says: "If you want the number of rooms, that is a sweep line and it also gives me the peak time for free, and it generalises if events are weighted. If you want each meeting assigned to a room, that is a heap keyed on end time. Which do you need?" Turning an ambiguous requirement into an explicit choice, before writing code that has to be thrown away, is the behaviour the round is actually measuring.

Further reading

• Cormen, Leiserson, Rivest and Stein. Introduction to Algorithms, 4th ed. Chapter 6 (Heapsort), including the linear-time BUILD-MAX-HEAP analysis.
• Jon Bentley and Thomas Ottmann. "Algorithms for Reporting and Counting Geometric Intersections." IEEE Transactions on Computers, 1979. The sweep line, from the source.
• Python heapq documentation, whose "Priority Queue Implementation Notes" cover the tie-break counter and lazy deletion directly.
• Lucene TopScoreDocCollector, for the bounded priority queue in a search engine's collection phase.

Backtracking with pruning, and tries

What it is

Backtracking is depth-first search over a tree of decisions that you never build. At each node you make a choice, recurse, and then undo the choice so the next branch starts from a clean state. The undo is what makes it backtracking rather than ordinary recursion, and its cost is why the pattern is memory-cheap: one path is in memory at a time, not the whole tree. Pruning is the part that matters. The unpruned search explores every leaf; a good prune kills a subtree the moment it becomes provably useless, and in problems like n-queens that is the difference between finishing and not.

A trie (prefix tree) stores a set of strings as a tree where each edge is one character and each node represents the prefix spelled by the path to it. Lookup costs $O(\text{length of the key})$ and, importantly, does not depend on how many keys are stored. That independence is the property a hash map cannot match once the question involves prefixes.

They share a page because their hardest common form is a single problem: searching a grid for many words at once, where the trie is what makes the backtracking's pruning cheap.

Don't be confused: a trie is not usually faster than a hash map for exact lookup. A hash map hashes the key once and does one probe. A trie does one pointer dereference per character, each a potential cache miss. For "is this exact string present", the hash map wins in practice, and claiming otherwise is a tell. The trie wins where the hash map has nothing to offer at all: all keys with this prefix, longest prefix match, all keys within edit distance 1, and iteration in sorted order. Choose it for the question it can answer, not for a speed claim it cannot support.

Don't be confused: exponential output is not the same as an inefficient algorithm. subsets on $n$ items returns $2^n$ tuples, so no algorithm can be faster than exponential; the output is that size. Saying "this is $O(2^n)$, but that is optimal because the answer has $2^n$ elements" is correct and expected. Backtracking becomes genuinely inefficient only when it explores subtrees that contain no answers, which is exactly what pruning removes.

The problem it solves

Backtracking solves constrained enumeration: produce every arrangement satisfying a set of rules, or find one, when there is no formula and no greedy rule that works. Sudoku, n-queens, parsing ambiguous grammars, scheduling under constraints, and every "generate all valid X" problem.

The trie solves prefix questions at a scale where the alternatives collapse. Storing a million words and asking "which start with car" costs a full scan with a hash map, $O(\log n)$ plus a scan of the matches with a sorted array, and $O(3)$ plus the matches with a trie. It also solves longest prefix match, which has no good hash map formulation at all, and which is the operation every IP router performs for every packet.

Mechanics

"""Backtracking with pruning, and tries.

Runnable: `python3 backtracking_and_tries.py`. They share a page because the
canonical hard version of each is the same problem: word search on a grid, where
the trie is what makes the backtracking's pruning cheap.
"""


# --- Backtracking: the shape -------------------------------------------------
# Every backtracking solution is the same four lines around a loop:
#   choose -> recurse -> un-choose, with a base case and a pruning test.
# The un-choose is what makes it backtracking rather than plain recursion, and
# forgetting it is the single most common bug.
def permutations(items):
    out, used, path = [], [False] * len(items), []

    def walk():
        if len(path) == len(items):
            out.append(tuple(path))         # copy: path is mutated after this
            return
        for i, it in enumerate(items):
            if used[i]:
                continue
            used[i] = True                  # choose
            path.append(it)
            walk()                          # recurse
            path.pop()                      # un-choose
            used[i] = False
    walk()
    return out


def subsets(items):
    """Include-or-exclude, the other canonical shape. 2^n subsets, so this is
    exponential by definition, not by inefficiency: the OUTPUT is exponential."""
    out, path = [], []

    def walk(i):
        if i == len(items):
            out.append(tuple(path))
            return
        walk(i + 1)                          # exclude items[i]
        path.append(items[i])                # include it
        walk(i + 1)
        path.pop()
    walk(0)
    return out


def combination_sum(candidates, target):
    """Pruning that actually changes the complexity class. Sorting lets the loop
    BREAK rather than CONTINUE: once a candidate overshoots, every later one
    does too, so the whole remaining branch is dead."""
    out, path = [], []
    candidates = sorted(candidates)
    calls = [0]

    def walk(start, remaining):
        calls[0] += 1
        if remaining == 0:
            out.append(tuple(path))
            return
        for i in range(start, len(candidates)):
            if candidates[i] > remaining:
                break                        # PRUNE: sorted, so all later ones too
            path.append(candidates[i])
            walk(i, remaining - candidates[i])   # i, not i+1: reuse allowed
            path.pop()
    walk(0, target)
    return out, calls[0]


def combination_sum_unpruned(candidates, target):
    """The same search with `continue` instead of `break`, to measure what the
    pruning is worth."""
    out, path = [], []
    candidates = sorted(candidates)
    calls = [0]

    def walk(start, remaining):
        calls[0] += 1
        if remaining == 0:
            out.append(tuple(path))
            return
        if remaining < 0:
            return
        for i in range(start, len(candidates)):
            path.append(candidates[i])
            walk(i, remaining - candidates[i])
            path.pop()
    walk(0, target)
    return out, calls[0]


def n_queens(n):
    """Pruning by maintaining attacked sets instead of re-scanning the board.
    A diagonal is constant in (row - col); an anti-diagonal is constant in
    (row + col). That is the whole trick, and it turns an O(n) check per
    placement into O(1)."""
    cols, diag, anti = set(), set(), set()
    placements, count = [], [0]

    def walk(row, board):
        if row == n:
            count[0] += 1
            if len(placements) < 2:
                placements.append(list(board))
            return
        for col in range(n):
            if col in cols or (row - col) in diag or (row + col) in anti:
                continue                     # PRUNE
            cols.add(col); diag.add(row - col); anti.add(row + col)
            board.append(col)
            walk(row + 1, board)
            board.pop()
            cols.discard(col); diag.discard(row - col); anti.discard(row + col)
    walk(0, [])
    return count[0], placements


# --- Trie --------------------------------------------------------------------
class Trie:
    """A prefix tree. Each edge is one character, each node is the prefix spelled
    by the path from the root. Lookup is O(len(word)) and, crucially, INDEPENDENT
    of how many words are stored, which is what a hash map cannot offer for
    prefix queries."""

    def __init__(self):
        self.root = {}
        self.END = "$"          # a key that cannot collide with a character

    def insert(self, word):
        node = self.root
        for ch in word:
            node = node.setdefault(ch, {})
            node.setdefault("#count", 0)
            node["#count"] += 1              # words passing through this prefix
        node[self.END] = word

    def search(self, word):
        node = self._walk(word)
        return node is not None and self.END in node

    def starts_with(self, prefix):
        return self._walk(prefix) is not None

    def count_with_prefix(self, prefix):
        node = self._walk(prefix)
        return node["#count"] if node else 0

    def _walk(self, s):
        node = self.root
        for ch in s:
            if ch not in node:
                return None
            node = node[ch]
        return node

    def autocomplete(self, prefix, limit=5):
        node = self._walk(prefix)
        if node is None:
            return []
        out = []

        def collect(n):
            if len(out) >= limit:
                return
            if self.END in n:
                out.append(n[self.END])
            for ch in sorted(k for k in n if len(k) == 1 and k != self.END):
                collect(n[ch])
        collect(node)
        return out


def word_search(board, words):
    """Backtracking + trie together. Searching each word independently is
    O(words * cells * 4^len). Putting all words in a trie walks the grid ONCE
    and prunes the moment the path spells a prefix no word has."""
    trie = Trie()
    for w in words:
        trie.insert(w)
    rows, cols = len(board), len(board[0])
    found, visits = set(), [0]

    def walk(r, c, node):
        visits[0] += 1
        ch = board[r][c]
        if ch not in node:
            return                            # PRUNE: dead prefix
        nxt = node[ch]
        if trie.END in nxt:
            found.add(nxt[trie.END])
        board[r][c] = None                    # mark visited in place
        for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)):
            nr, nc = r + dr, c + dc
            if 0 <= nr < rows and 0 <= nc < cols and board[nr][nc] is not None:
                walk(nr, nc, nxt)
        board[r][c] = ch                      # un-choose
    for r in range(rows):
        for c in range(cols):
            walk(r, c, trie.root)
    return sorted(found), visits[0]


if __name__ == "__main__":
    print("permutations([1,2,3]) :", permutations([1, 2, 3]))
    print("subsets([1,2,3])      :", subsets([1, 2, 3]))

    print()
    res, pruned_calls = combination_sum([2, 3, 6, 7], 7)
    _, unpruned_calls = combination_sum_unpruned([2, 3, 6, 7], 7)
    print("combination_sum([2,3,6,7], 7) :", res)
    print("recursive calls, pruned       :", pruned_calls)
    print("recursive calls, unpruned     :", unpruned_calls)

    print()
    for n in (4, 6, 8):
        count, ex = n_queens(n)
        print(f"n_queens({n}) solutions      : {count}")
    print("first two 8-queens boards (column per row):")
    for b in n_queens(8)[1]:
        print("   ", b)

    print()
    t = Trie()
    for w in ["car", "card", "care", "careful", "cat", "dog"]:
        t.insert(w)
    print("search('car')         :", t.search("car"))
    print("search('ca')          :", t.search("ca"), "(a prefix is not a word)")
    print("starts_with('ca')     :", t.starts_with("ca"))
    print("count_with_prefix(car):", t.count_with_prefix("car"))
    print("count_with_prefix(ca) :", t.count_with_prefix("ca"))
    print("autocomplete('car')   :", t.autocomplete("car"))

    print()
    board = [list("oaan"), list("etae"), list("ihkr"), list("iflv")]
    words = ["oath", "pea", "eat", "rain", "hike"]
    hits, visits = word_search(board, words)
    print("board                 :", ["".join(r) for r in board])
    print("words                 :", words)
    print("found                 :", hits)
    print("cell visits with trie :", visits)

Five details worth defending.

out.append(tuple(path)) copies. path is mutated after the append, so storing a reference stores a list that will be empty by the time you read it. This produces the famous "all my results are identical" or "all my results are empty" bug, and it happens to almost everyone once.

The un-choose must undo everything the choose did. In n_queens, the choose adds to three sets and appends to the board, and the un-choose removes from three sets and pops. Miss one and the search silently loses solutions. Keeping choose and un-choose adjacent and symmetric in the source is a deliberate defence against this.

n_queens prunes with $O(1)$ attack tests, not by scanning the board. Two cells share a diagonal exactly when row - col is equal, and an anti-diagonal exactly when row + col is equal. Maintaining three sets makes the legality check constant time instead of $O(n)$.

combination_sum uses break, not continue. Because the candidates are sorted, once one overshoots the remaining target, every later one does too, so the entire rest of the loop is dead. break kills it; continue walks it. The code includes an unpruned twin purely to measure this.

In the trie, the terminal marker is "$" and the count key is "#count". Both are chosen to be strings that cannot collide with a single character, and autocomplete filters children with len(k) == 1 for the same reason. Using a sentinel that could be a legitimate character is a bug waiting for the input that contains it. A production implementation uses a node class with explicit fields rather than overloading a dict, and that is the better answer if asked to make it production-ready.

Worked example

permutations([1,2,3]) : [(1, 2, 3), (1, 3, 2), (2, 1, 3), (2, 3, 1), (3, 1, 2), (3, 2, 1)]
subsets([1,2,3])      : [(), (3,), (2,), (2, 3), (1,), (1, 3), (1, 2), (1, 2, 3)]

combination_sum([2,3,6,7], 7) : [(2, 2, 3), (7,)]
recursive calls, pruned       : 10
recursive calls, unpruned     : 28

n_queens(4) solutions      : 2
n_queens(6) solutions      : 4
n_queens(8) solutions      : 92
first two 8-queens boards (column per row):
    [0, 4, 7, 5, 2, 6, 1, 3]
    [0, 5, 7, 2, 6, 3, 1, 4]

search('car')         : True
search('ca')          : False (a prefix is not a word)
starts_with('ca')     : True
count_with_prefix(car): 4
count_with_prefix(ca) : 5
autocomplete('car')   : ['car', 'card', 'care', 'careful']

board                 : ['oaan', 'etae', 'ihkr', 'iflv']
words                 : ['oath', 'pea', 'eat', 'rain', 'hike']
found                 : ['eat', 'oath']
cell visits with trie : 47

The pruning measurement is the point of this page. The same search, the same answers, 10 recursive calls with break against 28 with continue. That is a factor of 2.8 on a four-element input with a target of 7. The ratio grows with the input, because the pruned version never enters subtrees whose first step already overshoots, and the number of such subtrees grows combinatorially. Reporting a measured ratio rather than asserting "pruning helps" is what makes the claim worth anything, and instrumenting a call counter takes one line, which is a thing you can do live in an interview if challenged.

The n-queens counts are the standard sequence: 2 for $n=4$, 4 for $n=6$, 92 for $n=8$. If you write this and get 92, you are right; if you get anything else, the un-choose is incomplete. This is a self-checking problem and it is worth knowing that 92 is the number.

search('ca') is False while starts_with('ca') is True, which is the distinction the terminal marker exists to make. A trie node's existence means a prefix was seen, not that a word ends there. Every trie bug involving "it returns words I never inserted" traces back to conflating the two.

count_with_prefix('car') is 4 (car, card, care, careful) and ('ca') is 5 (those four plus cat). The counts are maintained on insert, which makes them $O(1)$ to read. The alternative, walking the subtree on each query, is $O(\text{subtree size})$ and is what people write first.

word_search finds eat and oath in 47 cell visits. Both pea and rain and hike are absent from the grid, and the trie means the search abandoned those paths as soon as the spelled prefix left the trie, rather than exploring four directions to each word's full length. Four separate depth-first searches, one per word, would visit substantially more.

Production evidence

Regex engines backtrack, and it has taken down real systems. PCRE, Python's re, Java's java.util.regex and JavaScript's engine are all backtracking matchers: on a failed alternative they rewind and try the next. A pattern with nested quantifiers such as (a+)+b can take exponential time on a non-matching input, which is the ReDoS vulnerability class. Cloudflare's global outage on 2 July 2019 was caused by a regular expression deployed to their WAF that backtracked catastrophically and drove CPU to saturation across the fleet; their public post-mortem describes the pattern and the fix. The structural answer is a non-backtracking engine (RE2, used by Go's regexp and by several services precisely for this reason), which guarantees linear time by refusing to support backreferences.

SAT solvers are backtracking with industrial-strength pruning. DPLL is backtracking search over variable assignments, with unit propagation and pure literal elimination as pruning rules; modern CDCL solvers add conflict-driven clause learning, which is pruning that remembers why a subtree failed so the same failure is never re-explored. Package managers use them: Dart's pub and several others resolve version constraints with a CDCL-derived algorithm, because dependency resolution is NP-complete and backtracking with learning is what makes it tractable.

Lucene's term dictionary is a compressed trie. Lucene stores the terms of each index segment in a finite state transducer, which is a trie with common suffixes shared as well as common prefixes, and it maps terms to postings-list offsets. That structure is what makes prefix queries, wildcard queries and range queries over terms work without scanning the dictionary, and it is compact enough to hold in memory for a segment.

IP routing is longest prefix match on a trie. A routing table maps address prefixes of varying length to next hops, and forwarding requires the longest matching prefix. The Linux kernel's forwarding information base uses an LC-trie (a level-compressed trie) for IPv4. There is no hash map formulation of this operation, which is the cleanest example of a trie being chosen for capability rather than speed.

Aho-Corasick is a trie with failure links, and it matches many patterns against a text in one pass, in time linear in the text plus the number of matches, independent of the number of patterns. grep -F with many patterns, intrusion detection signature matching, and content scanning all use it. The word_search function on this page is the same idea applied to a grid instead of a string.

The debate

How much should you prune in an interview? There is a real tradeoff and candidates get it wrong in both directions. Aggressive pruning is more code, more chances for an off by one, and harder to explain. My position: write the correct unpruned search first, out loud say "this is exponential and I am going to add pruning", then add exactly the prunes you can justify in one sentence each. In combination_sum that is the sort plus break, which is two lines. In n-queens it is the three attack sets. Do not add a prune you cannot explain, because an interviewer will ask why it is safe, and "safe" means it cannot remove a valid solution, which is a proof obligation.

Trie or hash map for autocomplete? The honest answer is that most production autocomplete is not a bare trie. A trie gives you the candidate set for a prefix, but the product requirement is the top k by popularity, and walking a whole subtree to sort it is too slow when the prefix is short and the subtree is most of the corpus. The production shapes are a trie with the top-k precomputed and cached at each node, or a finite state transducer with weights, or (increasingly) an inverted index over prefix n-grams. Say the trie, then immediately say "with the top-k materialised per node, otherwise a one-character prefix walks the entire corpus." That second clause is the whole difference between a textbook answer and someone who has shipped a typeahead.

When is a trie the wrong structure? When memory matters and keys are long and sparse. A naive trie node with a 26-slot child array wastes enormous space when most children are empty, and the pointer chasing is cache-hostile. The fixes are a radix or Patricia trie (collapse chains of single-child nodes into one edge labelled with a substring), which is what routing tables actually use, or an FST if the set is static. For a large static string set, an FST or a succinct structure will be several times smaller than a pointer trie. If the key set is static and you only need exact lookup, a perfect hash beats both.

Follow-up Q&A

Why does subsets produce them in that order, with the empty set first and (3,) second? Because the recursion excludes before it includes: walk(i+1) without appending runs first. So the first leaf reached excludes everything, then the deepest choice flips first. Order is a consequence of the recursion's shape, not of the problem, and if a specific order is required you either reorder the two recursive calls or sort at the end. Being able to say why the order is what it is, rather than being surprised by it, is the signal.

How do you handle duplicates in the input for permutations or subsets? Sort the input, then within the loop skip any candidate equal to its predecessor that has not been used at this level: if i > 0 and items[i] == items[i-1] and not used[i-1]: continue. The not used[i-1] clause is the subtle part; it distinguishes "the duplicate is being reused at the same tree level" (skip, it makes a duplicate result) from "the duplicate is being used deeper in the same path" (allow, it is a legitimate arrangement). Getting this condition backwards produces either duplicates or missing results, and it is a standard follow-up.

What is the actual complexity of n-queens with your pruning? There is no useful closed form; the number of solutions itself has no formula and is a well studied open problem. The correct answer is to state the upper bound honestly, $O(n!)$ for the unpruned search since each row picks a distinct column, and then say that pruning reduces it by a large but unquantified constant-and-more factor in practice. Interviewers ask this partly to see whether you will invent a bound. Do not.

When would you convert backtracking into dynamic programming? When subtrees repeat, that is, when different decision paths reach the same state and the answer depends only on that state and not on the path. Backtracking over "which coins have I used" has no repetition, so it stays backtracking. Backtracking over "how much target remains" reaches the same remaining value many ways, so memoising on the remaining value converts an exponential search into a polynomial DP. The test is whether the state is smaller than the path, and that sentence is the bridge between this pattern and dynamic programming.

Your trie stores a #count on every node during insert. What breaks if you support delete? The counts have to be decremented along the same path, and nodes whose count reaches zero should be removed or they leak memory and slow later traversals. Deletion in a trie is genuinely fiddly because you can only remove a node when it has no children and is not a word terminal, so you walk back up from the terminal removing while both conditions hold. Most interview tries skip delete for this reason, and saying that explicitly is better than implementing it badly.

How would you find all words within edit distance 1 of a query using the trie? Walk the trie while tracking a small edit budget, allowing at each step a match, a substitution, an insertion or a deletion, and prune any branch whose budget is exhausted. This is the trie version of the Levenshtein automaton, and it is how Lucene's fuzzy query works. The reason it is fast is precisely the pruning: a branch that has already spent its budget and does not match is abandoned near the root rather than at the leaves.

Common misconceptions

"Backtracking and DFS are different algorithms." Backtracking is DFS, over an implicit tree of decisions rather than an explicit graph, plus the undo step and the pruning. If you can already write a DFS, you can write backtracking, and framing it that way makes the pattern much less intimidating.

"Pruning is an optimisation I can add later." For enumeration problems, sometimes. For search problems like n-queens at $n = 20$, or SAT, pruning is the difference between terminating and not, so it is part of the algorithm rather than a tuning pass.

"A trie gives $O(1)$ lookup." It gives $O(m)$ for a key of length $m$, with a pointer dereference and likely a cache miss per character. What is $O(1)$ with respect to is the number of stored keys, and that is the claim to make precisely.

"Regexes are fast." Backtracking regex engines are fast on typical input and catastrophically slow on adversarial input. If a regex ever sees user-supplied input, either use a linear-time engine or bound the execution, and know that this is a documented availability vulnerability class rather than a theoretical one.

Interview delivery note

Before writing any backtracking, say the four parts out loud: "State is X. The choices at each step are Y. The base case is Z. The prune is: if [condition] then no completion of this path can work, so I stop." Naming the prune and its justification in the same breath is the move, because the justification is what proves you have not broken correctness.

The senior-to-staff separator: connecting the pattern to its production failure mode unprompted. A senior candidate writes a correct backtracking search. A staff candidate writes the same code and adds: "Note this is the same machinery as a backtracking regex engine, so the same input-dependent blowup applies. If this ever runs on user-controlled input, I would bound the node count and fail closed rather than let it run, which is essentially the mitigation for ReDoS." Similarly on the trie: "this answers prefix queries, but for autocomplete I would materialise the top k at each node, because a one-character prefix otherwise walks the whole corpus." Both sentences say the same thing about you: you have thought about what happens when this code meets real traffic, which is the thing a staff engineer is hired to do.

Further reading

• Cloudflare. "Details of the Cloudflare outage on July 2, 2019." The catastrophic backtracking post-mortem, with the offending pattern and the analysis.
• Alfred V. Aho and Margaret J. Corasick. "Efficient string matching: an aid to bibliographic search." Communications of the ACM, 1975. The trie with failure links.
• Russ Cox. "Regular Expression Matching Can Be Simple And Fast." swtch.com/~rsc/regexp/regexp1.html, 2007. Why backtracking engines blow up and what RE2 does instead.
• Donald Knuth. "Dancing Links." 2000. Backtracking with an exact-cover data structure that makes the choose and un-choose steps $O(1)$, which is the most elegant treatment of the undo problem in this page.

Dynamic programming: 1D, 2D, knapsack, LIS and edit distance

What it is

Dynamic programming is a technique for problems where a solution decomposes into overlapping subproblems and the answer to a subproblem depends only on the subproblem, not on the path taken to reach it. You solve each subproblem once, store the result, and reuse it. That is the whole idea. Everything else is bookkeeping about what the subproblem is and what order to solve them in.

Two properties must hold. Optimal substructure: the optimal solution contains optimal solutions to its subproblems. Overlapping subproblems: the same subproblem is reached many times. Miss the first and DP gives wrong answers; miss the second and DP is just recursion with wasted memory.

Don't be confused: "DP" is not a class of problems, it is a property of your state definition. The same problem is exponential or polynomial depending on what you choose as the state. Backtracking over "which coins have I picked" has no overlap, because every path holds a different multiset. Rewrite the state as "how much target remains" and paths collapse onto each other, and the same problem becomes a polynomial DP. The state definition is the work; the recurrence usually writes itself once the state is right. If you cannot find the DP, you have the wrong state, not the wrong recurrence.

Don't be confused: memoisation and tabulation are the same algorithm. Top-down memoised recursion and bottom-up table filling compute the same values with the same complexity. They differ in three practical ways: top-down only computes the states it actually needs (which can be far fewer), bottom-up avoids recursion-depth limits and function-call overhead, and only bottom-up lets you drop the table to a rolling row for $O(1)$ or $O(n)$ space. Neither is "the real DP".

The problem it solves

Naive recursion for Fibonacci recomputes fib(30) millions of times. That is the toy version of a real problem: any recursive formulation whose call tree revisits states does exponential work for a polynomial amount of distinct information. DP converts the tree into a DAG and evaluates each node once.

More usefully, DP handles optimisation under constraints where greedy fails. coin_change in the code below is the standard demonstration: with coins ${1, 5, 6, 9}$ and a target of 11, greedy takes 9 first and needs $9+1+1 = 3$ coins, while the optimum is $5+6 = 2$. Greedy is correct for some coin systems (including most real currencies, which are designed to be canonical) and wrong for others, and you cannot tell by looking. DP does not care.

Mechanics

"""Dynamic programming: 1D, 2D, knapsack, LIS and edit distance.

Runnable: `python3 dynamic_programming.py`. The five shapes the interview
pattern list names, each with the state definition written out, because the
state definition IS the problem and the recurrence follows from it.
"""

import bisect
from functools import lru_cache


# --- 1D: the state is one index ----------------------------------------------
def house_robber(nums):
    """state: best[i] = the most you can take from the first i houses.
    recurrence: best[i] = max(skip house i, take house i + best[i-2])
    Rolling two variables instead of an array, because the recurrence only ever
    looks back two steps. O(n) time, O(1) space."""
    take, skip = 0, 0
    for n in nums:
        take, skip = skip + n, max(skip, take)
    return max(take, skip)


def coin_change(coins, amount):
    """state: fewest[a] = fewest coins summing exactly to a, or infinity.
    recurrence: fewest[a] = 1 + min(fewest[a - c] for each coin c <= a)

    UNBOUNDED knapsack: coins are reusable, so the inner loop runs FORWARD over
    amounts and each coin can be picked up again at a larger amount."""
    INF = float("inf")
    fewest = [0] + [INF] * amount
    for a in range(1, amount + 1):
        for c in coins:
            if c <= a and fewest[a - c] + 1 < fewest[a]:
                fewest[a] = fewest[a - c] + 1
    return -1 if fewest[amount] == INF else fewest[amount]


# --- 0/1 knapsack: the one where loop ORDER carries the meaning --------------
def knapsack_01(weights, values, capacity):
    """state: best[c] = best value achievable with capacity c, using the items
    considered so far.

    The inner loop runs BACKWARD over capacity. That single detail is what makes
    it 0/1 rather than unbounded: iterating downward means best[c - w] has not
    yet been updated for the current item, so it still refers to a solution
    WITHOUT this item. Iterate upward and you silently allow reuse.
    """
    best = [0] * (capacity + 1)
    for w, v in zip(weights, values):
        for c in range(capacity, w - 1, -1):       # backward
            best[c] = max(best[c], best[c - w] + v)
    return best[capacity]


def knapsack_01_with_items(weights, values, capacity):
    """The 2D table version, kept because reconstructing WHICH items were chosen
    needs the full table. The 1D version above throws that history away."""
    n = len(weights)
    table = [[0] * (capacity + 1) for _ in range(n + 1)]
    for i in range(1, n + 1):
        w, v = weights[i - 1], values[i - 1]
        for c in range(capacity + 1):
            table[i][c] = table[i - 1][c]                    # skip item i
            if w <= c and table[i - 1][c - w] + v > table[i][c]:
                table[i][c] = table[i - 1][c - w] + v        # take item i
    chosen, c = [], capacity
    for i in range(n, 0, -1):
        if table[i][c] != table[i - 1][c]:                   # item i was taken
            chosen.append(i - 1)
            c -= weights[i - 1]
    return table[n][capacity], sorted(chosen)


# --- LIS: two algorithms, and the second is not a DP at all ------------------
def lis_quadratic(nums):
    """state: length[i] = length of the longest increasing subsequence ENDING at
    index i. The "ending at i" is what makes the recurrence work; "within the
    first i" does not, because it loses the information needed to extend."""
    if not nums:
        return 0, []
    length = [1] * len(nums)
    prev = [-1] * len(nums)
    for i in range(len(nums)):
        for j in range(i):
            if nums[j] < nums[i] and length[j] + 1 > length[i]:
                length[i], prev[i] = length[j] + 1, j
    best = max(range(len(nums)), key=lambda i: length[i])
    seq, k = [], best
    while k != -1:
        seq.append(nums[k])
        k = prev[k]
    return length[best], seq[::-1]


def lis_nlogn(nums):
    """O(n log n) via patience sorting. tails[k] is the SMALLEST possible tail
    of an increasing subsequence of length k+1. That array is sorted by
    construction, so binary search places each element.

    Note what this returns and does not: the LENGTH is correct, but `tails`
    itself is generally NOT a valid subsequence of the input. Reconstructing the
    actual sequence needs a parent array, as in the quadratic version.
    """
    tails = []
    for n in nums:
        i = bisect.bisect_left(tails, n)     # bisect_left: strictly increasing
        if i == len(tails):
            tails.append(n)
        else:
            tails[i] = n
    return len(tails), tails


# --- 2D: edit distance -------------------------------------------------------
def edit_distance(a, b):
    """state: d[i][j] = edits to turn a[:i] into b[:j].
    recurrence: if the last characters match, d[i][j] = d[i-1][j-1] (free).
    Otherwise 1 + min(delete a[i-1], insert b[j-1], substitute).

    The base row and column are not zeros: turning "" into b[:j] takes j
    insertions, so d[0][j] = j. Filling them with zeros is the most common bug.
    """
    m, n = len(a), len(b)
    d = [[0] * (n + 1) for _ in range(m + 1)]
    for i in range(m + 1):
        d[i][0] = i
    for j in range(n + 1):
        d[0][j] = j
    for i in range(1, m + 1):
        for j in range(1, n + 1):
            if a[i - 1] == b[j - 1]:
                d[i][j] = d[i - 1][j - 1]
            else:
                d[i][j] = 1 + min(d[i - 1][j],      # delete from a
                                  d[i][j - 1],      # insert into a
                                  d[i - 1][j - 1])  # substitute
    return d[m][n], d


def edit_ops(a, b, d):
    """Walk the table backwards to recover the actual edit script. Same idea as
    the knapsack reconstruction: the table holds the history, so read it."""
    ops, i, j = [], len(a), len(b)
    while i > 0 or j > 0:
        if i > 0 and j > 0 and a[i - 1] == b[j - 1] and d[i][j] == d[i - 1][j - 1]:
            i, j = i - 1, j - 1
        elif i > 0 and j > 0 and d[i][j] == d[i - 1][j - 1] + 1:
            ops.append(f"sub {a[i-1]}->{b[j-1]} at {i-1}")
            i, j = i - 1, j - 1
        elif i > 0 and d[i][j] == d[i - 1][j] + 1:
            ops.append(f"del {a[i-1]} at {i-1}")
            i -= 1
        else:
            ops.append(f"ins {b[j-1]} at {i}")
            j -= 1
    return ops[::-1]


# --- memoised recursion: the same DP, discovered rather than designed --------
def grid_paths(rows, cols, blocked=()):
    """Top-down is often the easier way to FIND the recurrence, because you write
    the question, not the fill order. Convert to bottom-up only if you need the
    space saving or Python's recursion limit is a problem."""
    blocked = set(blocked)

    @lru_cache(maxsize=None)
    def ways(r, c):
        if r >= rows or c >= cols or (r, c) in blocked:
            return 0
        if (r, c) == (rows - 1, cols - 1):
            return 1
        return ways(r + 1, c) + ways(r, c + 1)

    n = ways(0, 0)
    return n, ways.cache_info()


if __name__ == "__main__":
    houses = [2, 7, 9, 3, 1]
    # 7 and 9 are adjacent, so the greedy "take the two biggest" is illegal here.
    print("house_robber", houses, "->", house_robber(houses), "(2+9+1; 7+9 is adjacent)")
    print("coin_change([1,5,6,9], 11) ->", coin_change([1, 5, 6, 9], 11), "(5+6, greedy would say 9+1+1)")
    print("coin_change([2], 3)        ->", coin_change([2], 3), "(impossible)")

    print()
    w, v, cap = [3, 4, 5, 9], [4, 5, 6, 10], 12
    print("weights", w, "values", v, "capacity", cap)
    print("knapsack_01 (1D)      ->", knapsack_01(w, v, cap))
    total, items = knapsack_01_with_items(w, v, cap)
    print("knapsack_01 (2D)      ->", total, "using item indices", items,
          "weights", [w[i] for i in items])

    print()
    seq = [10, 9, 2, 5, 3, 7, 101, 18]
    n1, actual = lis_quadratic(seq)
    n2, tails = lis_nlogn(seq)
    print("sequence              :", seq)
    print("lis_quadratic         :", n1, actual)
    print("lis_nlogn             :", n2, "tails =", tails, "<- length is right, tails is not the subsequence")

    print()
    a, b = "intention", "execution"
    dist, table = edit_distance(a, b)
    print(f"edit_distance({a!r}, {b!r}) = {dist}")
    for op in edit_ops(a, b, table):
        print("   ", op)
    print("edit_distance('', 'abc') =", edit_distance("", "abc")[0])

    print()
    n, info = grid_paths(3, 4)
    print("grid_paths(3,4)       :", n, "paths;", info)
    n, info = grid_paths(3, 4, blocked=[(1, 1)])
    print("with (1,1) blocked    :", n, "paths;", info)

Five details, each of which is a question you will be asked.

The loop direction in knapsack_01 is the entire difference between 0/1 and unbounded. Both versions are the same three lines; one iterates capacity backward and one forward. Going backward, best[c - w] has not yet been touched for the current item, so it refers to a solution that does not include the item, which is what "use each item at most once" means. Going forward, best[c - w] may already include the current item, so the item gets reused, which is exactly the unbounded knapsack that coin_change wants. A one-character change to a range silently changes the problem being solved, and being able to say why out loud is one of the strongest signals available on this topic.

The base row and column of the edit distance table are not zeros. d[i][0] = i because turning a prefix of length $i$ into the empty string takes $i$ deletions, and d[0][j] = j symmetrically. Filling them with zeros is the most common edit-distance bug, and it produces answers that are too small in a way that looks plausible on short inputs.

lis_quadratic defines the state as "ending at index i", not "within the first i". This is the state-definition point made concrete. "Longest increasing subsequence within the first $i$ elements" is not enough information to extend, because you do not know what value the best subsequence ended on. "Ending at $i$" carries that, so the recurrence works, and the final answer is a max over all $i$ rather than the last cell. When a DP will not close, this is usually the fix: add to the state whatever the recurrence needs to know.

lis_nlogn is not a DP. It maintains tails[k], the smallest possible tail of any increasing subsequence of length $k+1$. That array is sorted by construction, so each new element is placed by binary search, giving $O(n \log n)$. It is the binary search pattern wearing a DP costume, and it is the standard follow-up once you produce the quadratic version.

grid_paths uses lru_cache and reports the cache statistics, which is the cheapest possible demonstration that memoisation is doing something. 17 misses and 6 hits on a 3 by 4 grid means 6 recursive calls returned without recomputing a subtree.

Worked example

house_robber [2, 7, 9, 3, 1] -> 12 (2+9+1; 7+9 is adjacent)
coin_change([1,5,6,9], 11) -> 2 (5+6, greedy would say 9+1+1)
coin_change([2], 3)        -> -1 (impossible)

weights [3, 4, 5, 9] values [4, 5, 6, 10] capacity 12
knapsack_01 (1D)      -> 15
knapsack_01 (2D)      -> 15 using item indices [0, 1, 2] weights [3, 4, 5]

sequence              : [10, 9, 2, 5, 3, 7, 101, 18]
lis_quadratic         : 4 [2, 5, 7, 101]
lis_nlogn             : 4 tails = [2, 3, 7, 18] <- length is right, tails is not the subsequence

edit_distance('intention', 'execution') = 5
    sub i->e at 0
    sub n->x at 1
    sub t->e at 2
    sub e->c at 3
    sub n->u at 4
edit_distance('', 'abc') = 3

grid_paths(3,4)       : 10 paths; CacheInfo(hits=6, misses=17, maxsize=None, currsize=17)
with (1,1) blocked    : 4 paths; CacheInfo(hits=4, misses=17, maxsize=None, currsize=17)

The LIS output is the most instructive line on this page. Both algorithms report length 4 and they agree, as they must. But the quadratic version returns the actual subsequence [2, 5, 7, 101], while tails from the fast version is [2, 3, 7, 18], which is not a subsequence of the input in that order at all: 3 appears before 5 in the input but after 2, and 18 appears after 101. The tails array is a set of best-possible endings, not a path. Candidates who return tails as "the LIS" are wrong and their answer looks right, because the length is right. If the problem asks for the sequence and not just its length, either use the quadratic version or add a parent array to the fast one, and say which you are doing.

Check the knapsack by hand. Weights [3,4,5,9], values [4,5,6,10], capacity 12. Items 0, 1 and 2 weigh exactly 12 and are worth $4+5+6 = 15$. The tempting alternative is item 3 (weight 9, value 10) plus item 0 (weight 3, value 4), also exactly 12, worth 14. So 15 is right and the greedy "best value per unit weight" heuristic would have picked item 0 first (ratio 1.33) and could plausibly land on the wrong answer. This is the input that shows the fractional-knapsack greedy does not carry over to 0/1.

grid_paths(3,4) is 10, which is $\binom{5}{2}$ as the closed form predicts, and blocking the single cell $(1,1)$ drops it to 4. The check: paths through $(1,1)$ number $\binom{2}{1} \times \binom{3}{1} = 2 \times 3 = 6$, and $10 - 6 = 4$. Having a closed form to check the DP against is a gift when it exists, and constructing one for the unobstructed case is a good way to validate an implementation before adding the obstacles that make the closed form impossible.

The edit script for intention to execution is five substitutions, which is worth inspecting because the textbook presentation of this exact pair usually shows a delete, three substitutions and an insert. Both are five operations, so both are optimal; the table has multiple optimal paths and the reconstruction picks whichever branch it tests first. If an interviewer's expected output differs from yours on a reconstruction problem, check whether both are optimal before assuming you are wrong.

Production evidence

Query planners use DP for join ordering. The System R optimiser introduced dynamic programming over subsets of relations: compute the best plan for every subset of tables, building up by size, because the best plan for a set of tables can be assembled from the best plans of its subsets. PostgreSQL still does this for queries below geqo_threshold (12 relations by default) and switches to a genetic algorithm above it, because the DP is $O(3^n)$ in the number of relations and stops being affordable. That threshold is a working example of a team choosing where exact DP stops paying.

The Viterbi algorithm is a DP over hidden state sequences, and it decodes convolutional codes in mobile and satellite communications, does part-of-speech tagging, and underpinned speech recognition for decades. The state is "most likely path ending in this state at this time", which is exactly the "ending at $i$" formulation used in lis_quadratic.

diff is an edit distance variant. Myers' algorithm, which is what Git uses by default, computes the shortest edit script between two sequences of lines. It is a refinement of the edit distance DP that searches the table diagonally and runs in $O(ND)$ where $D$ is the size of the edit script, which is fast in the common case where two file versions are mostly the same.

Sequence alignment in bioinformatics. Needleman-Wunsch (global alignment) and Smith-Waterman (local alignment) are the edit distance DP with a substitution scoring matrix and gap penalties instead of a flat cost of 1. Smith-Waterman is exact and is usually too slow for large database searches, which is why BLAST exists as a heuristic approximation. That pairing (exact DP, then a heuristic when the DP does not scale) is the same shape as the Postgres threshold above.

Levenshtein automata in Lucene. Lucene's fuzzy query builds an automaton accepting all strings within a given edit distance of the query and intersects it with the term dictionary's finite state transducer, rather than computing edit distance against every term. It is the trie-plus-pruning approach from the previous page, and it is the reason fuzzy search over millions of terms is affordable.

The debate

Top-down or bottom-up? Write top-down first. The reason is not preference: top-down lets you write the recurrence as a question, without deciding the fill order, and deciding the fill order is where people get stuck. @lru_cache on a clean recursive function is a correct DP in one line. Convert to bottom-up when you need the space reduction (the rolling array in house_robber and knapsack_01 is only possible bottom-up), when recursion depth is a real risk (Python defaults to 1,000 frames, and a 10,000-element 1D DP will hit it), or when the constant factor matters. State the conversion as a deliberate step, not as a correction.

Is the $O(n \log n)$ LIS worth writing in an interview? Only if asked, or if the stated constraints demand it. The quadratic version is six lines, obviously correct, and returns the actual subsequence; the fast version is four lines but is easy to get subtly wrong (bisect_left gives strictly increasing, bisect_right gives non-decreasing, and choosing wrong is a silent off by one) and does not give you the sequence. My position: write the quadratic version, state that an $O(n \log n)$ patience-sorting version exists and what its invariant is, and implement it if they want it. Volunteering the existence of the better algorithm gets most of the credit at a fraction of the risk.

When is DP the wrong tool? Three cases. First, when a greedy is provably correct, in which case DP is slower and more code, and the proof obligation is on you either way. Second, when the state space is too large: knapsack's $O(nW)$ is pseudo-polynomial, polynomial in the numeric value of $W$ rather than in the bits used to write it, so a capacity of $10^9$ makes the table impossible even with only 20 items. In that regime you want meet-in-the-middle, branch and bound, or an approximation scheme, and knowing that "pseudo-polynomial" is the reason is a real distinction. Third, when the problem lacks optimal substructure, in which case DP produces confident wrong answers, which is worse than being slow.

Follow-up Q&A

Is the knapsack DP polynomial or not? The complexity is $O(nW)$, which looks polynomial. It is pseudo-polynomial. The input size is $O(n \log W)$ bits, because $W$ is written in binary, so $O(nW)$ is exponential in the input length. 0/1 knapsack is NP-complete, and the DP does not contradict that. This is the crispest available test of whether a candidate understands complexity as a function of input size rather than of the numbers in the input, and it is asked often.

How do you reduce a 2D DP's space to $O(n)$? If the recurrence for row $i$ only reads row $i-1$, keep two rows and swap, or one row updated in the correct direction as knapsack_01 does. The cost is that you lose the ability to reconstruct the solution path, which is why knapsack_01_with_items keeps the full table. If you need both minimal space and the path, the technique is Hirschberg's divide-and-conquer, which computes the alignment in $O(\min(m,n))$ space at the cost of doubling the time. Naming Hirschberg here is a strong signal because most people know only the two extremes.

Why does the greedy fail for coin_change with [1,5,6,9] but work for real money? Because a coin system is canonical when greedy is optimal for every amount, and real currency denominations are deliberately designed that way. ${1,5,6,9}$ is not canonical: at 11, greedy takes 9 then needs two 1s for a total of 3, while $5+6$ is 2. There is a known test (Pearson's algorithm) for deciding whether a given coin system is canonical, and it runs in polynomial time. The interview-relevant point: you cannot tell by inspection, so do not assert greedy without a proof or a stated assumption.

Your edit_distance treats insert, delete and substitute as cost 1 each. What if they differ? Change the constants in the min, and the algorithm is otherwise unchanged. This generalises to a full substitution matrix, which is exactly Needleman-Wunsch. One subtlety worth knowing: if a substitution costs more than a delete plus an insert, the substitution branch is never chosen and the metric silently changes character. Also, the Damerau variant adds transposition as a fourth operation, which needs one more term reading d[i-2][j-2], and it matters for typo correction because adjacent-character transposition is one of the most common human typing errors.

When would you memoise on a tuple that includes something other than indices? Whenever the recurrence's answer depends on it. A common example is "at most $k$ transactions" stock problems, where the state is (day, transactions_left, holding). The discipline: write down every variable the recursive call reads, and that set is your state. If the state includes something you did not put in the cache key, the memoisation is wrong and returns stale answers, which is a bug that produces plausible numbers rather than a crash.

How do you approach a DP problem you have never seen, live? In this order. One, solve a tiny instance by hand. Two, write the brute-force recursion, however slow. Three, ask what the recursive call actually depends on, and make that the cache key. Four, add @lru_cache and check the answer is unchanged. Five, only if needed, convert to a table and reduce space. Narrating those five steps is itself the answer to "how do you think about DP", and it is more convincing than producing a memorised recurrence.

Common misconceptions

"Dynamic programming means filling a table." It means solving each subproblem once. The table is one implementation. Memoised recursion is DP; so is an iterative rolling variable.

"The state is always the index." It is whatever the recurrence reads. Multi-dimensional states are normal, and the reason a problem seems impossible is usually a missing dimension.

"If it has optimal substructure, greedy will work." Optimal substructure is necessary for both greedy and DP but sufficient for neither. Greedy additionally needs the greedy choice property: a locally optimal choice is part of some globally optimal solution. 0/1 knapsack has optimal substructure and fails the greedy choice property, which is precisely why it needs DP while fractional knapsack does not.

"$O(nW)$ for knapsack means it is efficient." Pseudo-polynomial, as above. The gap between the two is a genuine complexity-theory distinction and it has practical consequences.

"lru_cache makes any recursion fast." Only if states repeat. On a recursion whose arguments are never equal, it adds hashing overhead and unbounded memory growth and helps nothing. Also note maxsize=None never evicts, so on a large state space it is a memory leak in a long-running process.

Interview delivery note

Say the state definition as a full English sentence before you write anything: "Let best[c] be the maximum value achievable with capacity exactly c using the items I have considered so far." Then the recurrence, then the base case, then the fill order. Four sentences, thirty seconds, and they make the rest of the problem mechanical. Candidates who start writing loops before stating the state are the ones who get stuck, and interviewers can see it happening.

The senior-to-staff separator on DP is knowing where the DP stops being the right answer and saying so. A senior candidate produces a correct $O(nW)$ knapsack. A staff candidate produces the same code and then says, unprompted: "Note this is pseudo-polynomial. It is $O(nW)$ in the value of the capacity, so with 30 items and a capacity of a billion this table does not exist and I would go to meet-in-the-middle or branch and bound. The threshold is not theoretical: Postgres does exactly this, using DP join ordering under 12 relations and a genetic algorithm above it." That answer demonstrates the thing DP questions are actually probing, which is whether you understand the cost model well enough to know when to abandon your own solution.

Further reading

• Cormen, Leiserson, Rivest and Stein. Introduction to Algorithms, 4th ed. Chapter 14 (Dynamic Programming), including the optimal substructure and greedy-choice discussion.
• P. Griffiths Selinger et al. "Access Path Selection in a Relational Database Management System." SIGMOD 1979. The DP join-ordering algorithm every planner still descends from.
• Eugene W. Myers. "An O(ND) Difference Algorithm and Its Variations." Algorithmica, 1986. The algorithm behind git diff.
• Dan Hirschberg. "A linear space algorithm for computing maximal common subsequences." Communications of the ACM, 1975. Reconstruction without the full table.

Lead essentials: the summary, the research and the vocabulary

This chapter is the compression of the rest of the book for someone interviewing for a team lead or tech lead role, plus two things the other chapters assume rather than teach.

The summary is what actually matters out of 280 pages, weighted by return per hour of preparation, organised around one distinction: a senior engineer optimises the artifact, and a lead optimises the system that produces artifacts. Answering lead questions with IC answers is the most reliable way to fail a TL loop, and the fix is usually reframing work you have already done rather than learning anything new.

The research is the small set of studies and named effects that convert an opinion into an argument. Goodhart's law, Project Oxygen, Project Aristotle, psychological safety, Westrum, DORA, normalization of deviance, Conway, Brooks, and a handful of named effects worth having ready. Each entry says what the study actually found, which in several cases is not what it is popularly claimed to have found, and the gap is a fast way to show you read the source.

The vocabulary is three pages on the terms that raise the register of everything else you say: the language of decisions and risk, of systems and failure, and of organisations and delivery. They are taught as families rather than as a glossary, because they form a system, and each entry includes how it misfires, because a term used loosely is detectable in one follow-up question.

There is also a page on speaking in numbers, with runnable Monte Carlo code, because the single most common lead question is a date question and the standard answers to it are all bad. Its headline result: summing the most-likely estimates for a six-task project produced a plan sitting at the first percentile of the real distribution.

The condensed lookup, including the full term table and answers to the questions that come up in nearly every loop, is the team lead cheat sheet.

What this chapter covers

• [done] The team lead summary: what actually matters
• [done] The research a lead should be able to cite
• [done] Speaking in numbers: p90 and Monte Carlo
• [done] The vocabulary of decisions and risk
• [done] The vocabulary of systems, failure and design
• [done] The vocabulary of organisations and delivery

Source: §2, §3, §13, §26, and the cross-cutting leadership material.

The team lead summary: what actually matters

What it is

This book has 280 pages. A team lead interviewing in the next month cannot read them all, and more importantly should not, because the loop does not test coverage. It tests whether you have a model of how engineering organisations produce working software, and whether you can apply it to a situation you have not seen. This page is the compression: the essential points, the topics that carry the most weight per hour of preparation, and the handful of positions worth holding before you walk in.

The distinction that organises everything below is between an individual contributor's model and a lead's model of the same system. A senior engineer optimises the artifact: the code, the design, the query plan. A lead optimises the system that produces artifacts: the queues, the feedback loops, the decision rights, the constraint. They use overlapping vocabulary and mean different things by it, and the single most reliable way to fail a TL loop is to answer lead questions with IC answers.

Don't be confused: "team lead" and "engineering manager" are not the same role, and the interview differs. A TL or tech lead is usually accountable for technical direction and delivery without formal people management: no headcount, no performance ratings, no hiring authority over the team. An EM has those and often less technical depth expected. The overlap is delivery, unblocking and communication; the divergence is that a TL leads through influence and technical credibility while an EM also leads through positional authority. If you prepare EM answers ("I would put them on a PIP") for a TL loop, you will sound like you are describing someone else's job. Ask which one the role is. Many companies use "tech lead" for a role that is really an EM, and vice versa.

The problem it solves

The interview problem: you have limited hours and the material is unbounded. The working problem behind it: new leads systematically over-invest in the technical decisions, which are visible and comfortable, and under-invest in the mechanisms, which are invisible and are what actually determine whether the team ships. The compression below is weighted toward the second category on purpose.

Mechanics

The seven things that carry the most weight

1. Delivery is a queueing problem before it is a skill problem. When a team is slow, the instinct is to look at the engineers. Look at the queues first: how long does a PR wait for review, how long does a change wait for a deploy window, how many things are in flight per person. Queue time dominates work time in most struggling teams, and queue time responds to policy (WIP limits, review rotation, deploy frequency) rather than to effort. This is the single highest-leverage reframe available to a new lead, and it converts a conversation about people into a conversation about a system, which is both more effective and more comfortable for everyone in the room. See Little's Law; the arithmetic is the same for a team as for a thread pool.

2. You get what you measure, so measure the outcome and guard the rest. Any metric that becomes a target stops measuring what it measured. The defence is not to abandon metrics; it is to pair every target metric with a counter-metric that catches the obvious gaming, and to prefer outcome metrics over activity metrics. This is Goodhart's law and it is covered properly in Research that holds up.

3. Decide by reversibility, not by importance. The cost of a decision is not its size, it is how expensive it is to undo. A one-way door deserves analysis, a written argument and several people; a two-way door deserves a decision today by whoever is closest. Teams routinely apply the one-way-door process to two-way-door decisions, which reads as rigour and is actually the most common source of organisational drag. Say which kind a decision is before you say what you think it should be.

4. Mechanisms beat intentions. "We will be more careful" is not a fix. A mechanism is a repeatable process that produces the outcome whether or not anyone remembers to care: a check in CI, a rotation, a required field, a recurring review with a named owner and a written output. When an interviewer asks how you would prevent a recurrence, they are listening for a mechanism, and "we discussed it in retro" is the answer that fails.

5. Cognitive load is a design constraint with a budget. A team can hold a bounded amount of system in its head. Every additional datastore, language, deployment target and on-call surface spends that budget, and the spend is permanent while the benefit is often one-time. This is why "we could use Kafka here" is a question about the team, not about Kafka, and why the strongest answer to a technology proposal is frequently "what would we remove".

6. Your job is to make the important work possible, not to do it. The concrete forms: unblocking (the four blocker types), setting the paved road so the easy path is the correct path, absorbing coordination cost so engineers do not have to, and being the person who says what everyone knows but no one has said. A lead who is on the critical path of the code is a lead who has made themselves a single point of failure.

7. Write things down. Written decisions with the reasoning attached are how a team stays consistent across time and people. The specific claim worth making in an interview: a design doc is not documentation, it is a decision-forcing device, and its value is mostly extracted before it is finished, in the arguments it surfaces.

The topics worth the most preparation hours

If you have twelve hours, spend them roughly like this. Four on your own stories, because every behavioural answer comes from the same small set and a thin portfolio is the most common failure. Two on incident and reliability reasoning, because it is asked in nearly every loop and rewards structure. Two on the delivery-system reframe above, which is what separates a lead answer from a senior one. Two on one technical area you own deeply, because credibility is a prerequisite and depth in one place buys more than breadth in five. One on the vocabulary, covered in the three language pages of this chapter, which raises the register of everything else you say. One on your questions for them, which are scored and which most candidates waste.

Worked example

A concrete compression of the lead reframe, on the most common opening question in a TL loop, "tell me about a time you improved how a team worked".

The IC-shaped answer: "The team was slow to ship, so I refactored the test suite and got CI from 40 minutes to 8." Real work, real result, and it describes something a strong senior does. It answers the question "are you technically capable", which was not asked.

The lead-shaped answer, same event: "The team was shipping about one change a week and it felt like a quality problem, so I measured instead of guessing. Cycle time was 6 days, of which 4.5 was waiting: 2.5 days waiting for review and 2 days waiting for the weekly deploy window. Actual work was under a day. So the constraint was queueing, not engineering. I did three things: a review rotation with a same-day expectation, a WIP limit of two so people finished before starting, and I took the CI suite from 40 minutes to 8 because the deploy window existed to batch a slow pipeline. Cycle time went to 1.5 days over about six weeks and we moved to deploying on merge. The counter-metric I watched was change failure rate, which stayed flat, because the obvious failure mode of 'ship faster' is shipping worse."

The same person, the same work, and the second answer scores at a different level. What changed: it starts from a measurement rather than a feeling, it names the constraint, it distinguishes queue time from work time, the technical fix is subordinate to the system fix and is justified by it, there is a mechanism rather than an intention, there is a counter-metric, and there is a number at the end. That is the whole difference, and it is almost entirely a matter of framing work you have already done.

Production evidence

The reframe in the worked example is not a rhetorical trick; it is the finding of the largest public dataset on the subject. The DORA research programme, over more than a decade and tens of thousands of respondents, found that delivery throughput and stability move together rather than trading off, and that the practices predicting both are technical and procedural (trunk-based development, deployment automation, small batches, fast feedback) rather than attributes of the people. That is the empirical basis for "it is a system problem, not a people problem", and being able to attribute it rather than assert it is what makes it persuasive in a room.

Google's Project Aristotle found the same thing at the team level: what predicted team effectiveness was not who was on the team but how the team operated, with psychological safety the strongest single factor. Project Oxygen found that the behaviours of effective managers were learnable and coachable rather than innate. Both are covered in detail on the research page, and both point the same direction, which is why the direction is worth trusting.

The debate

Is the lead reframe ever wrong? Yes, and being able to say when is what stops it from being a slogan. It is wrong when the constraint genuinely is capability: a team with no one who understands the system it owns will not be fixed by a WIP limit, and pretending otherwise wastes a quarter. It is also wrong when the problem is a single individual whose behaviour is degrading everyone else's work, where a systems answer reads as conflict avoidance and is experienced by the team as abandonment. My position: start with the system because that is where the leverage usually is and because it is falsifiable, but put a time bound on it. If you have fixed the queues and the throughput has not moved, the diagnosis was wrong and you should say so out loud rather than adding another process.

Should a team lead still write code? The honest answer is that it depends on team size and that the variables are known, so commit to them. Under about five engineers, a lead who does not write code loses technical credibility and has too little else to do. Above about eight, a lead on the critical path becomes a bottleneck, because their coding time is the first thing sacrificed to interrupts and their unfinished work blocks others. The rule I would state: write code that is off the critical path. Prototypes, tooling, the unglamorous refactor no one has time for, the second reviewer on hard changes. That keeps the credibility and the context without making the team's delivery depend on your calendar.

Metrics for individuals: useful or corrosive? Corrosive, with one exception. Individual output metrics (commits, PRs, story points) are gamed within a sprint of introduction, they misattribute collaborative work, and they punish exactly the glue work that holds teams together. The exception is using them privately as a signal to go look, never as a judgement: a sharp change in someone's pattern is a reason to have a conversation, not a finding. State this clearly if asked, because "I would build a dashboard of individual productivity" is a genuinely disqualifying answer at this level and some interviewers ask precisely to see whether you will.

Follow-up Q&A

What is the first thing you do in a new lead role? Listen on a schedule, not indefinitely. Concretely: one-to-ones with everyone in the first two weeks with the same three questions (what should we keep, what is in your way, what would you change if you could change one thing), read the last three months of incidents and the last quarter of retros, and find the one thing that is obviously broken and that you can fix quickly without permission. The early win matters less for the fix than for the evidence that reporting a problem to you results in the problem changing, which is what determines whether people tell you anything in month three. Give yourself a deadline for the listening phase, because an indefinite one reads as indecision.

How do you handle a technical decision where you disagree with the team's consensus? Say your position with its reasoning, ask what would change your mind, and ask what evidence would change theirs. If it is a two-way door, go with the team even when you disagree, because the cost of being wrong is small and the value of the team owning the decision is large. If it is a one-way door, you may need to overrule, and if you do, say explicitly that you are overruling and why, rather than continuing to argue until people give up. The failure mode to avoid is winning by persistence, which is what "I kept pushing until they agreed" is, and which costs you the thing you actually need, which is people telling you when you are wrong.

A senior engineer on your team is unhappy about the direction and is disengaging. What do you do? Find out which of the three it is before acting, because the responses are different. Disagreement with the direction: reopen the decision honestly if it is reopenable, and if it is not, say so and ask them to disagree and commit, which is a legitimate thing to ask once. Loss of growth: the work has become routine and the fix is scope, not conversation. Or something outside work entirely, in which case the answer is flexibility and patience, not a development plan. Diagnosing the wrong one costs you the person, and the diagnosis comes from asking directly rather than inferring.

How do you say no to a product partner? Not with "no", and not with "yes but". With options and their costs: "We can have A by the date, or A and B three weeks later, or A and B by the date if we drop the migration, which moves the compliance risk into Q3. I would recommend the first. Which do you want?" That converts a conflict about capacity into a decision about priorities, which is their decision to make, and it is the single most reusable move in the product relationship. The failure mode is presenting a verdict rather than options, which makes engineering the department of no.

What do you do when you inherit a system you do not understand and an incident starts? Say that you do not understand it, and route rather than lead. In an incident the worst outcome is an ambiguous commander, so appoint the person who does understand it as incident lead, and take the jobs that do not require system knowledge and that they should not be doing: communications, timeline, keeping people out of the channel, deciding when to escalate. That is a genuinely strong lead answer and candidates avoid it because it feels like admitting weakness, when it actually demonstrates the thing being tested, which is knowing what the role is.

How do you know your team is healthy, without a survey? Four observable signals, none of which require asking. Do people disagree with each other in writing where you can see it, and do junior people disagree with senior ones. Does bad news reach you early and unprompted, or do you find out when it is unfixable. When someone is out, does their work continue. And does the team change things without asking you. The absence of visible disagreement is the strongest negative signal, and it is usually misread as harmony.

Common misconceptions

"Leading means being the best engineer on the team." It means being the reason the team's engineering is good, which is a different job and is frequently better served by someone who is not the strongest individual contributor. If you are the best engineer on your team and it stays that way for a year, you have a hiring or growing problem.

"Process is bureaucracy." Process is compressed judgement. A team with no process makes every decision from scratch and the cost lands on whoever is newest. The real question is never whether to have process but whether each piece is paying for itself, and the useful discipline is to attach a removal condition to a process when you introduce one.

"A good lead protects the team from the organisation." Partly. Absorbing thrash is real work. But a team fully insulated from organisational context cannot make good local decisions, because it does not know what the company is trying to do, and it becomes fragile the moment you leave. Filter, do not block: pass on the reasoning, absorb the noise.

"I should have an answer for everything." The highest-scoring sentence available in a lead interview is often "I do not know, here is how I would find out". What is being tested is whether you can operate under uncertainty without either freezing or bluffing, and confident wrongness is the failure mode interviewers are most alert to, because they have all worked with it.

Interview delivery note

The move that upgrades most lead answers is a single sentence at the front: "Let me separate the technical problem from the system problem, because I think the interesting one here is the second." It signals the altitude you are operating at before you say anything else, and it gives you permission to talk about queues, ownership and mechanisms rather than only architecture.

The senior-to-staff-and-lead separator across every question on this page is whether your answer generalises past the incident. A senior answer fixes the thing. A lead answer fixes the thing, and then names the class of thing, and then changes something so the class stops recurring: "the immediate fix was the index, the class is that we have no way to catch a query plan regression before production, and the mechanism is a plan check in CI on the twenty queries that matter." Same story, three levels of altitude, and interviewers are explicitly listening for the third.

Further reading

• Nicole Forsgren, Jez Humble and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018. The research design behind DORA, which is the part worth reading, since the findings are widely quoted and the methodology is what makes them credible.
• Matthew Skelton and Manuel Pais. Team Topologies. IT Revolution, 2019. Cognitive load as an explicit design constraint on team boundaries.
• Camille Fournier. The Manager's Path. O'Reilly, 2017. The tech lead chapter is the most accurate published description of the role this page is about.
• Will Larson. An Elegant Puzzle: Systems of Engineering Management. Stripe Press, 2019. The systems-thinking framing of team problems, including the queueing view of delivery.

The research a lead should be able to cite

What it is

A small set of studies and named effects that do real work in a leadership conversation, because they convert an opinion into a finding. "I think we should pair the target metric with a counter-metric" is a preference. "Goodhart's law says the metric will stop measuring what it measured the moment it becomes a target, so I want a counter-metric" is an argument, and the second one survives contact with a director who disagrees.

The other reason to know them precisely is that most of them are misquoted in a specific, consistent way, and knowing the actual finding is a fast and non-obnoxious way to demonstrate that you have read the source rather than the summary. Each entry below states what the study found and, where it differs, what people claim it found.

Don't be confused: citing research is not the same as deferring to it. The failure mode is using a study as an authority that ends discussion ("Aristotle says psychological safety, so we are doing psychological safety"), which is both bad reasoning and unpersuasive. Use the finding to name a mechanism, then argue about your specific situation. The study tells you what generally predicts what; it does not tell you what is true of your team, and the person across the table knows that.

The problem it solves

Leadership arguments are usually decided by seniority, volume or persistence, because nobody has anything better. Having a small stock of well-understood evidence changes what the argument is about: instead of two opinions about whether individual productivity dashboards work, you have a named, decades-old result about what happens to any metric under target pressure, and the burden shifts to the person who wants to build the dashboard anyway.

In an interview it does a narrower job. It signals that your views came from somewhere, which is the difference between a candidate with opinions and a candidate with a model.

Mechanics

Goodhart's law, and its sharper cousin

What it says. Charles Goodhart, writing about UK monetary policy in 1975: any observed statistical regularity will collapse once pressure is placed on it for control purposes. Marilyn Strathern's 1997 restatement is the one everyone quotes: "When a measure becomes a target, it ceases to be a good measure."

Why it is true rather than merely cynical is the part worth being able to explain. A metric is a proxy: it correlates with the thing you care about across the range of behaviours people were exhibiting when you measured the correlation. Making it a target expands the behaviour space to include actions taken because of the target, and those actions were not in the sample the correlation came from. The correlation is not being broken by dishonesty; it is being broken by optimisation. That is why it happens even with people acting in complete good faith, which is the misconception to head off: Goodhart is not a claim about gaming, it is a claim about correlations under selection pressure.

Campbell's law (Donald Campbell, 1979) is the social-science version and is sharper for organisational use: the more a quantitative indicator is used for social decision-making, the more it will be subject to corruption pressures, and the more it will distort the processes it was meant to monitor. Note the second clause, which Goodhart's formulation lacks: the measurement damages the activity, not just the measurement. Measuring code review turnaround does not merely produce a useless number; it produces worse reviews.

The practical consequence, and what to say in an interview: never gate on a single metric. Pair the target with a counter-metric chosen specifically to catch the cheapest way to cheat. Deployment frequency pairs with change failure rate. Click-through rate pairs with unsubscribe rate. Review turnaround pairs with defects found in review. If you cannot name the cheapest way to cheat your metric, you are not ready to make it a target.

Google's Project Oxygen: managers matter, and the ranking is the finding

What it was. Google began Project Oxygen in 2008 partly expecting to show that managers did not matter much, which is worth knowing because it is the opposite of a study designed to find its conclusion. The data said otherwise: teams under highly rated managers performed better on turnover, satisfaction and performance. The project then worked backwards to identify what those managers actually did, producing eight behaviours, expanded to ten in 2018.

The finding people miss is the ordering. In the original list, "has key technical skills that help advise the team" ranked last. Being a good coach ranked first. That is not a claim that technical skill is unimportant, and misreading it that way is the standard error: Google was ranking within a population of managers who all had substantial technical skill, so the result says technical depth is a threshold rather than a differentiator. Above the threshold, coaching, empowering without micromanaging and clear communication distinguish people; below it, nothing else helps. That distinction between a threshold variable and a differentiating variable is the useful transferable idea, and it applies well beyond management.

The 2018 additions are also revealing about what changed as Google grew: "collaborates across Google" and "is a strong decision maker". Both are about the boundary of the team rather than its interior, which is the shift that happens to every organisation past a certain size.

Project Aristotle: how the team works beats who is on it

What it was. Google studied around 180 teams from 2012, looking for the composition that predicted effectiveness: seniority mix, personality types, tenure, colocation, whether people socialised outside work. None of it predicted much. What predicted effectiveness was how the team behaved, and five dynamics emerged, with the first far more important than the rest: psychological safety, dependability, structure and clarity, meaning, and impact.

The uncomfortable implication for a lead is that assembling talent is not the job. You can staff a team with excellent engineers and get mediocre output, and the mechanism is observable: in a team without safety, people do not report problems early, do not admit confusion, do not disagree with the loudest person, and do not try things that might fail. Each of those is individually rational and collectively fatal.

Psychological safety is Amy Edmondson's construct, from her 1999 study of hospital teams, and its origin story is the best thing about it. She expected better teams to make fewer errors. The data showed better teams reported more errors. The measurement was of reported errors, and what varied was not the error rate but whether people were willing to say so. That is the single most useful thing to know about the concept, because it tells you what to look for: not the absence of problems but the presence of people mentioning them. A team with no reported incidents is not a safe team, it is an opaque one.

Normalization of deviance: how safe teams drift

What it is. Diane Vaughan's term, from The Challenger Launch Decision (1996). The O-rings on the shuttle boosters had shown erosion on previous flights. Erosion was outside the original design specification, but it had never caused a failure, so over successive flights it was progressively reclassified as an acceptable, expected condition. The launch decision was not made by people knowingly accepting a catastrophic risk. It was made by people whose definition of "acceptable" had migrated, one uneventful flight at a time.

Vaughan's finding is that this is a normal organisational process, not a moral failure, which is what makes it dangerous: every occurrence of the deviation without consequence is evidence, and the evidence genuinely does accumulate in the direction of "this is fine". The engineering translations are everywhere: manual production changes that have never gone wrong, an alert that has been firing for months, a test that everyone knows to re-run, a permission that was temporary in March. The diagnostic question, and it is a good one to ask in an interview: "what are we currently doing that we would not approve if we were proposing it today?"

The counter-mechanism is to make deviation visible and effortful rather than to exhort people to care: a break-glass procedure that pages someone, an exception with an expiry date, an alert that fails loudly rather than degrading. Anything that requires ongoing vigilance will lose to this process, because this process is what vigilance decays into.

Conway's law, and the deliberate inverse

What it says. Melvin Conway, 1968: organisations design systems that mirror their own communication structures. It is an observation about information flow, not a metaphor: two modules can only have a clean interface if the people building them can negotiate one, and the interface will be as good as that conversation.

The lead-relevant version is the inverse manoeuvre, sometimes called the inverse Conway manoeuvre: since architecture will follow team structure anyway, change the team structure to get the architecture you want. This is the intellectual foundation of Team Topologies, and it is the reason "should we split this team" and "should we split this service" are the same question asked twice. When someone proposes a service decomposition that does not match how the teams communicate, Conway's law predicts it will be reabsorbed, and it usually is.

Brooks's law and the second-system effect

What it says. Fred Brooks, The Mythical Man-Month, 1975: adding people to a late software project makes it later. The mechanism matters more than the slogan, because the slogan is false as stated and Brooks knew it. Two costs: new people consume the time of existing people to ramp up, and communication paths grow as $n(n-1)/2$, so the coordination overhead grows quadratically while capacity grows linearly. Adding people helps when work is genuinely partitionable and the ramp-up is short; it hurts when the work is sequential and the context is deep. So the useful form is: adding people to a late project makes it later unless the remaining work partitions cleanly and the new people need little context, which is rarely true late in a project and is exactly why it is late.

The second-system effect, from the same book, is the tendency of an architect's second system to be over-engineered, because they finally get to build everything they had to leave out of the first one. It is the most accurate published description of what a rewrite looks like from the inside, and it is worth naming when a team proposes one.

DORA, Westrum, and what culture predicts

What DORA found, across a decade of surveys and the Accelerate book: four measures (deployment frequency, lead time for changes, change failure rate, time to restore) separate high from low performers, and crucially throughput and stability move together rather than trading off. That result is the empirical refutation of "we ship slowly because we care about quality", and it is worth citing precisely because that sentence is otherwise unanswerable.

Westrum's typology (Ron Westrum, 2004, from safety research in healthcare and aviation) classifies organisations by how information flows: pathological (power-oriented, information is hoarded, messengers are shot), bureaucratic (rule-oriented, information moves through channels, responsibility is narrow), and generative (performance-oriented, information is actively sought, messengers are trained, failure leads to inquiry). DORA found that Westrum-generative culture predicts software delivery performance, which gives you a measured link from culture to output, and the measurement is behavioural rather than attitudinal. The single best diagnostic question from this framework: what happens to the person who brings bad news?

A few named effects worth having ready

Chesterton's fence. Do not remove a fence until you know why it was put there. The reason it is a good principle rather than a conservative one: the argument "I do not see why this exists" is evidence about you, not about the fence. The lead application is to require an explanation before a deletion, and the counter-application is that it is frequently used to defend things nobody can explain, in which case the correct response is a time-boxed investigation, not indefinite preservation.

Hyrum's law. With a sufficient number of users, every observable behaviour of your system will be depended on by somebody, regardless of what the contract says. Named for Hyrum Wright at Google. It is why "that was never part of the API" is a true statement that does not help you, and it is the argument for expand-and-contract migrations over clean breaks.

Gall's law. A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched into working; you have to start over with a working simple system. This is the most compact available argument against big-bang rewrites and for walking skeletons.

Survivorship bias, in its best-documented form: Abraham Wald, working for the Statistical Research Group in the Second World War, was asked where to add armour to bombers based on the distribution of bullet holes in returning aircraft. His answer was to armour the places with no holes, because the sample consisted only of planes that came back, so damage in those areas was evidently survivable. The engineering translations are constant: your latency percentiles exclude the requests that timed out, your user research excludes the users who left, and your postmortems cover the incidents you detected.

The planning fallacy (Kahneman and Tversky, 1979): people underestimate task duration even when they know that similar tasks have historically taken longer, and the effect survives being told about it. The operational counter is reference class forecasting, popularised by Bent Flyvbjerg: instead of estimating this project from its parts, find the distribution of outcomes for similar past projects and place this one in it. In engineering terms, "how long did our last three migrations take" beats any bottom-up estimate, and it is the honest answer to a date question. See the estimation page for what to do with that distribution once you have it.

Parkinson's law of triviality (1957), the origin of "bikeshedding": a committee spends a few minutes approving a nuclear reactor and hours on the design of the bike shed, because everyone can form an opinion about a bike shed. The lead value is diagnostic: the amount of discussion a decision attracts is inversely related to its importance, so a long argument is a signal to check whether the topic deserves it.

Worked example

A concrete case where citing the right result changes an outcome, drawn from the most common version of this conversation.

The situation. A director wants a dashboard of per-engineer PR counts and review turnaround, visible to management, "so we can see who needs support".

The weak objection: "I don't think individual metrics are a good idea." True, and it loses, because it is one opinion against another and the director has more authority.

The stronger version, using three of the results above: "I want the visibility too, and I think this specific design will destroy the thing it measures. Three reasons. Goodhart: the moment PR count is visible to management it stops correlating with output, because people will split PRs, and the split is individually rational so we cannot fix it by telling people not to. Campbell's stronger version says the measurement will also degrade the underlying activity, and here that means review quality, because the fastest way to improve turnaround is to approve without reading. And Aristotle's finding is that psychological safety is the strongest predictor of team effectiveness, so a management-visible individual ranking is a direct tax on the thing that predicts our output. What I think you actually want is to know where work is getting stuck, which is a team-level flow question, so let me give you cycle time broken down by stage, plus review queue depth, which shows exactly the same problem without creating a leaderboard. If a specific person is struggling, that shows up in a one-to-one and I will tell you."

Same position, different outcome, and the difference is that the second version names mechanisms, offers the thing the director actually wanted, and does not require anyone to lose an argument.

Production evidence

The findings above are themselves the production evidence, which is unusual for this book, so the useful thing to add is where they have been adopted rather than merely published. Google turned Project Oxygen into its manager feedback survey and its manager training, and published the behaviour list along with the fact that they revised it in 2018, which is the more credible detail: a framework that gets updated is one somebody is still using. DORA's four metrics have been adopted widely enough to appear as built-in dashboards in GitHub, GitLab and Azure DevOps, which is the strongest available signal that the measures survived contact with practice. Team Topologies' cognitive-load-first team design has been adopted publicly by several large engineering organisations as the basis for platform team charters.

The honest caveat to state if pressed: most of this literature is correlational and survey-based. DORA's data comes from self-selected respondents answering self-reported questions, and its causal claims rest on structural equation modelling rather than experiment. That is a real limitation and naming it before your interviewer does is worth more than the citation itself.

The debate

Is Goodhart's law an argument against measurement? No, and the version of it that gets deployed as one is worth pushing back on. It is an argument against unpaired metrics under target pressure. Metrics used for observation rather than for targets are far less affected, which is why "we measure this but do not target it" is a coherent and useful position. The correct conclusion is to measure more things and target fewer of them, and to be explicit about which is which. The failure I would name in an interview: teams that read Goodhart, concluded that measurement is futile, and now run on anecdote, which is strictly worse.

Does psychological safety mean avoiding conflict? It means the opposite, and this is the most consequential misreading of Aristotle in circulation. Edmondson's construct is the shared belief that the team is safe for interpersonal risk-taking: disagreeing, admitting error, asking an obvious question, challenging a senior person. A conflict-averse team scores low on the thing, not high. The observable proxy is not harmony, it is whether junior people publicly disagree with senior people, and a lead who reads safety as niceness produces a team where nobody says anything, which is the pathology the research was describing.

Should you cite this material in an interview at all? There is a real risk of sounding like someone who reads management books instead of leading teams, and I have seen candidates overrun by it. My position: cite the mechanism, attribute briefly, and spend most of your words on your own situation. "That is Goodhart's law, and concretely what happened on my team was..." works. Three paragraphs on Project Aristotle without a single example from your own experience does not, because it answers a question about reading rather than about doing. One attribution per answer is plenty.

Follow-up Q&A

If throughput and stability move together, why do so many organisations believe they trade off? Because the trade-off is real at a fixed level of capability and disappears only when capability changes. If your deployment is manual and your test suite is unreliable, shipping more often genuinely does break more, and everyone in that organisation has direct evidence for the trade-off. DORA's finding is that the practices removing the trade-off (automated deployment, trunk-based development, small batches, comprehensive automated testing) are available and are what high performers have. So the honest statement is not "there is no trade-off", it is "the trade-off is a symptom of a fixable condition", and saying it that way is much more persuasive to someone whose lived experience is the trade-off.

How would you actually measure psychological safety on your team? Edmondson has a validated seven-item survey instrument and you can use it, but for a team of eight the survey is often worse than observation because anonymity is not credible at that size. Behavioural proxies I would use: the ratio of questions to statements in design reviews, whether anyone below staff level has publicly disagreed with anyone above it in the last month, whether incident timelines contain the phrase "I did not understand", and how long it takes for bad news to reach you compared with how long the person had known. Ask for the anecdote rather than the score: "tell me about the last time you told someone here that they were wrong" is one question and it produces more information than an instrument.

What is the difference between normalization of deviance and reasonable risk acceptance? Documentation and expiry. Accepting a risk deliberately, with the reasoning written down, a named owner and a review date, is engineering judgement. The same risk accepted implicitly, because it has not bitten yet and nobody re-examined it, is normalization of deviance. The distinguishing test is whether anyone could tell you today why the deviation is acceptable, and if the answer is "we have always done it that way", the drift has already happened. This is why exceptions should expire by default; an expiry date converts a silent drift into a scheduled decision.

Conway's law says architecture follows org structure. What if I cannot change the org? Then predict rather than fight. If two teams in different reporting lines with no shared rituals own two halves of a system, the interface between them will be poor and will accrete workarounds, and you should design accordingly: put a hard, versioned, explicitly owned contract at that boundary and invest in it disproportionately, because that is where the organisational fracture will express itself. The realistic lead move when you cannot restructure is to add the missing communication path (a shared on-call, a joint design review, one person with a foot in both) rather than to pretend the boundary is not there.

A team of ten is proposing to split into two teams of five. What does the research say? Team Topologies' answer is to split on cognitive load rather than on component boundaries: each team should own a domain it can hold in its head end to end, which usually means splitting along the flow of change rather than along technical layers. Conway predicts the architecture will follow whichever split you pick, so pick the split whose implied architecture you want. Brooks warns that the transition itself has a cost and that the communication paths between the two teams are now a permanent tax, so the split should be justified by an ongoing gain and not by a one-time frustration. The question I would ask the team: after the split, what change would require both teams to coordinate? If the answer is "most of them", the boundary is wrong.

Which of these would you drop if you had to keep only three? Goodhart, because it applies to every metric conversation you will ever have. Psychological safety with Edmondson's reported-errors finding, because it tells you what to look at rather than merely what to want. And normalization of deviance, because it is the only one on the list that describes a failure mode you cannot see from inside without a deliberate mechanism, which makes it the one where knowing about it changes the most.

Common misconceptions

"Project Oxygen showed technical skills do not matter for managers." It showed they ranked last within a population of technically strong managers. It is a threshold, not an irrelevance, and the popular reading inverts the finding.

"Project Aristotle found that psychological safety is all that matters." It found five factors and ranked safety first. Dependability, structure and clarity, meaning and impact were also predictive, and a team with high safety and no clarity is pleasant and ineffective.

"Brooks's law means never add people." It means adding people to a late project with unpartitionable work and deep context requirements is counterproductive. Growing a team between projects, or adding to genuinely parallel work, is normal and fine.

"Goodhart's law is about people gaming metrics." It is about correlations breaking under optimisation pressure, which happens without any intent to game. This matters practically: a solution based on catching cheaters will not work, because there are no cheaters.

"Chesterton's fence means do not change things." It means find out why first. Chesterton's own formulation explicitly permits removing the fence once you can explain it, and the principle is regularly used to defend the indefensible by people who have not tried to find out.

Interview delivery note

The sentence pattern that works: name the effect, state the mechanism in one clause, then go immediately to your own experience. "That is normalization of deviance: each time the deviation does not cause a failure, it becomes evidence that it is safe. Concretely, on my team we had a manual step in the release that everyone knew about, and the way I found it was that a new engineer asked why we did it, which is the only reason anyone noticed." Fifteen seconds of theory, then the thing that actually demonstrates you.

The separator between a senior candidate and a lead candidate here is whether the research is used descriptively or prescriptively. A senior candidate quotes the finding. A lead candidate uses it to make a prediction about a specific situation and then says what they would do about the prediction: "Conway's law tells me that boundary will accrete workarounds, so before we commit to the split I want a shared design review between the two teams, because that is the communication path the architecture is going to need whether or not the org chart provides it." That is the difference between having read something and having a model.

Further reading

• Diane Vaughan. The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press, 1996. Long, and the argument is worth it.
• Amy Edmondson. "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly, 1999. The reported-errors result is in the original paper.
• Nicole Forsgren, Jez Humble and Gene Kim. Accelerate. IT Revolution, 2018. Part II is the methodology, which is the part that makes the rest citable.
• Ron Westrum. "A typology of organisational cultures." BMJ Quality & Safety, 2004.
• Google re:Work, which publishes the Oxygen behaviour list and the Aristotle findings directly, including the 2018 revision.

Speaking in numbers: p90, Monte Carlo, and the language of estimates

What it is

The register that separates a lead who is trusted with a date from one who is not. It has two halves: the vocabulary (p90, order of magnitude, within noise, directionally correct, material, across the board) and the arithmetic underneath it, which is what stops the vocabulary from being decoration.

The central technical idea is that an estimate is a distribution, not a number, and almost every estimation failure in engineering follows from collapsing it to a number too early. Once you hold the distribution, three things become sayable that otherwise cannot be: how confident you are, what would change the answer, and what the cost of the confidence is. Monte Carlo is the cheapest way to get a distribution when you cannot derive one, and it takes about fifteen lines.

Don't be confused: p90 is a percentile of a distribution, not a safety margin you add. "Give me your p90" and "give me your estimate plus buffer" sound like the same request and are not. A p90 is the value below which 90 percent of outcomes fall, which is a statement about a distribution you have in mind. A buffer is a number you invented. The practical difference shows up immediately: p90s do not add, as the code below demonstrates, while buffers do, which is why an organisation that runs on buffers systematically over-quotes and then absorbs the slack invisibly.

Don't be confused: "we are not statistically significant yet" is usually the wrong sentence. Statistical significance answers "is this effect distinguishable from zero", which is rarely the decision you face. The decision is usually "is this effect big enough to be worth the cost", which is a question about the confidence interval and the minimum detectable effect, not the p-value. A result can be highly significant and commercially irrelevant, or non-significant and clearly worth shipping given the cost of waiting. Leads who say "significant" when they mean "big" get caught by anyone numerate in the room.

The problem it solves

A director asks when the migration will be done. There are three bad answers and each fails differently. A single number ("six weeks") is a promise you did not mean to make and will be held to. A refusal ("it depends") is read as evasion and is the answer that costs leads the most credibility. A padded number ("twelve weeks", privately meaning six) works once, and then the padding is discovered and every future estimate is discounted, which is strictly worse than where you started.

The fourth answer is a distribution with a commitment attached: "p50 is about eight weeks, p90 is about ten, and I will commit to ten. The spread is driven almost entirely by the backfill, so if you want the range tighter, the thing to fund is a week of prototyping the backfill." It is honest, it is actionable, it gives them a lever, and it is defensible when it goes wrong, because a p90 missed one time in ten is a p90 working correctly.

Mechanics

"""Monte Carlo estimation, and why you cannot add p90s.

Runnable: `python3 lead_estimation.py`. Deterministic: the seed is fixed, so the
numbers in the chapter are reproducible.

The scenario is one a lead actually faces. Six tasks, each with a three-point
estimate from the engineer who will do it. A director asks for a date they can
put in a plan. The naive answers are "add the optimistic numbers" and "add the
pessimistic numbers", and both are wrong in ways worth being able to name.
"""

import random
import statistics

# (task, optimistic, most likely, pessimistic) in engineer-days.
# These are the numbers you actually get when you ask, and the spread is wide
# because that is what honest estimates look like on unfamiliar work.
TASKS = [
    ("schema migration",      3,  5, 15),
    ("backfill job",          2,  4, 20),
    ("dual-write path",       4,  7, 14),
    ("read cutover",          1,  2,  6),
    ("delete old path",       1,  2,  4),
    ("load test and tune",    2,  6, 18),
]

TRIALS = 100_000


def triangular_sample(rng, lo, mode, hi):
    """A triangular distribution is the honest default for a three-point
    estimate: it uses exactly the three numbers you were given and assumes
    nothing else. PERT/beta weights the mode more heavily and is the other
    common choice; the point of this file is not the distribution, it is that
    ANY distribution beats adding single numbers."""
    return rng.triangular(lo, hi, mode)


def percentile(sorted_values, p):
    """Nearest-rank percentile. Written out rather than imported so the
    definition is visible: the p-th percentile is the smallest value below which
    p percent of observations fall."""
    if not sorted_values:
        raise ValueError("no data")
    k = max(0, min(len(sorted_values) - 1,
                   int(round(p / 100.0 * len(sorted_values) + 0.5)) - 1))
    return sorted_values[k]


def simulate(tasks, trials, rng):
    """Sum the tasks per trial, because they run in sequence. Each trial is one
    possible world; the distribution over trials is the answer."""
    totals = []
    for _ in range(trials):
        totals.append(sum(triangular_sample(rng, lo, mode, hi)
                          for _, lo, mode, hi in tasks))
    totals.sort()
    return totals


def per_task_percentiles(tasks, trials, rng, p):
    """The p-th percentile of each task INDEPENDENTLY, which is the number an
    engineer gives you when you ask 'what is your worst case'."""
    out = {}
    for name, lo, mode, hi in tasks:
        samples = sorted(triangular_sample(rng, lo, mode, hi) for _ in range(trials))
        out[name] = percentile(samples, p)
    return out


def with_one_parallel_track(tasks, trials, rng):
    """The same work, but the backfill and the load test run in parallel with
    the critical path instead of in series. The point: parallelism changes the
    shape of the distribution, not just its mean, because the finish time
    becomes a MAX over tracks and a max of two random variables is later than
    either one's typical value."""
    serial = [t for t in tasks if t[0] not in ("backfill job", "load test and tune")]
    side = [t for t in tasks if t[0] in ("backfill job", "load test and tune")]
    totals = []
    for _ in range(trials):
        a = sum(triangular_sample(rng, lo, mode, hi) for _, lo, mode, hi in serial)
        b = sum(triangular_sample(rng, lo, mode, hi) for _, lo, mode, hi in side)
        totals.append(max(a, b))
    totals.sort()
    return totals


if __name__ == "__main__":
    rng = random.Random(20260808)

    print("Three-point estimates, in engineer-days")
    print(f"  {'task':22} {'opt':>5} {'likely':>7} {'pess':>6}")
    for name, lo, mode, hi in TASKS:
        print(f"  {name:22} {lo:5} {mode:7} {hi:6}")

    sum_opt = sum(t[1] for t in TASKS)
    sum_mode = sum(t[2] for t in TASKS)
    sum_pess = sum(t[3] for t in TASKS)
    print()
    print(f"  naive sum of optimistic  : {sum_opt:6.1f} days")
    print(f"  naive sum of most likely : {sum_mode:6.1f} days")
    print(f"  naive sum of pessimistic : {sum_pess:6.1f} days")

    totals = simulate(TASKS, TRIALS, rng)
    print()
    print(f"Monte Carlo, {TRIALS:,} trials, tasks in series")
    for p in (10, 50, 80, 90, 95, 99):
        print(f"  p{p:<3}: {percentile(totals, p):6.1f} days")
    print(f"  mean : {statistics.mean(totals):6.1f} days")

    # The headline comparison: adding per-task p90s versus the p90 of the total.
    p90s = per_task_percentiles(TASKS, TRIALS, rng, 90)
    sum_of_p90s = sum(p90s.values())
    true_p90 = percentile(totals, 90)
    print()
    print("Why you cannot add p90s")
    for name, v in p90s.items():
        print(f"  p90 of {name:22}: {v:5.1f}")
    print(f"  SUM of the per-task p90s      : {sum_of_p90s:5.1f} days")
    print(f"  p90 of the TOTAL (simulated)  : {true_p90:5.1f} days")
    print(f"  overstatement                 : {sum_of_p90s - true_p90:5.1f} days "
          f"({100 * (sum_of_p90s / true_p90 - 1):.0f}% too pessimistic)")
    print(f"  and the naive most-likely sum : {sum_mode:5.1f} days, which lands at "
          f"p{100 * sum(1 for t in totals if t <= sum_mode) / len(totals):.0f} "
          f"of the real distribution")

    par = with_one_parallel_track(TASKS, TRIALS, rng)
    print()
    print("Same work, backfill and load test moved off the critical path")
    for p in (50, 90):
        print(f"  p{p:<3}: {percentile(par, p):6.1f} days "
              f"(was {percentile(totals, p):.1f})")
    saved_p50 = percentile(totals, 50) - percentile(par, 50)
    saved_p90 = percentile(totals, 90) - percentile(par, 90)
    print(f"  p50 improves by {saved_p50:.1f} days, p90 by {saved_p90:.1f} days")

The scenario is a six-task migration where each engineer gave a three-point estimate, which is what you actually get when you ask properly. Four details in the code matter.

The triangular distribution uses exactly the three numbers you were given and assumes nothing else, which makes it the honest default. PERT (a beta variant) weights the mode more heavily and is the other common choice. The point of the file is not the distribution: any distribution beats a point estimate, and arguing about which one is a good way to avoid doing the useful thing.

The tasks are summed inside each trial, then the trials are sorted. That ordering is the whole method. Each trial is one possible world in which each task took some particular time; the spread across trials is the answer. Summing the percentiles instead, which is the intuitive thing to do, produces the wrong number for a reason developed below.

The percentile function is written out rather than imported so the definition is visible, and because percentile conventions differ (nearest-rank, linear interpolation, several others) by enough to matter at the tails on small samples. With 100,000 trials the convention is irrelevant; with 40 measurements it is not, which is worth knowing when you are reading a latency dashboard.

The parallel variant takes a max rather than a sum. That is not a detail, it is the reason parallelising work helps less than people expect: the finish time of two parallel tracks is the maximum of two random variables, and the maximum of two draws is later than the typical value of either. Halving the critical path does not halve the schedule.

Worked example

Three-point estimates, in engineer-days
  task                     opt  likely   pess
  schema migration           3       5     15
  backfill job               2       4     20
  dual-write path            4       7     14
  read cutover               1       2      6
  delete old path            1       2      4
  load test and tune         2       6     18

  naive sum of optimistic  :   13.0 days
  naive sum of most likely :   26.0 days
  naive sum of pessimistic :   77.0 days

Monte Carlo, 100,000 trials, tasks in series
  p10 :   30.6 days
  p50 :   38.3 days
  p80 :   44.0 days
  p90 :   47.2 days
  p95 :   49.7 days
  p99 :   54.3 days
  mean :   38.7 days

Why you cannot add p90s
  p90 of schema migration      :  11.6
  p90 of backfill job          :  14.6
  p90 of dual-write path       :  11.4
  p90 of read cutover          :   4.6
  p90 of delete old path       :   3.2
  p90 of load test and tune    :  13.6
  SUM of the per-task p90s      :  59.0 days
  p90 of the TOTAL (simulated)  :  47.2 days
  overstatement                 :  11.8 days (25% too pessimistic)
  and the naive most-likely sum :  26.0 days, which lands at p1 of the real distribution

Same work, backfill and load test moved off the critical path
  p50 :   22.2 days (was 38.3)
  p90 :   27.2 days (was 47.2)
  p50 improves by 16.1 days, p90 by 20.0 days

The single most important number here is p1. The sum of the most-likely estimates is 26 days, and 26 days sits at the first percentile of the actual distribution. That plan has roughly a one in a hundred chance of being met. Every person who gave an estimate was being honest, every individual number was reasonable, and the addition of reasonable numbers produced a date that will essentially never happen. This is the arithmetic behind why software projects are late, and it does not require anyone to be optimistic or incompetent. The cause is that task durations are right-skewed (a task can take five times as long, it cannot take negative time) so the mode is well below the mean, and summing modes accumulates the gap six times over.

The second number is the 25 percent overstatement. Adding the per-task p90s gives 59 days against a true p90 of 47.2. The reason is that the sum's p90 does not require every task to hit its own p90; it requires the total to be high, and in most such worlds some tasks run long while others run short. Independent variation cancels. This is the same mathematics as "you cannot average percentiles" in the percentiles page, arriving from the other direction, and it has a direct organisational consequence: an organisation that asks everyone for a worst case and adds them up produces estimates roughly a quarter too large, gets treated as sandbagging, and then gets its numbers cut arbitrarily, which destroys the information content of the estimate entirely.

The third result is about parallelism. Moving the backfill and load test off the critical path improves p50 by 16.1 days and p90 by 20.0. Note that p90 improved more than p50, which is the non-obvious part and is the real argument for parallelising: taking work off the critical path does not merely shorten the schedule, it narrows the distribution, because the total no longer accumulates every task's variance. When you are asked to justify adding a person to a project, "it reduces the tail" is a much stronger claim than "it goes faster", and this is the demonstration.

Production evidence

Monte Carlo schedule estimation is standard practice in construction, aerospace and finance and is comparatively rare in software, which is the gap worth exploiting. The technique dates to Ulam and von Neumann's work at Los Alamos in the 1940s, and the name comes from the casino, via Ulam's uncle. In project management it appears as a standard extension to PERT and is built into mainstream scheduling tools.

Reference class forecasting is the same idea with empirical rather than simulated distributions, and it is mandated rather than merely recommended in some jurisdictions: the UK Treasury's Green Book requires optimism-bias adjustments derived from historical outturns for public projects, following Bent Flyvbjerg's work on megaproject cost overruns. The engineering translation is that your last five migrations are a better prior than your team's estimate of this one, and if you have that data you should use it in preference to any simulation.

Percentile-based commitments are how service levels already work, which is the argument for importing them into schedules. Nobody promises that every request will be under 200 ms; they promise a p99, and everyone understands that the remaining 1 percent is not a broken promise. Making a schedule commitment at p90 and saying so is exactly the same contract, and framing it that way to a non-engineering stakeholder usually lands, because they already accept the logic in the reliability context.

On the vocabulary side, "order of magnitude" reasoning is the documented interview norm at several of the companies in this book's loop formats, and the latency numbers table exists for exactly this purpose: not to be recited, but to make a factor-of-ten estimate available in ten seconds.

The debate

Is Monte Carlo worth it for a two-week project? No. The overhead is not the code, it is the three-point estimates, which take real time to collect honestly and which people resent providing. My position: use it when the decision is expensive and the spread is wide, which in practice means multi-month projects, anything with a hard external date, and anything where you are being asked to commit publicly. For a two-week project, ask for the most likely number, commit to roughly double it, and spend your effort elsewhere. Stating that threshold explicitly is better than either evangelising the technique or dismissing it.

Should you show the distribution to stakeholders, or just the commitment? Show the p50 and p90 and commit to one of them; do not show the full curve unless asked. The reason is not condescension, it is that a distribution invites negotiation over which percentile to plan against, and that negotiation is one you will lose, because the person with the budget will always prefer p50 and will remember it as the date. Give two numbers and a recommendation. The exception is when the spread is the message: if p50 is 8 weeks and p90 is 20, the shape is the finding, and the right conversation is about reducing uncertainty rather than about picking a date.

Are three-point estimates better than just asking for a number? Yes, and for a reason that has nothing to do with the arithmetic. Asking "optimistic, likely, pessimistic" makes people articulate what the pessimistic case actually is, which surfaces the risk. Half the value of the exercise is that someone says "20 days if the source data turns out to be inconsistent", and now you know the real question is the source data, which you can investigate this week instead of discovering in month two. The estimate is a by-product; the risk register is the product.

When is a point estimate the right answer? When you are being asked for a decision input rather than a commitment, and precision would be false. "Is this a week or a quarter" is a completely legitimate question, and answering with percentiles is unhelpful theatre. Match the precision of the answer to the precision of the decision.

Follow-up Q&A

Your tasks were sampled independently. Real project tasks are correlated. Does that break the model? It biases it, and in the dangerous direction, so this is the right challenge to raise about your own model before someone else does. If the underlying cause of the schema migration running long is the same as the cause of the backfill running long (the source data is worse than believed), those durations are positively correlated, and positive correlation increases the variance of the sum, which pushes the true p90 higher than the independent simulation says. Independent Monte Carlo is therefore optimistic about the tail. The practical fixes: model the shared driver explicitly as one variable that feeds several tasks, or apply a global multiplier drawn per trial, or simply say out loud that the p90 is a floor. Naming the assumption and its direction is worth more than fixing it.

Where does the mean sit relative to the p50, and why do you care? In this run the mean is 38.7 and the p50 is 38.3, so the mean sits slightly above the median, which is the signature of a right-skewed distribution: the long tail pulls the average up. That matters because the mean is the right number for aggregation and the median is the right number for a single commitment. If you are planning twenty such projects, use the mean, because the tails average out across a portfolio. If you are committing to one, use a percentile. Confusing them is how portfolio-level planning produces per-project promises nobody can keep.

How many trials do you need? Enough that the percentile you care about is stable, which you determine by running it twice with different seeds and seeing whether the number moves. For a p50, a few thousand trials is plenty. For a p99, you need considerably more, because the p99 is estimated from the top 1 percent of samples, so 1,000 trials gives you 10 observations to estimate it from and the answer will jump around. The code uses 100,000, which takes under a second and removes the question. The general principle worth stating: the further into the tail, the more data the estimate needs, which is also why p99.9 dashboards over five-minute windows are usually noise.

What does "within noise" actually mean and how do you avoid abusing it? It means the observed difference is smaller than the variation you would see between two measurements of the same condition. The abuse is invoking it without ever having measured that variation. The discipline: before comparing A to B, run an A/A comparison and see how different two identical things look. If your A/A test shows a 3 percent swing, then a 2 percent A/B result is within noise and you should say so with that number attached. "Within noise" with a measured noise floor is a strong statement; without one it is a way of dismissing data you dislike.

A stakeholder says "just give me a date". What do you say? Give one, then qualify in that order rather than the reverse. "Ten weeks. That is my p90, so I expect to make it nine times out of ten, and I would rather commit to that than to the eight-week median and miss it half the time. The one thing that could break it is the backfill, and I will know by the end of week two." Leading with the number respects the question; leading with the caveat sounds like evasion and gets you interrupted. The order of the sentences is doing as much work as their content.

How do you handle an estimate for work that has genuine unknown unknowns? You do not estimate it; you buy information. Time-box a spike with an explicit question and an explicit budget: "give me one week and I will tell you whether this is a two-week or a two-month problem." That is a commitment you can keep, and it converts an unanswerable question into a scheduled decision. Estimating through an unknown unknown is the single most common way leads lose credibility, because the number is not merely wrong, it is unfounded, and everyone finds out at the same time.

Common misconceptions

"The p90 means there is a 90 percent chance we finish on that day." It means a 90 percent chance of finishing on or before it. The distinction sounds pedantic and is not: percentiles are cumulative, and treating them as point probabilities leads people to think a p50 and a p90 are two competing predictions rather than two points on one curve.

"Adding the worst cases gives the worst case." It gives a number far beyond any realistic worst case, as the 59 versus 47.2 comparison shows. The genuine worst case is the tail of the total, and it is much closer to the p99 of the sum than to the sum of the p99s.

"Monte Carlo gives you accuracy." It gives you the consequences of your assumptions computed correctly. If the three-point estimates are wrong, the simulation is confidently wrong, and the false precision of "47.2 days" is actively dangerous. Round the output. Quoting a simulated schedule to one decimal place is a tell.

"p50 is the average." It is the median. They coincide only for symmetric distributions, and task durations are never symmetric. The gap between them is precisely the effect that makes projects late.

"Percentiles need a normal distribution." They need no distributional assumption at all, which is the main reason to prefer them over mean-and-standard-deviation for anything right-skewed, including both latency and task duration.

Interview delivery note

Two sentences are worth having word-perfect. For a date question: "My p50 is eight weeks and my p90 is ten. I will commit to ten, and the entire spread comes from the backfill, so if you want a tighter number the thing to fund is two days of prototyping it." For a metrics question: "That difference is within noise; our A/A variation is about three percent and this is two."

The senior-to-lead separator is whether the uncertainty is presented as information or as an excuse. A senior engineer says "it's hard to estimate, there are a lot of unknowns", which is true and is heard as hedging. A lead says "the uncertainty is concentrated in one place, here is what it would cost to remove it, and here is the number I will commit to meanwhile". Same underlying uncertainty; one version hands the decision-maker a lever and the other hands them a problem. Interviewers who have managed engineers have heard the first version many times and are listening specifically for the second.

Further reading

• Bent Flyvbjerg. "From Nobel Prize to Project Management: Getting Risks Right." Project Management Journal, 2006. Reference class forecasting, with the megaproject outturn data behind it.
• Douglas Hubbard. How to Measure Anything. Wiley, 3rd ed. 2014. Calibrated estimation and the value of information, which is the formal version of "buy information instead of estimating".
• Daniel Kahneman and Amos Tversky. "Intuitive Prediction: Biases and Corrective Procedures." 1979. The planning fallacy in the original.
• HM Treasury. The Green Book, supplementary guidance on optimism bias. A government mandating a correction factor derived from historical overruns is a useful thing to be able to point at.

The vocabulary of decisions and risk

What it is

The terms a senior engineer uses to talk about choosing under uncertainty. They are worth learning as a set rather than individually because they form a small, coherent system: a decision has a reversibility, it creates or destroys option value, its failure has a blast radius bounded by a failure domain, and the job before committing is risk retirement.

These are not decorations. Each one names a distinction that changes what you do, and using them correctly compresses a paragraph into a phrase, which is most of what "sounding senior" actually is. Using them incorrectly is worse than not using them, so each entry below includes the way it misfires.

Don't be confused: jargon that names a distinction is different from jargon that names nothing. "One-way door" earns its place because the alternative phrasing ("a decision that would be expensive and slow to reverse, so it warrants more analysis than its size suggests") is fifteen words and gets skipped. "Leverage synergies" names nothing and is why people are suspicious of vocabulary in the first place. The test: can you state the decision the term changes? If not, do not use it.

The problem it solves

Two problems, one internal and one external.

Internally, teams misallocate deliberation. They spend a fortnight on a decision they could reverse in an afternoon, and they make a genuinely irreversible choice in a corridor because it seemed small. Without a word for the difference, the sorting does not happen, because the apparent size of a decision is what people sort on and it is the wrong variable.

Externally, this vocabulary is how you get heard by people more senior than you. A director does not have context on your service. They do have a model of risk, cost and reversibility, and speaking in those terms lets them reason about your problem without learning it. That translation is a large part of the lead job, and it is what interviewers are testing when they ask you to explain a technical decision to a non-technical stakeholder.

Mechanics

Reversibility: the family that should drive your process

One-way door and two-way door come from Amazon's decision-making language and are the most useful pair here. A two-way door is a decision you can walk back through: you try it, and if it is wrong you undo it at low cost. A one-way door is expensive or impossible to reverse. The prescription is that the process should match the door, not the perceived importance: two-way doors get decided fast by whoever is closest, one-way doors get analysis, a written argument and more people.

• "The database choice is close to a one-way door, so I want to validate it properly."
• "This API naming choice is a two-way door. Ship it and adjust later."

How it misfires: almost everything gets labelled a one-way door by whoever wants more time. The correction is to ask what specifically makes it irreversible and what the reversal would cost, and often the answer reveals a two-way door with an expensive-sounding name. The genuinely irreversible things are a short list: data you delete, data you leak, an external API you publish, a promise to a customer, and a person you lose.

Reversibility is the underlying property, and it is the thing to optimise for under uncertainty. "Given how little we know, I would optimise for reversibility over optimality." That sentence is a strong lead move because it explicitly trades away a thing everyone wants (the best answer) for a thing that is worth more when you are uncertain (the ability to be wrong cheaply).

Option value is the value of keeping a future choice open. Keeping a storage interface neutral has option value; hard-coding DynamoDB semantics spends it. The reason to name it is that option value is invisible in a cost comparison, so it loses every argument in which it is not explicitly stated. "The abstraction costs us two weeks now, and what it buys is option value on the storage decision, which I think is worth it because we will learn a lot in the next quarter."

Path dependence is the observation that today's choice constrains tomorrow's options, often more than anyone intends. "Architecture is path-dependent; today's shortcut becomes next year's platform." The lead use is as an argument for caring about small decisions in foundational places, and it is the honest counter to "we can always change it later", which is true in principle and false in the presence of a hundred dependents.

Point of no return is the moment reversal stops being feasible, and the reason to name it is that it is usually not the moment people think. In a migration it is rarely the cutover; it is the first write that only exists in the new store. Identify it in advance and say so, because "we have not reached the point of no return yet" is one of the most reassuring sentences you can offer during a fraught migration, and it is only available to someone who worked out where it was.

No-regret move: an action worth taking under essentially any plausible future. "Adding observability is a no-regret move regardless of which architecture we pick." Enormously useful for breaking deadlock, because it lets a team make progress while the contested decision is still open, and it is the honest answer to "we cannot do anything until we decide".

The risk family

Blast radius is the scope of damage if something fails, and it is the most portable term on this page because non-engineers understand it immediately. "Can we reduce the blast radius by rolling out per tenant?" Failure domain is the boundary within which a single failure can affect things, and the pair works together: you reduce blast radius by aligning it with a failure domain. "We should not put both replicas in the same failure domain."

How they misfire: people use blast radius to describe severity rather than scope. A total outage of a service used by one internal team is severe and has a small blast radius. Keeping the distinction lets you make the argument that actually matters, which is usually about correlation: the question is not how bad one failure is, it is how many things fail together.

Single point of failure extends to people, and that extension is where a lead should be using it. "She has become a human single point of failure for deployments." Bus factor is the sharper form: how many people would have to disappear before critical knowledge is lost. "Our bus factor on the ranking pipeline is one." Naming a bus factor of one is one of the few ways to get time allocated for documentation and pairing, because it converts a vague concern into a number.

Risk retirement is the practice of deliberately eliminating the biggest uncertainties first, and it is the organising principle behind good project sequencing. "The first milestone should retire the scaling and data-quality risk." The natural instinct is to sequence work by dependency or by what is easy to start; the better instinct is to sequence by what could kill the project, because learning that in month one is cheap and in month five is not.

Test the riskiest assumption first is the same idea as an instruction. "Do not build the UI yet. Test the riskiest assumption, which is whether retrieval quality is good enough at all." De-risk is the verb: "Prototype the OpenSearch workload to de-risk the architecture."

Known unknown and unknown unknown separate the risks you can list from the ones you cannot. The practical difference is what you do about them: known unknowns get a spike, an owner and a date; unknown unknowns get slack and early integration, because the only reliable way to find them is to build something end to end and see what breaks. "The prototype is mainly about exposing unknown unknowns" is a legitimate justification for work that produces no shippable output, and it is a justification most engineers fail to articulate.

The consequence family

Second-order effect is the consequence of the consequence. "The first-order effect is faster deploys. The second-order effect is that people start making smaller changes, which is where most of the value actually is." This is one of the highest-value terms on the page, because reasoning past the first order is close to a definition of seniority, and because second-order effects are where both the benefits and the disasters live.

Downstream consequence is the narrower version for effects on other teams or systems. "Changing this schema has downstream consequences for analytics." Use it when you want to name a cost that lands on someone not in the room, which is a specific and valuable contribution to a decision.

Local maximum: a solution that is optimal within the current constraints and blocks a better design. "We keep optimising this service, but I think we are at a local maximum." The reason it is worth having is that it makes a legitimate argument for stopping incremental improvement, and that argument is otherwise very hard to make against people producing measurable gains. The honest counterweight to state alongside it: a local maximum you are sitting on is worth more than a global maximum you have not reached, so the argument has to come with an estimate of the cost of getting to the other hill.

Smoking gun: the single piece of evidence that settles a diagnosis. "The retry counters were the smoking gun." The discipline it enforces is worth more than the phrase: asking "what would be the smoking gun here?" during an incident forces people to state what evidence would distinguish their hypothesis from the alternatives, which is what stops an investigation from becoming a sequence of guesses. The absence of a smoking gun after an incident is itself a finding, and it usually means an observability gap.

Two register-setting idioms

Across the board means uniformly, affecting everything in a category. "Latency is up across the board, not just on the search path" is a precise and useful sentence: it immediately rules out a large class of causes, because a uniform regression points at something shared (a dependency, a node, a config, a deploy) rather than at any individual code path. Use it to describe a measurement, not a plan. "We need to improve across the board" is noise.

Down the road means at some later point, and its value is precision about when a cost lands. "Denormalising here saves us a join now and costs us a migration down the road." The trap is that it is frequently used to defer a decision indefinitely, and a lead should notice when it is doing that: "When, specifically, and what will have changed by then?" is the right follow-up, and it is the difference between a deliberate deferral and an avoided one.

Worked example

The same technical position, argued twice, in a design review where a team wants to adopt a new datastore.

Without the vocabulary: "I'm not sure about this. It feels like a big change and I think we should be careful. There's a lot we don't know and it might be hard to change later. Can we think about it more?"

That is a reasonable instinct expressed in a way that cannot be acted on. It offers no test, no decision and nothing anyone can agree or disagree with, so the likely outcome is that the proposer, who has a concrete plan, wins by default.

With it: "I think this is close to a one-way door: once we have written data that only exists in the new store, reversing means a migration rather than a config change, so I want to spend more on the decision than its size suggests. Two things I would do first. The riskiest assumption is that the access pattern fits the partition model, and we can retire that in about three days with a load test against real key distributions, which is a no-regret move because we need those numbers anyway. And I would keep the repository interface storage-neutral for now, which costs us maybe two days and buys option value on this exact decision. The second-order effect I am watching is on-call: this adds a datastore to the surface the team is paged for, and that cost is permanent while the performance win might not be. If the load test comes back clean, I am happy to go ahead."

Same reservations, and this version gets a decision. It names the reversibility, proposes a specific test with a duration that retires the main risk, prices the hedge, surfaces a consequence that lands on the team rather than the system, and commits to a condition under which the objection goes away. The last part is what makes it a lead contribution rather than an obstruction: an objection without an exit condition is a veto, and a veto costs you credibility even when you are right.

Production evidence

One-way and two-way doors entered general usage through Jeff Bezos's 2015 and 2016 Amazon shareholder letters, where the argument was explicitly about organisational speed: most decisions are two-way doors, large organisations apply heavyweight one-way-door process to all of them, and the result is slowness misdiagnosed as rigour. Whatever you think of the source, the framing is now common enough at senior levels that it functions as shared vocabulary rather than as a quotation.

Blast radius and failure domain are load-bearing in cloud architecture, not merely descriptive: AWS availability zones exist to be failure domains, and cell-based architecture is the explicit practice of bounding blast radius by partitioning users into independent cells so that a bad deploy or a poison request can only affect one cell. Amazon and Slack have both published on cell-based designs. See cell-based architecture.

Risk retirement and riskiest-assumption-first are the structural principle behind spiral development (Barry Boehm, 1986), whose central idea is that each iteration should be organised around resolving the highest risk remaining rather than around building the next component. It is also the logic of the lean-startup minimum viable product, stripped of the startup framing: build the smallest thing that tests the assumption most capable of invalidating the plan.

Bus factor shows up as an operational metric in real engineering organisations, usually computed from commit and review history per critical component, and it is a standard input to staffing and documentation decisions rather than a joke.

The debate

Does this vocabulary make you sound senior or make you sound like a consultant? Both are available and the difference is whether the term is doing work. A term used to make a distinction that changes the decision reads as fluency; a term used as a synonym for a plain word reads as posturing. My rule: at most two or three of these in an answer, each attached to a specific consequence. "It is a one-way door because reversing means a data migration" is fluency. "We need to think about the blast radius and the option value and the second-order effects here" is three abstractions and no content, and experienced interviewers discount it immediately.

Is "optimise for reversibility" always right? No, and the failure mode is real enough to name. Systematically preferring reversible options produces architectures made entirely of abstraction layers and feature flags, each of which was individually justified and which collectively are unmaintainable. Reversibility has a price, paid in complexity and in the option-value hedges you never exercise. The correct form is: optimise for reversibility in proportion to your uncertainty, so as you learn, deliberately spend reversibility for simplicity. A team that has been running a system for three years and still has the abstraction layer "in case we switch databases" is paying rent on an option it will never exercise, and removing it is the right call.

One-way doors: who should decide them? The instinct is "the most senior person available", and it is wrong in a specific way. The senior person should ensure the decision gets the right process, which is not the same as making it. The person with the most context should usually make it, with the reasoning written down and reviewed. The failure mode of senior people deciding one-way doors personally is that the reasoning stays in their head, which makes the decision unreviewable and un-inheritable, and one-way doors are exactly the decisions your successor will need to understand.

Follow-up Q&A

How do you tell a one-way door from a two-way door when nobody agrees? Ask one question: what would it cost, in engineer-weeks and in customer impact, to be running the alternative three months from now? A number under a couple of weeks with no customer impact is a two-way door regardless of how large the decision feels. The instinct to check against: the cost of reversal is usually dominated by accumulated dependencies rather than by the change itself, so the honest question is not "can we switch" but "how many things will have been built on this by then". That reframing usually resolves the disagreement, because it is answerable.

How is a pre-mortem different from a risk register? A risk register is a list you produce by asking "what could go wrong", which reliably generates generic risks nobody acts on. A pre-mortem, from Gary Klein, changes the prompt: assume it is six months from now and the project failed badly; write the story of how. The counterfactual framing defeats the optimism that suppresses concerns, and it gives people social cover to voice a doubt, because they are describing a hypothetical rather than predicting failure. The output is different in kind: specific, causal narratives rather than a list of categories, and specific narratives are actionable. Run it after the plan exists and before the commitment.

What is the difference between a root cause and a contributing factor, and why does it matter? The root cause is the initiating event; contributing factors are conditions that let it become an incident. "The expired certificate was the trigger; the missing expiry alert was a contributing factor." It matters because the contributing factors are usually where the durable fixes are. Renewing the certificate prevents this incident. Alerting on expiry prevents the class. Organisations that stop at root cause fix one incident at a time forever. The stronger position, from the resilience-engineering literature, is that "root cause" is mostly a narrative convenience for complex systems, where failures are typically the intersection of several conditions none of which is individually sufficient. You can hold that view and still use the term, as long as the postmortem's actions target the contributing factors.

Give me an example of a second-order effect that bit you. The pattern worth being able to tell: a change that improved its first-order metric and degraded the system through a path nobody modelled. The canonical shapes are worth recognising even from other people's experience. Adding a cache in front of a slow dependency improves latency, and the second-order effect is that the dependency's real load is now invisible, so its capacity problem is discovered during the next cache flush. Adding retries improves success rate, and the second-order effect is that a partial outage becomes a retry storm. The general rule: any change that decouples a consumer from a producer's pain has a second-order effect, because the pain was information.

Everything is a risk. How do you decide which ones to retire first? Two axes, and take the top-right quadrant. How likely is it to be a problem, and how much would the answer change the plan? The second axis is the one people skip, and it is the more important one: a risk whose resolution would not change anything you do is not worth retiring, however scary it is. If the answer to "will the vendor scale to 10x" is "we would use them either way because there is no alternative", the investigation is a comfort exercise. Sequence by information value, not by anxiety.

What is the difference between "we do not know" and an unknown unknown? The first is a known unknown and it has an owner and a date. An unknown unknown is not on any list, so no process finds it; the only things that find it are integration and contact with reality. Practically, this means the two get different responses: known unknowns get spikes, unknown unknowns get schedule slack and early end-to-end integration. A plan with no slack is a plan that assumes no unknown unknowns, which is an assumption no one would defend if stated aloud, and stating it aloud is the useful move when someone proposes one.

Common misconceptions

"A one-way door means you should not do it." It means you should decide it properly. Plenty of one-way doors are correct and necessary, and refusing to walk through them is its own failure. The prescription is about process, not about direction.

"Blast radius is about severity." It is about scope. Small blast radius with high severity is a normal and often acceptable design point; large blast radius with low severity is how outages become newsworthy.

"Optimising for reversibility means never committing." It means committing in a way you can undo, which is the opposite of not committing. A feature flag is a commitment with an exit.

"The riskiest assumption is the hardest technical part." Often it is not. It is frequently whether anyone wants the thing, whether the data is what you were told it is, or whether another team will deliver a dependency. Technical risk is the risk engineers most enjoy retiring, which is exactly why it is over-prioritised.

"Second-order effects are unpredictable." Many are, some are not, and the common ones are a short list you can learn: caching hides load, retries amplify failures, abstraction hides cost, automation atrophies the manual skill, and any metric you publish changes behaviour. Checking against that list takes a minute.

Interview delivery note

The single highest-return sentence from this page, usable in almost any design discussion: "Before we go further, is this a one-way door? Because if it is not, I would rather decide it now and be prepared to change it than spend two weeks getting it right." It demonstrates that you sort decisions by reversibility, it moves the discussion forward, and it signals a bias to action without recklessness, which is precisely the balance a lead is hired for.

The senior-to-lead separator is attaching an exit condition to every objection. A senior engineer raises a risk. A lead raises the risk, says what evidence would resolve it, says how long that would take, and commits to a position if the evidence comes back clean. The first is useful and can be argued with indefinitely. The second ends with a decision, and the ability to end discussions with decisions is most of what the role is.

Further reading

• Jeff Bezos. Amazon shareholder letters, 2015 and 2016. The one-way and two-way door framing, in the argument it was written for.
• Gary Klein. "Performing a Project Premortem." Harvard Business Review, September 2007. Two pages, and the method is in them.
• Barry Boehm. "A Spiral Model of Software Development and Enhancement." IEEE Computer, 1988. Risk-driven sequencing before it was called anything else.
• Richard Cook. "How Complex Systems Fail." 1998. Eighteen numbered observations, four pages, and the strongest available argument against single root causes.

The vocabulary of systems, failure and design

What it is

The terms senior engineers use to describe how a system behaves under stress and how a design treats the people who use it. Two families sit on this page because they are the same subject from two ends: the design vocabulary (footgun, pit of success, seam, escape hatch) describes whether a system is easy to use correctly, and the failure vocabulary (backpressure, load shedding, retry storm, brownout) describes what it does when it cannot keep up. A system with sharp edges fails in ways a system with guardrails does not.

Most of these have precise technical referents elsewhere in this book. What this page adds is the conversational use: when to reach for the word, what it commits you to, and how it misfires. A term used loosely by someone who does not know its mechanism is detectable in one follow-up question.

Don't be confused: backpressure and load shedding are opposite responses to the same condition. Both trigger when a consumer cannot keep up. Backpressure propagates the slowness upstream, so the producer slows down and nothing is lost. Load shedding discards work, so throughput is preserved for what remains and something is lost. The choice is not stylistic: backpressure is right when the producer can slow down and the work must not be lost (a batch pipeline, a file upload), and shedding is right when the producer cannot be slowed and lateness is worthless (live requests, a stock feed). Using them as synonyms is the most common way to fail a follow-up on this material.

The problem it solves

Under pressure, the words available to a team determine what it can discuss. A team without "backpressure" reaches for "add a bigger buffer", which is the failure mode the word exists to prevent. A team without "pit of success" argues about whether developers should be more careful, which never works, rather than about whether the default is wrong, which does.

In an interview the job is narrower and sharper. These terms let you describe a failure mode in three words that would otherwise take a paragraph, which buys you time to say something substantive, and they signal that you have operated a system rather than only built one.

Mechanics

Whether the design helps or hurts its user

Footgun: something that makes it easy to accidentally harm yourself. "Letting callers pass an arbitrary timeout here is a footgun." The word carries a specific accusation, that the danger is available by default rather than requiring effort, and that is what makes it different from "this API is complicated". Reach for it when the failure requires no mistake, only inattention.

Sharp edge: a feature that works but is easy to misuse with serious consequences. "The client works, but it has sharp edges around retries." Softer than footgun, and the right word when the danger is real but requires the user to be doing something reasonable-looking.

Pit of success: a design where the easiest, default behaviour is also the correct one. "Make idempotency automatic so callers fall into the pit of success." Rico Mariani's phrase from Microsoft, and it is the constructive counterpart to the two above. It is the single most useful design term on this page for a lead, because it redirects a conversation from "how do we get people to do the right thing" to "why is the right thing not the default", and the second question has answers.

Leaky abstraction: an abstraction whose implementation details still reach the user. "Our repository layer is leaking database semantics." Joel Spolsky's law is that all non-trivial abstractions leak to some degree, so the useful form is never "this leaks" but "this leaks in a way that costs us something specific". An ORM that leaks N+1 query behaviour is a leak that matters; one that leaks connection-pool naming is not.

Escape hatch: a deliberate, supported way to bypass the abstraction when it does not fit. "The framework needs an escape hatch for unusual query patterns." The important word is deliberate. Every abstraction will be bypassed; the choice is whether the bypass is designed, documented and observable, or whether it is a hack that spreads. A platform without escape hatches does not get compliance, it gets shadow infrastructure, which is the argument to make when a platform team proposes to lock something down.

Seam: a place where behaviour can be changed or substituted without editing the surrounding code. Michael Feathers's term from Working Effectively with Legacy Code, and the most useful single concept for talking about untestable systems. "We need a seam around the payment provider before we can test this safely." It reframes "this code is untestable" as a concrete structural request, which someone can actually do.

How you change a system without stopping it

Strangler pattern: incrementally replace a legacy system by routing traffic to new components until the old one is unused, rather than rewriting and switching. "Put the new recommendation API in front and strangle the legacy path incrementally." Martin Fowler's name for it, after the strangler fig. The reason it wins arguments is that it is the only rewrite approach that produces value before it finishes and that can be abandoned halfway without having wasted everything.

Walking skeleton: a minimal end-to-end implementation proving every major component connects, before any of them do anything useful. "Before we build ranking logic, get a walking skeleton from ingestion through to serving." Tracer bullet is the close cousin from The Pragmatic Programmer, emphasising discovery rather than structure: a thin path through the whole system fired early to find out what you do not know. "Build a tracer bullet through Kinesis, embeddings, OpenSearch and the API."

Thin vertical slice: one small feature built end to end, rather than one architectural layer built completely. "Do one thin vertical slice before building the whole data platform." All three of these share a single argument, and it is worth being able to state it directly: integration risk is the risk that does not decompose. You can estimate each component accurately and still be badly wrong about the whole, because the interactions are where the surprises are, and horizontal layer-by-layer construction defers every interaction to the end. This is also the practical content of Gall's law.

What a system does when it cannot keep up

Backpressure: the mechanism by which a slow consumer causes producers to slow down. "The consumer needs to propagate backpressure instead of buffering indefinitely." The failure it prevents is unbounded buffering, and the sentence that gives it teeth is that an unbounded queue does not solve a throughput mismatch, it converts it into a memory failure and adds latency while it does so.

Load shedding: deliberately rejecting lower-priority work to protect the rest. "At 95 percent saturation we shed recommendation refresh requests." The lead-relevant point is that shedding is a decision about priority, so the design question is not "should we shed" but "what is the priority order and who decided it", and that question usually has no owner.

Graceful degradation: continuing with reduced functionality rather than failing entirely. "If personalisation is unavailable, degrade to popular articles." Brownout is the deliberate, temporary version: switching off expensive optional functionality during overload. "During peak we brown out the expensive recommendations."

Fail open and fail closed describe what happens when a dependency is unavailable: does the operation proceed or is it rejected? "For authorisation, we fail closed." This is a genuine decision with no universal answer, and the deciding variable is what the check is protecting against. Security checks fail closed, because an unavailable authoriser must not become an open door. Availability-oriented checks (a recommendation service, a feature flag lookup) fail open. The dangerous case is a check that everyone assumes fails closed and which was implemented to fail open for availability reasons, usually years earlier, usually undocumented, which is a specific and excellent thing to go and check on your own systems.

Defense in depth: multiple independent protective layers, so that any single failure is not sufficient. "Rate limits, authentication, quotas and tenant isolation give us defence in depth." The load-bearing word is independent: three controls that all depend on the same identity service are one control wearing three hats, and saying so is a good way to demonstrate that you understand the term rather than merely using it.

Head-of-line blocking: one slow item delaying unrelated work behind it. "Large jobs are causing head-of-line blocking in the queue." Thundering herd: many clients acting simultaneously, usually after a shared trigger. "Cache expiry causes a thundering herd against Postgres." Retry storm: retries amplifying an outage rather than recovering from it. "Without exponential backoff and jitter, a brief dependency blip becomes a retry storm." Death spiral: a feedback loop where degradation creates load that creates more degradation. "Latency rose, clients retried, retries raised load, and we entered a death spiral."

Those four are a progression and it is worth saying so, because the progression is what makes the story coherent in a postmortem: head-of-line blocking creates latency, latency triggers retries, retries create a herd, the herd creates a death spiral. A candidate who narrates an outage along that chain sounds like someone who has been in one.

The guardrail family

Paved road or golden path: the supported, recommended way of doing something, which is easier than the alternatives rather than merely mandated. "Our deployment template on Kubernetes is the paved road." Guardrails, not gates: prefer automated constraints that catch problems to human approvals that hold things up. "Security should provide guardrails, not gates."

Both encode the same position, which is worth stating as a position rather than a slogan: compliance obtained by making the right thing easy is durable, and compliance obtained by review is a tax that people route around. The honest limit, and you should volunteer it, is that guardrails only work where the constraint is machine-checkable. Judgement calls (is this design sound, is this vendor acceptable) still need people, and pretending otherwise produces automation theatre.

Shift left: move validation earlier, into development and CI. "We shifted schema compatibility checks left into CI." Shift right: validate in production with observability, canaries and experiments, on the argument that some properties only exist under real traffic. "Some reliability properties can only be validated by shifting right." They are complements rather than alternatives, and the mature position is that you shift left everything that is cheaply checkable and shift right everything that is only true in production, which is more than people expect: real load shapes, real data distributions, real client behaviour.

Complexity as a budget

Accidental complexity comes from your implementation choices; essential complexity is inherent to the problem. Brooks's distinction, and the reason it matters is that only one of them is removable. "Half of this workflow is accidental complexity from the framework." "Exactly-once financial posting is essential complexity, and no abstraction removes it."

Complexity budget: the informal limit on how much a team can operate. "Kafka would work, but I am not sure this justifies the complexity budget." Change surface: how much of the system a modification touches. "Can we reduce the change surface by putting the compatibility logic at the boundary?"

The reason to have these as nouns is that they make an otherwise unwinnable argument winnable. "This is too complicated" is an aesthetic objection and loses to a concrete benefit. "This spends complexity budget we are already overdrawn on, and here is the on-call burden that proves it" is a cost, and costs can be weighed.

Worked example

An incident review, narrated twice.

Without the vocabulary: "The database got slow, and then everything got slower, and there were a lot of requests, and eventually it fell over. We restarted things and it recovered. We should probably add some limits."

With it: "A slow query in the reporting path caused head-of-line blocking on the shared connection pool, so unrelated requests queued behind it. Latency crossed the client timeout, so clients retried, and because the retry policy had no backoff or jitter that became a retry storm, roughly tripling offered load at the moment we had least capacity. That is a death spiral: the system's response to overload increased the overload. We recovered by restarting, which worked only because it dropped every in-flight retry.

Three fixes at different levels. Immediately, backoff with jitter on the client, which breaks the amplification. Structurally, a separate connection pool for reporting so the failure domain does not include the serving path, which turns this from an outage into a degraded report. And the real fix is load shedding: at 90 percent pool saturation we should reject reporting queries with a clear error rather than queueing them, because a report that arrives four minutes late is worth nothing and it cost us the serving path. The thing I want to change culturally is that the unbounded queue looked like resilience and was actually the mechanism of the failure."

The second version is not longer by much and is a completely different signal. It names a causal chain rather than a sequence of events, it identifies the amplifying feedback loop explicitly, it separates fixes by time horizon, and it ends with the generalisable lesson. Every one of those moves is enabled by having the words.

Production evidence

Backpressure is a specified part of the Reactive Streams standard (now java.util.concurrent.Flow in the JDK), where request(n) is literally the consumer telling the producer how much it can take. That it needed standardising across Akka, Reactor, RxJava and Vert.x is evidence of how often the naive version was got wrong.

Load shedding at Netflix and Google is documented practice rather than theory. Google's SRE book devotes a chapter to handling overload, covering client-side throttling and criticality levels so that shedding is priority-aware, and Netflix has published on concurrency limits and prioritised load shedding at the edge. The recurring finding in both: the failure of an overloaded system is usually caused by the system's own retry behaviour, which is why adaptive concurrency limits and circuit breakers exist.

Thundering herd mitigation is why cache libraries ship jitter. The standard fixes, randomised TTLs, request coalescing so only one caller recomputes, and probabilistic early expiration, are built into mature caching layers precisely because the naive implementation reliably produces synchronised expiry.

The paved road model is how large platform organisations actually operate. Netflix's "paved road" language is the widely-cited origin, and Spotify's "golden path" is the same idea; in both, the road is optional but supported, and the deal offered to teams is explicit: take the road and get deployment, observability and compliance handled, or leave it and own those yourself. The optionality is the design, not a weakness of it, because a mandatory road gets no feedback about whether it is any good.

Strangler applications are the documented approach for most large legacy migrations that succeeded, and the pattern name comes from Martin Fowler's 2004 article. The counter-evidence is instructive too: the well-known big-bang rewrite failures (the Netscape 6 rewrite is the canonical software-industry example, described in Joel Spolsky's "Things You Should Never Do") are what the pattern exists to avoid.

The debate

Backpressure or load shedding, when both are available? The deciding variable is whether the work retains value when delayed. If it does, propagate backpressure, because dropping work that is still worth doing is pure loss. If it does not, shed, because queueing worthless work consumes capacity that valuable work needs. My default for user-facing request paths is to shed, and for data pipelines is backpressure, and the mistake I see most often is applying the pipeline instinct to a request path: buffering user requests during overload produces a queue of responses nobody is waiting for any more, and the system spends its recovery capacity answering abandoned questions. Say the phrase "we should reject rather than queue, because a late answer here is worth nothing" and you have made the whole argument.

Is "guardrails, not gates" always right? No, and treating it as absolute is a recognisable inexperience tell. Gates are correct where the action is irreversible, rare, and high-consequence: production data deletion, a change to how money moves, granting standing production access. The cost of a gate is proportional to how often it triggers, so a gate on a rare, catastrophic action is cheap and a gate on a daily action is ruinous. The refined position: automate everything checkable into guardrails, then place a small number of gates on the irreversible actions, and be able to name every gate and why it exists. An organisation that cannot enumerate its gates has accumulated them rather than chosen them.

Should every abstraction have an escape hatch? Mostly yes, with one real exception. Escape hatches undermine invariants you actually need to hold: if your platform guarantees that all traffic is authenticated and observable, an escape hatch that bypasses the mesh voids the guarantee, and the guarantee was the product. The resolution is to distinguish invariants from conveniences. Provide escape hatches around conveniences (query patterns, serialisation, deployment shape) and refuse them around invariants, while making the invariant path fast enough that nobody wants out. If people are routing around an invariant, the invariant is either wrong or too expensive, and that is worth learning rather than policing.

Follow-up Q&A

How do you actually implement backpressure across a network boundary? You need an explicit protocol-level mechanism, because TCP's flow control only tells you the socket buffer is full, which is far too late and too coarse. The real options: a credit or request-based protocol (Reactive Streams' request(n), gRPC streaming flow control, RSocket's leasing), a bounded queue with a blocking or rejecting put so that fullness propagates as slowness or as an error, or an explicit rate negotiated between the parties. The anti-pattern is an unbounded queue between services, which converts a throughput mismatch into unbounded latency followed by an out-of-memory failure. If you cannot introduce a real mechanism, a bounded queue that rejects is still far better than an unbounded one that lies.

How do you choose the shedding threshold? Not from CPU, which is the common mistake, because CPU is a lagging and non-linear signal near saturation. Shed on queueing delay or on concurrency measured against a limit, because those rise before throughput collapses. The adaptive approach (Netflix's concurrency-limits work, based on TCP congestion-control ideas like Vegas) measures latency continuously and infers the concurrency limit rather than requiring you to configure one, which matters because the right limit changes with instance type, dependency health and traffic mix. Start with a static limit derived from a load test, then move to adaptive when the static one is visibly wrong, and instrument shed events as a first-class metric so you can tell shedding from failure.

How is graceful degradation different from a circuit breaker? A circuit breaker is a mechanism that stops calling a failing dependency; graceful degradation is the product decision about what to do instead. The breaker gives you a fast failure; degradation is what fills the hole. A circuit breaker without a degradation plan just converts a slow failure into a fast one, which helps your latency and does nothing for your user. The interview-relevant point is that the degradation plan is a product conversation, not a technical one: someone has to decide that popular articles are an acceptable substitute for personalised ones, and that person is usually not an engineer.

Which is the more dangerous default, fail open or fail closed? Fail open, because its failure is silent. A fail-closed system that breaks causes an outage, and everyone finds out in minutes. A fail-open system that breaks keeps serving, and you discover months later that the authorisation check has been returning true since a deploy in March. So my default is to fail closed unless there is a stated availability reason to do otherwise, and to alert loudly on every fail-open event, because the thing that makes fail-open acceptable is knowing it happened. An unmonitored fail-open path is a vulnerability with a deployment date.

When is a walking skeleton a waste of time? When the integration risk is genuinely already retired: you are adding the fourth service to an established platform, the deployment path is known, the interfaces are the same as the last three. Then the skeleton proves something you already know, and the honest thing is to skip it. The test is whether you can name something the skeleton would tell you that you do not currently know. If you cannot, it is ritual. If you can (does the embedding service actually handle our payload size, does the network path between these two VPCs exist), build it this week.

Is technical debt a useful metaphor or a harmful one? Genuinely contested, and worth having a view. It is useful because it captures the interest payment: a shortcut has a recurring cost, not a one-time one, which is why "debt service" is the more precise phrase and why "that integration consumes 20 percent of the team's capacity in debt service" is a sentence that gets funding. It is harmful because it implies the debt was deliberately taken on at a good rate, which flatters most of what gets called debt, and because it suggests any debt can be repaid, when some of it is better characterised as a design you would not choose and cannot afford to replace. My position: keep the metaphor for deliberate, identified shortcuts with a known payoff, and use plainer language ("this design is wrong for what we now need") for the rest, because conflating them lets genuinely bad architecture hide inside a respectable-sounding category.

Common misconceptions

"Backpressure means adding a queue." It means bounding the queue and propagating fullness. An unbounded queue is the absence of backpressure with extra steps.

"Retries improve reliability." Retries improve reliability against independent, transient failures and actively harm it against correlated ones, which is what an overload is. Retries without backoff, jitter and a budget are an availability risk, not a mitigation.

"Defence in depth means more layers." It means more independent layers. Layers sharing a failure mode add cost and complexity while adding no depth, and the shared dependency is usually identity or DNS.

"A leaky abstraction is a bug." All non-trivial abstractions leak. The question is whether the leak costs anything, and the goal is to choose which details leak rather than to eliminate leaking.

"Shift left means shift everything left." Some properties only exist in production, and pretending a staging environment tests them produces false confidence, which is worse than untested. Real traffic shapes, real data skew and real client behaviour are shift-right concerns by nature.

Interview delivery note

The highest-value habit from this page is narrating a failure as a causal chain with a named amplifier, because it is what people who have been in incidents do and it cannot be faked convincingly. "Head-of-line blocking created latency, latency triggered retries, and the retries were the amplifier that turned a slow query into an outage" is one sentence, and it tells the interviewer you have sat through the real thing.

The senior-to-lead separator is which layer your fix lands on. A senior engineer fixes the slow query. A lead fixes the slow query, isolates the failure domain so the next slow query cannot reach the serving path, and then changes the default so that the class does not recur, usually by making the safe thing the easy thing. The last move is the pit-of-success argument applied to your own organisation, and it is what makes a fix durable after you have moved on.

Further reading

• Betsy Beyer et al. Site Reliability Engineering. O'Reilly, 2016. Chapter 21, "Handling Overload", and chapter 22, "Addressing Cascading Failures", which is the death spiral in detail.
• Michael Feathers. Working Effectively with Legacy Code. Prentice Hall, 2004. Seams, and how to create one in code that resists it.
• Martin Fowler. "StranglerFigApplication." martinfowler.com, 2004.
• Michael Nygard. Release It!, 2nd ed. Pragmatic Bookshelf, 2018. The stability patterns and antipatterns, which is where most of the failure vocabulary on this page was made precise.

The vocabulary of organisations, ownership and delivery

What it is

The terms that describe where work gets stuck and who is allowed to unstick it. This is the largest of the three language pages because it is where a lead spends most of their words: the costs that organisations pay without noticing (the taxes), the flow concepts that explain why adding people does not help (constraint, critical path, WIP), the ownership concepts that determine whether anything gets decided (decision rights, DRI, escalation path), and the mechanisms that make an outcome recur rather than happen once.

The organising claim, and it is worth holding explicitly: almost every "we are moving too slowly" problem is one of four things. A queue nobody is measuring, a decision nobody owns, a cost nobody has priced, or work in progress nobody has limited. The vocabulary below is organised around those four, because a term that helps you identify which one you are looking at is worth more than a term that merely sounds senior.

Don't be confused: a mechanism is not a process, and the difference is what interviewers are listening for. A process is a set of steps people are expected to follow. A mechanism produces the outcome whether or not anyone remembers to care: it has an owner, a trigger, a forcing function and an output that someone would notice the absence of. "We agreed to review dependencies quarterly" is a process and it will lapse by the second quarter. "The dependency report is generated automatically, lands in the team channel, and the platform lead is named on it" is a mechanism. When asked "how do you stop this recurring", answering with a process is the most common way to give an answer that sounds right and scores low.

The problem it solves

Organisational costs are mostly invisible, and invisible costs never lose an argument because they are never in it. Every one of the "tax" terms below exists to make one of these costs sayable: the ongoing price of a dependency between two teams, of a shared database, of a self-hosted system, of an architecture that a team cannot hold in its head. Once a cost has a name, it can appear in a comparison, and once it appears in a comparison it can win.

The flow vocabulary solves the opposite problem: too many visible things. When delivery is slow there are twenty plausible causes and no way to rank them. Constraint, critical path and queue discipline give a ranking, and the ranking is usually surprising, which is the point.

Mechanics

The taxes: costs paid continuously, noticed rarely

Coordination tax: productivity lost because people or teams must synchronise. "Splitting this across four teams adds more coordination tax than technical value." Coupling tax: the ongoing cost of dependencies between systems. "The shared database is a significant coupling tax." Integration tax: the recurring cost of connecting things built independently. "Supporting five auth providers is a permanent integration tax." Operational tax: the burden of running something. "Self-hosting gives us control and a substantial operational tax." Carry cost: the ongoing cost of keeping any decision around. "Every additional datastore has a carry cost."

They are variations on one move, and the move is what matters: convert a one-time-looking decision into a recurring cost. The reason this wins arguments is that build-versus-buy and split-versus-consolidate discussions are almost always framed as one-time comparisons, in which the option with the lower upfront cost wins by construction. Naming a tax changes the units.

Cognitive load: the mental effort required to understand or operate a system. "The architecture is elegant and imposes too much cognitive load." This is the one with the most theoretical backing, from Team Topologies, which argues team boundaries should be drawn so that each team's domain fits within its cognitive capacity. Its practical power is that it makes "this is too much for this team" a design statement rather than a complaint about the team, which is the difference between a conversation that goes somewhere and one that offends people.

Toil: repetitive manual operational work that scales with service size and produces no lasting value. "Certificate rotation is our biggest source of toil." The SRE definition is strict and the strictness is the value: toil is manual, repetitive, automatable, tactical, devoid of enduring value, and scales linearly with growth. Work failing those tests is not toil, it is just work you dislike. Google's SRE practice puts a numeric cap on it, 50 percent, and having a number is what makes it a constraint rather than an aspiration.

Undifferentiated heavy lifting: necessary infrastructure work that gives no competitive advantage. "Running our own broker is undifferentiated heavy lifting." The phrase is Amazon's and it is the core buy-over-build argument. The counter to have ready, because a good interviewer will push: the boundary moves, and something undifferentiated at your scale can be your entire advantage at another. A search company running its own retrieval stack is not doing undifferentiated heavy lifting; a payments company doing the same thing is.

Force multiplier: something or someone that makes others substantially more effective. "A platform team should be a force multiplier, not a service desk." Worth using sparingly and precisely, because it has been diluted into a compliment. The precise use is comparative: this work makes N other people faster, therefore it is worth more than the same effort spent directly.

Flow: why the obvious fix does not work

Constraint: the limiting factor on throughput. "If QA capacity is the constraint, adding developers will not increase throughput." This is Goldratt's theory of constraints in one word, and it earns its place because improving anything other than the constraint improves nothing, which is deeply counterintuitive and is why teams work hard and get faster at nothing.

Critical path: the dependency sequence that determines the earliest possible completion. "The frontend is not on the critical path; the data backfill is." Long pole in the tent: the same idea, informally, for the component that determines the timeline. "Data migration is the long pole." Both let you say the most useful sentence in project planning, which is that work not on the critical path is free to be late, so effort spent accelerating it is wasted.

Move the bottleneck: what happens when you fix a constraint and expose the next one. "We sped up development and moved the bottleneck to code review." This is essential for setting expectations, because it predicts that the first improvement will disappoint, and predicting a disappointment in advance is how you survive it politically.

WIP limit: a cap on concurrent work in progress. "The team needs a WIP limit, not more parallel projects." The argument is Little's Law: cycle time equals work in progress divided by throughput, so with throughput roughly fixed, halving WIP halves cycle time, and it does so without anyone working harder. It is the single most reliable intervention available to a new lead, and it is the one teams resist most, because starting feels productive and finishing feels slow.

Queue discipline: the rules governing how queued work is ordered and served. "Changing queue discipline may improve tail latency without adding capacity." The lead application is that most teams run their review and support queues FIFO by accident, never having chosen, and that shortest-job-first or an explicit priority class is often strictly better and free.

Ownership: who is allowed to decide

Decision rights: who has authority over which decisions. "The problem is not accountability, it is that decision rights are unclear." This is frequently the actual diagnosis when a team is stuck, and it is invisible until named, because everyone assumes the question of who decides was settled and nobody checks.

DRI, directly responsible individual: one named, accountable person. "Who is the DRI for the migration?" Apple's term, widely adopted. The value is the singular: a group is not a DRI, and "the team owns it" is how things stop being owned.

RACI (responsible, accountable, consulted, informed) is the heavyweight version and is worth naming with a caveat: it is genuinely useful for a cross-team programme with unclear boundaries, and it is bureaucratic overkill for one team's work. Say which you would use and why. Two-in-a-box: two leaders jointly responsible, usually product and engineering. "We run product and engineering two-in-a-box."

Ownership boundary: the explicit division of responsibility between teams. "The incident exposed an unclear ownership boundary." Note that ownership boundaries and Conway's law interact: an unclear ownership boundary reliably produces a bad interface, because there is no one to negotiate it.

Escalation path: the defined route for resolving something beyond local authority. "We need a clear escalation path for cross-team blockers." The specific failure this prevents is the two-week silent block, where a team is stuck on another team and nobody has said so to anyone with the power to resolve it, usually because escalating feels like an accusation. Naming the path in advance removes the social cost of using it, which is the whole point.

Hero culture: an organisation dependent on individuals repeatedly rescuing it. "We should fix the process rather than reward hero culture." The mechanism worth explaining is that heroism is self-perpetuating: it resolves the incident, which removes the pressure to fix the cause, and it is rewarded, which produces more of it. Recognising the hero and fixing the system are not in tension, and saying both is the mature version.

Talking: the phrases that shape a discussion

Disagree and commit: state the disagreement, then support the decision once made. "I still prefer Postgres, but I will disagree and commit to DynamoDB." The important half is the first one, and the phrase is regularly abused to mean "stop arguing", which inverts it. It requires that the disagreement was actually heard and recorded; without that it is compliance with extra syllables.

Strong opinions, loosely held: have a defensible position and update on evidence. Useful as an aspiration and worth being slightly wary of, because in practice it often licenses the strong opinions without the loose holding. The better operational form is to state in advance what would change your mind, which is falsifiable in a way the slogan is not.

Challenge the premise: question the assumption behind the question. "Before we discuss Kafka, I want to challenge the premise that this needs to be asynchronous at all." One of the highest-value moves available in a design interview, because a large fraction of design questions contain an unnecessary assumption, and because it demonstrates that you engage with problems rather than with tasks.

Work backward: start from the outcome and derive the implementation. "Work backward from the latency SLO rather than starting from the technology." Amazon's working-backwards process (write the press release first) is the formal version, but the everyday use is simply refusing to start a design from the components.

Bikeshedding: disproportionate attention to trivia. "We are bikeshedding names while the consistency model is unresolved." Yak shaving: a chain of prerequisites before the actual task. "I wanted to change one endpoint and ended up yak shaving the CI pipeline." Boil the ocean: attempting an unnecessarily vast scope. "Let us not boil the ocean; solve recommendation freshness first." Gold-plating: sophistication beyond the requirement. "Multi-region active-active is gold-plating at our current scale." Premature abstraction: generalising before you have the cases. "I would rather duplicate this twice than introduce a premature abstraction."

Metrics and avoidance

Leading indicator: predicts a future outcome. "Review queue depth is a leading indicator of cycle-time deterioration." Lagging indicator: reports an outcome that already happened. "Availability is mostly a lagging indicator." The value of the pair is that leading indicators are the only ones you can act on, and most dashboards are entirely lagging.

Proxy metric: a measurable stand-in for what you care about. "PR count is a weak proxy for productivity." Vanity metric: impressive and decision-free. "Lines of code is a vanity metric." Counter-metric or guardrail metric: paired with a target to catch the obvious gaming. "Click-through is the target; unsubscribe rate is the guardrail." The mechanism behind all three is Goodhart's law, and the practical rule is that a target without a guardrail will be met in the cheapest available way.

Paper over: hide a problem with a superficial fix. "Raising the timeout papers over the contention." Kick the can down the road: defer rather than solve. "Another exception just kicks the migration down the road." Tax the happy path: degrade the common case for a rare one. "Do not tax the happy path for a 0.1 percent edge case." Pay down debt and debt service: "That integration consumes 20 percent of the team's capacity in debt service."

Of these, debt service is the one that changes outcomes, because a percentage of capacity is a number a finance-literate manager can act on, whereas "we have a lot of technical debt" is a mood.

Worked example

A team is late. Three diagnoses, in the order they usually get offered, and what the vocabulary does to the conversation.

Diagnosis one, the default: "The team needs to move faster; can we add two engineers?" Brooks's law says this makes it later, but that argument alone rarely wins because it sounds like an excuse.

Diagnosis two, better: "Let me look at where time actually goes before we add people." A week of measurement finds: median cycle time 9 days, of which 5.5 is waiting for review, 1 is waiting for a deploy slot, 2.5 is work. Six items in progress across four engineers.

Diagnosis three, the one that gets funded: "Cycle time is 9 days and under 3 of those are work, so this is not a capacity problem, it is a queueing problem, and adding people would add coordination tax to a system whose constraint is review. Three changes. A WIP limit of one per person, because by Little's Law cutting WIP from six to four should cut cycle time by roughly a third with no other change. A review rotation with a same-day expectation, which attacks the 5.5 days directly and costs nothing. And deploy on merge instead of the Thursday window, which removes the last day and is a no-regret move anyway. My prediction is cycle time under 4 days in six weeks, and my counter-metric is change failure rate, because the obvious way to hit that target dishonestly is to ship worse. If it does not move, my diagnosis was wrong and we should revisit headcount then, not now."

What made the third version work: it names the constraint, it prices the alternative (coordination tax), it cites a mechanism for the prediction rather than asserting one, it attaches a counter-metric, and it commits to a falsification condition. That last element is what distinguishes an analysis from an opinion, and it is what makes it safe for a manager to back you, because you have told them how they will know if you were wrong.

Production evidence

WIP limits and their effect on cycle time are the most empirically grounded item here. Little's Law is a theorem, not a heuristic, and its application to knowledge work is the foundation of Kanban practice; Daniel Vacanti's work on flow metrics documents the relationship in real delivery data. The prediction that halving WIP halves cycle time at constant throughput is arithmetic, which is why it is worth stating with confidence.

Toil's 50 percent cap is documented Google SRE practice: SRE teams are meant to spend at least half their time on engineering work, and exceeding the toil budget is treated as a signal to hand operational load back to the development team. The enforcement mechanism is the interesting part rather than the number: a cap with no consequence is a preference.

The DRI convention is long-established Apple practice, widely reported and widely copied; its function is that every item on a meeting agenda has one name against it.

Theory of constraints comes from manufacturing (Goldratt's The Goal, 1984) and reached software through The Phoenix Project. The transfer is legitimate because the underlying mathematics is queueing theory, which does not care whether the items in the queue are car parts or pull requests.

Team Topologies' cognitive-load-based team sizing has been adopted publicly as the basis for platform charters at several large organisations, and the associated claim, that a platform's job is to reduce the cognitive load of stream-aligned teams, is what distinguishes a platform team from an infrastructure team in most modern charters.

The debate

Are WIP limits universally good? No, and the exception matters. WIP limits assume work is blockable and that a blocked person can help elsewhere. In a team with extreme specialisation (one person who can touch the ML model, one who can touch the iOS app), a strict WIP limit idles people, because the work they could pull is work they cannot do. The correct response is to treat that as the finding rather than to abandon the limit: the specialisation is the constraint, and the fix is cross-training or a different team boundary, both of which take a quarter. My position: introduce the WIP limit, expect it to make specialisation visible and uncomfortable, and use that visibility as the argument for the structural fix. Do not set the limit so low that it produces idleness in month one; start at roughly one and a half items per person and tighten.

Is "undifferentiated heavy lifting" a good reason to buy? It is a good frame and a bad conclusion, because it smuggles in an assumption about where your differentiation is, and that assumption is exactly the strategic question. The version I would defend: buy when the capability is not differentiating and the managed option's constraints do not bind you and the exit cost is bounded. All three, because the common failure is buying something genuinely undifferentiated whose constraints turn out to bind hard eighteen months later, at which point the switching cost is the whole argument. Name the exit cost when you make the recommendation.

Does "disagree and commit" belong in a healthy team? Yes, with a limit worth stating. It is the correct resolution when a decision must be made, the disagreement has been genuinely heard, and the decision is reversible enough that being wrong is survivable. It is the wrong resolution when used repeatedly on the same person, which is how you convert a dissenter into someone who has stopped speaking, and when applied to one-way doors, where the cost of overriding a well-founded objection is unbounded. The health check: how often has the person invoking it been on the other side of it? If a leader always asks others to disagree and commit and never does so themselves, the phrase has become a euphemism.

Should individual metrics ever be used? Covered as a position elsewhere in this book and worth restating in the vocabulary frame: individual output metrics are proxy metrics for something (impact) that is not measurable at the individual level in collaborative work, they are subject to Goodhart within one cycle, and they tax exactly the glue work that does not appear in any of them. Use them privately as a signal to look, never publicly as a judgement. The one legitimate published exception is metrics about the system that happen to be per-person, such as on-call load, where the point is to detect unfairness rather than to rank.

Follow-up Q&A

How do you find the constraint without instrumenting everything? Look for the queue. The constraint is almost always immediately upstream of the longest wait, and you can find it by walking a handful of recently completed items backwards and marking timestamps at each state change. Ten items done by hand in an afternoon is enough to find it, and it beats a dashboard project that takes a quarter. A useful shortcut: ask the team where work waits, then verify. They usually know, and the verification is what makes it actionable to people outside the team.

A platform team is being treated as a ticket queue. What do you change? That is the "force multiplier versus service desk" failure and it has a structural cause: the platform is supplying labour rather than capability, so demand scales with the number of consuming teams. The fix is to move up the interaction modes: turn the top ticket categories into self-service, so the team consumes a product rather than a person's time, and be explicit that the paved road is the supported path while off-road use is unsupported. The measure to watch is the ratio of self-service actions to tickets, and if it is not moving, the self-service path is not good enough and the tickets are telling you exactly which part.

How do you introduce a mechanism without adding bureaucracy? Three tests before adding one. Does it have a single owner who would notice its absence? Does it produce an artifact someone outside the team reads? Does it have a removal condition, a statement of what would have to be true for us to stop doing it? A mechanism failing the third test is how bureaucracy accumulates, because nothing in an organisation is ever removed for lack of a reason to keep it. Attaching an expiry or a review date at creation is the cheapest possible defence, and it costs one sentence.

What is a closed loop and why does it matter for ML systems specifically? A closed loop is one where outcomes feed back into future decisions rather than being observed and forgotten. "Recommendation evaluation needs a closed loop from impressions through to model changes." It matters disproportionately in ranking and recommendation because the system's own output shapes the data it will train on next, so an open loop does not merely fail to improve, it degrades: you learn from a distribution you created, which is the feedback-loop problem behind popularity bias. The lead-relevant question is whether anyone owns the loop end to end, because the loop typically crosses a team boundary (serving, logging, training) and a loop with three owners has none.

What is the difference between an operating mechanism and a meeting? An operating mechanism is a recurring process with a named owner, a defined input, a defined output and a decision that gets made. A meeting is a slot in a calendar. "The dashboard is not the solution; the weekly review with a named owner and a written decision is the operating mechanism." The test: if nobody prepared, would the session still produce a decision? If yes, it is a meeting and it should be an email. If the absence of preparation would be noticed, it is a mechanism.

How do you tell essential complexity from accidental complexity in practice? Ask whether a competitor solving the same problem with a completely different stack would also face it. Exactly-once financial posting: yes, everyone faces it, essential. Three serialisation formats because of a historical migration: no, accidental. The test is imperfect and it is fast, and it usually settles the argument, because accidental complexity tends to have a date attached to its origin and essential complexity does not.

Common misconceptions

"Adding people increases capacity." It increases capacity only if the constraint is labour and the work partitions. Otherwise it adds coordination tax against unchanged throughput, which is Brooks's law with its mechanism attached.

"A DRI means one person does the work." It means one person is accountable for the outcome and for making sure the decisions get made. They may do none of the work.

"Toil is any work I dislike." Toil has a definition, and it is manual, repetitive, automatable, tactical, without enduring value, and scaling with growth. Difficult non-repetitive work is not toil, and calling it toil devalues the term when you need it.

"Cognitive load is about how smart the team is." It is about how much system there is. A brilliant team of four cannot operate twelve services well, and framing this as a capability question rather than a boundary question is how leads get talked into unsustainable ownership.

"A leading indicator is just an early metric." It has to be predictive, which requires evidence that it moved before the outcome moved in the past. A metric that is merely earlier is just noise you receive sooner.

Interview delivery note

The sentence with the highest return on this page, because it reframes almost any delivery question: "Before we talk about capacity, I want to know where the time actually goes, because in most teams I have seen, most of cycle time is queueing rather than work, and those have completely different fixes." It is true, it is checkable, and it moves the conversation from a resource negotiation to a diagnosis, which is the ground you want to be on.

The senior-to-lead separator across this vocabulary is whether you name the cost that lands on someone else. A senior engineer optimises their team's throughput. A lead says "this decision reduces our coordination tax and increases the platform team's operational tax, so we should check with them before committing", and that sentence is the whole job in miniature: seeing the system past your own boundary, pricing the effect, and routing the decision to the people who should make it.

Further reading

• Matthew Skelton and Manuel Pais. Team Topologies. IT Revolution, 2019. Cognitive load as a boundary constraint, and the four team types with three interaction modes.
• Eliyahu Goldratt. The Goal. North River Press, 1984. The theory of constraints as a novel, which sounds unpromising and is the reason the ideas travelled.
• Betsy Beyer et al. Site Reliability Engineering. O'Reilly, 2016. Chapter 5, "Eliminating Toil", including the definition and the 50 percent cap.
• Daniel Vacanti. Actionable Agile Metrics for Predictability. 2015. Flow metrics, cycle-time distributions and Little's Law applied to real delivery data.

Leadership

The chapter where staff and team lead candidates most often sound generic. Everything here should become a concrete story or a concrete practice you can describe in ninety seconds, with a number in it.

Two structural habits carry most of the weight. First, tell stories in SCOR rather than STAR: Situation, Complication, Options, Result and reflection. The Options slot is the whole game, because it is what makes a story sound like judgment rather than a resume bullet. Second, for any role-play, state your first move, the information you would gather, and the line you would not cross. That three-part structure turns a vague answer concrete.

What this chapter covers

• [done] Capacity math and forecasting covers the three-bucket budget and forecasting with cycle-time percentiles instead of story points
• [done] On-call design covers rotation size, page budget, interrupt shield and toil cap
• [done] Unblocking: the four blocker types
• [done] Growing people covers the skill matrix, stretch ratio, the delegation ladder and SBI feedback
• [done] PR review as a leadership lever covers the SLA, PR size, the comment taxonomy and review order
• [done] Promotions and the calibration room
• [done] Product partnership: options with costs, and owning the non-functional requirements
• [done] Retention and motivators
• [done] Hiring: scorecard first, defending the bar
• [done] Written-first culture, ADRs, managing up
• [done] Managing former peers, and glue work
• [done] Legacy modernisation as a narrative
• [done] The toxic code reviewer
• [done] Making the reliability investment case
• [done] The engineer who has missed three commitments
• [done] The impossible date
• [done] Two teams building the same service
• [done] Promotion when they are one level short
• [done] Building a story portfolio
• [done] The underperformance sequence
• [done] The AI-era review queue
• [done] The metrics a lead watches
• [done] A PM promises a date
• [done] Inheriting a team with low morale

Source: §8, §23, §38.6, §48.

Capacity math and forecasting with percentiles

What it is

Two related answers a lead has to give in numbers rather than adjectives: how much can this team take on, and when will this be done.

Capacity math is the honest conversion from headcount to available project work, plus a declared split of that work across categories. Forecasting with percentiles replaces estimation with measurement: you sample the team's actual historical throughput and simulate forward, producing a date distribution rather than a date.

The two things people say, and what to say instead:

"We have 7 engineers, so we have 7 engineers of capacity."
   -> ~3.5 to 4.5 engineers of project capacity, and here is the
      arithmetic.

"That'll take about six weeks."
   -> "P50 is 24 March, P85 is 11 April, assuming scope is frozen
      and the team stays at 7. Each additional must-have of this
      size moves P85 by about a week."

What this is confused with: estimation. An estimate is a forecast produced by opinion. A percentile forecast is produced from the team's own delivery history, which means it already contains the interruptions, the sick days and the underestimation bias, none of which an estimate contains.

Also confused: velocity and capacity. Velocity is an output measurement in a unit (points) that is not comparable across teams and drifts within one. Capacity is an input budget in person-days. Forecasting from throughput in items per week avoids the points question entirely.

The problem it solves

Two failures, and they compound into the same outcome: a team that looks slow and a lead who cannot explain why.

Failure 1: unbudgeted work.

Team of 7. Commitments made as if 7 people work on the roadmap.

What actually happens in a week:
  on-call                    1 person, largely consumed
  interrupts and support     ~8 person-days across the team
  security patching, library
    and platform upgrades    ~3 person-days
  interviews, onboarding     ~2 person-days
  meetings and ceremony      ~5 person-days
  vacation/holiday (annual
    average)                 ~3 person-days

35 nominal person-days - 26 = 9 person-days of roadmap work.

The roadmap was planned against 35. The team delivers 9. Everyone
concludes the team is slow, including the team.

The work did not disappear; it was never on the plan. And because it was never on the plan, it is invisible in every conversation about why delivery is behind.

Failure 2: point estimates.

"Six weeks" is a single number with no probability attached, so:
  - the stakeholder hears a commitment
  - the team hears an aspiration
  - nobody knows whether it is a 50% date or a 90% date
  - when it slips, the conversation is about trust rather than
    about the distribution

And cycle time is right-skewed, so the mean is not the middle:

  cycle times (days), 40 recent items:
  1,1,2,2,2,3,3,3,3,4,4,4,4,5,5,5,6,6,6,7,7,8,8,9,9,10,11,12,
  13,14,16,18,21,24,28,33,41,52,68,91

  mean 14.2   median 6   P85 28   P95 60

A plan built on the mean is wrong in both directions: too
pessimistic for the typical item, wildly optimistic for the tail.

Mechanics

Capacity: the arithmetic

Start from nominal, subtract what is committed elsewhere.

  N engineers x 5 days                        = nominal person-days/wk

  minus vacation + statutory holidays
        (Ontario: ~2 weeks vacation + 9
         statutory days = ~19/260 days
         = 7.3%)                              ~ 7%
  minus sick and personal                     ~ 3%
  minus meetings and ceremony                 10-20%
  minus on-call (1 person, partly)            1/N of headcount
  minus interrupts and support                 measure it
  minus hiring, interviews, onboarding         measure it
  minus KTLO: upgrades, patches, compliance    measure it

FOCUS FACTOR = project days / nominal days.
Measured values in healthy teams: 0.50 to 0.65.
Anything above 0.70 usually means something is not being counted.

The number to defend is not the focus factor, it is the measurement. Estimating it produces an argument; measuring it for four weeks produces a fact.

How to measure it cheaply, without a timesheet culture:
  - label every ticket with one of the three buckets (below)
  - once a week, ask each person for a one-line split of their
    week in tenths. Takes 30 seconds each.
  - or sample: pick two random half-days a week and record what
    the team was doing.

Any of these beats an estimate, and the second one is the cheapest
that survives contact with a busy team.

The three-bucket budget

FEATURE      new capability, roadmap work, experiments
RELIABILITY  tech debt, refactoring, test infrastructure,
& INVESTMENT performance, developer experience, migrations
KTLO         support, incidents, on-call follow-up, dependency and
             platform upgrades, security patching, compliance,
             deprecation forced on you by other teams

A declared allocation, e.g. 60 / 20 / 20, reviewed quarterly.

The value is not the specific numbers, it is that the split is declared and then measured against reality.

The artifact that changes the conversation:

               declared   actual (last quarter)
  Feature          60%       38%
  Reliability      20%        9%
  KTLO             20%       53%

Reading: KTLO consumed 2.7x its budget, and it came out of both
other buckets. The team did not underdeliver on features by 22
points because it was slow.

The follow-up question is then the useful one: WHY is KTLO 53%,
and what would reduce it? In one case: 31 of the 53 points were
dependency upgrades forced by a platform team's deprecation
schedule, which was a cross-team negotiation, not a team
performance problem.

Presenting declared-versus-actual reframes "why are you behind" into "here is where the capacity went, and here is the decision I need from you." That reframing is most of the lead's job in a planning conversation.

Guardrails on the buckets:

- KTLO going up over time is the signal that reliability
  investment is too low. They trade against each other with a lag
  of a quarter or two.
- If reliability is the bucket that gets raided every time
  something is urgent, it is not a budget, it is a wish. Protect
  it by scheduling it as named work with owners, not as slack.
- A quarter with 0% reliability is a decision. Make it
  explicitly, with an expiry date, and say what it costs.

Forecasting: throughput and Monte Carlo

Stop summing estimates. Sample history.

import random

def forecast(weekly_throughput: list[int], remaining_items: int,
             trials: int = 10_000) -> dict[str, int]:
    """Monte Carlo forecast of weeks-to-completion.

    weekly_throughput: items completed per week, from the team's
        own history. 10 to 20 weeks is enough; more than ~26 starts
        including a team that no longer exists.
    remaining_items: count of items left. NOT points. The count is
        sufficient because the historical throughput already
        encodes the size distribution.
    """
    results = []
    for _ in range(trials):
        done, weeks = 0, 0
        while done < remaining_items:
            # Resample an actual past week. This carries the real
            # variance: holiday weeks, incident weeks, good weeks.
            done += random.choice(weekly_throughput)
            weeks += 1
        results.append(weeks)
    results.sort()
    return {
        "P50": results[len(results) // 2],
        "P85": results[int(len(results) * 0.85)],
        "P95": results[int(len(results) * 0.95)],
    }

Example. Last 14 weeks of completed items:
  [6, 4, 9, 3, 7, 5, 0, 8, 6, 5, 11, 4, 7, 6]
  (the 0 was an incident week; leave it in, it is real)

Remaining: 62 items.

forecast(history, 62) -> {'P50': 11, 'P85': 14, 'P95': 16}

Reported as: "Half the time we finish in 11 weeks. 85% of the time
within 14. There is a 5% chance it takes 16 or more. The zero-week
in our history is an incident week, and the simulation includes
the possibility of another one."

Why this beats estimate-summing:

- It uses the team's real variance, including the bad weeks.
- It requires no estimates at all, only a count of remaining
  items, which removes the estimation meeting.
- It produces a probability, so the stakeholder chooses their own
  risk tolerance rather than inheriting yours.
- It is trivially re-runnable weekly, so the forecast improves as
  the work proceeds instead of being defended.

The two inputs it needs, and the honest caveats:

1. A stable-ish item size. If items range from an hour to a
   month, resampling breaks. The fix is not estimation, it is
   splitting: cap item size at "a few days" and the distribution
   tightens on its own.
2. A known remaining COUNT. Scope discovery is the real
   uncertainty, and it is modelled by a split factor:
     "62 known items, and historically discovery adds 20-40%,
      so simulate 74 to 87."
   State the split factor separately, because it is the
   assumption most likely to be wrong.

Little's Law, and why cutting WIP is the lever

              WIP
cycle time = --------
             throughput

20 items in progress, 4 completed per week
  -> average cycle time = 5 weeks

Cut WIP to 8, throughput unchanged
  -> average cycle time = 2 weeks

Throughput usually goes UP when WIP goes down, because context switching and blocked-item overhead fall, but the law holds even if it does not: cutting WIP shortens cycle time arithmetically, and it costs nothing.

And the measurement that explains why:

FLOW EFFICIENCY = active time / total elapsed time

Typical measured values: 5% to 20%.

An item with a 20-day cycle time and 15% flow efficiency spent
3 days being worked on and 17 days waiting: for review, for a
dependency, for a decision, for an environment, for a deploy
window.

So "work faster" addresses 3 days out of 20. Removing queues
addresses 17.

This is the single most useful number a lead can produce, because it redirects an improvement conversation from effort to flow, and because 15 percent is a shocking enough number to be remembered.

Answering "when will it be done"

Never a bare date. The shape that works:

  "P50 is 24 March, P85 is 11 April. That assumes:
     - scope is the 62 items currently in the plan, and history
       says discovery adds 20 to 40 percent
     - the team stays at 7 with the current on-call load
     - the payments dependency lands by 3 March; if it slips a
       week, P85 moves about a week

   If you need 24 March at high confidence, the levers are:
   cut 15 items, or add the two contractors we discussed, which
   historically takes 4 to 6 weeks to show up in throughput."

Three properties make that answer defensible: a probability, the assumptions, and the levers. A date with no probability is a promise; a date with a probability is a forecast; a forecast with levers is a decision the stakeholder can participate in.

A worked example: a team that was not slow

A platform team of 7 engineers. Two quarters of missed roadmap commitments. The VP's framing entering the conversation was "the team's velocity has dropped and I need to understand why."

Four weeks of measurement, using the 30-second weekly split:

Nominal:        7 x 5 = 35 person-days/week

Measured average per week:
  on-call primary (1 person)          4.1 days consumed
  interrupts, support, Slack asks     6.8 days
  meetings, ceremony, planning        5.2 days
  interviews and onboarding           2.4 days
  vacation/holiday/sick               2.6 days
  dependency and security upgrades    3.9 days
  -------------------------------------------
  non-project total                  25.0 days
  ROADMAP CAPACITY                   10.0 days/week

Focus factor: 10/35 = 29%.

Twenty-nine percent is far below the 50 to 65 percent healthy band, which made the number an argument rather than an excuse.

Three-bucket split, from ticket labels over the previous two quarters:

               declared   Q1 actual   Q2 actual
  Feature          65%        41%         33%
  Reliability      15%         7%          4%
  KTLO             20%        52%         63%

KTLO rising from 52 to 63 percent across two quarters, with reliability falling to 4 percent, is the lagged trade in the guardrail above happening in real time.

Where the KTLO came from, itemised:

Of the 63 points of KTLO in Q2:
  27  dependency upgrades forced by the platform org's
      deprecation schedule (4 major runtime and framework
      upgrades in one quarter)
  16  support requests from 9 consuming teams, none of which had
      a self-serve path
  11  incident follow-up
   6  compliance evidence collection
   3  miscellaneous

Each line has a different owner and a different fix, which is the point of itemising rather than reporting a single KTLO number.

The three asks the lead made, each attached to a number:

1. "Four forced major upgrades in one quarter is 27 points of our
    capacity. Can the platform org stagger them across two
    quarters?"
   -> agreed. Two moved to Q3.

2. "Nine teams ask us the same six questions. 16 points a quarter
    is 1.1 engineers. Building the self-serve path is estimated
    at 3 weeks of one engineer, so it pays back in under a
    quarter."
   -> approved as named reliability work with an owner.

3. "Our on-call is a 4-person rotation, so each person is on call
    one week in four and loses most of it. Moving to a 7-person
    rotation across the two teams costs onboarding and returns
    ~2 person-days a week."
   -> deferred, revisited the following quarter.

Forecasting replaced the estimation meeting:

Before: a 3-hour estimation session per quarter, 7 people, output
        a point total and a date. 21 person-hours, and the date
        was wrong both quarters.

After:  count remaining items, run the simulation, report P50/P85.
        Re-run weekly, taking about 10 minutes.

First forecast, at the start of Q3:
  history (last 12 weeks completed): [5,3,8,2,6,4,7,5,6,3,9,4]
  remaining: 48 known items, discovery factor 25-40%
             -> simulate 60 to 67

  at 60 items: P50 = 12 weeks, P85 = 15
  at 67 items: P50 = 13 weeks, P85 = 17

  Reported: "P85 is 17 weeks, which is past the quarter. To land
  inside the quarter at P85 we need to be at about 45 items, so
  15 to 22 items have to come out. Here is the list, ranked by my
  read of value; I need you to choose."

The last sentence is what changed the relationship. The lead stopped defending a date and started presenting a scoping decision with a probability attached to each option.

And the flow-efficiency measurement, which produced the largest single improvement:

Sampled 30 completed items: elapsed time vs active time.
  median cycle time      14 days
  median active time      2.5 days
  FLOW EFFICIENCY        18%

Where the 11.5 waiting days went:
  4.1  waiting for code review
  3.2  waiting for a dependent team's API
  2.0  blocked on a decision
  1.4  waiting for a deploy window
  0.8  waiting for a test environment

Actions:
  - a review SLA (first response within 4 working hours), plus a
    daily 20-minute review slot on everyone's calendar
  - deploy windows removed for this service (a separate
    conversation, using the deployment-strategy capacity
    arithmetic)
  - a standing 15-minute weekly decision slot with the PM and
    the architect, with a written list

Six weeks later:
  median cycle time      14 -> 8 days
  flow efficiency        18% -> 31%
  throughput             5.2 -> 7.1 items/week

Nobody worked harder or longer.

Throughput rose 37 percent from removing queues, which is the concrete demonstration that the lever is flow and not effort.

Outcome after two quarters:

                    before      after
focus factor          29%         44%
KTLO share            63%         38%
reliability share      4%         17%
median cycle time   14 days     8 days
roadmap items per
  quarter               41         68
forecast accuracy   n/a         3 of 3 quarters landed inside
                                the P85 date

Forty-four percent is still below the healthy band and was reported as such, because the honest version of the story is that the team went from badly constrained to normally constrained, and claiming otherwise would have made the next quarter's asks harder to justify.

Production evidence

Little's Law is a theorem of queueing theory (Little, 1961) that holds for any stable system regardless of arrival distribution or service discipline, which is why cutting WIP shortens cycle time arithmetically rather than as an empirical tendency.

Daniel Vacanti's Actionable Agile Metrics for Predictability and Troy Magennis's forecasting work are the standard references for throughput-based Monte Carlo forecasting and for reporting percentiles rather than point estimates; both make the argument that item count plus historical throughput outperforms estimate-summing.

The Kanban community's flow metrics (cycle time, throughput, work in progress, flow efficiency, work item age) are the standard set, and flow efficiency measurements in the 5 to 20 percent range are consistently reported across organisations, which is what makes "most of cycle time is waiting" a general finding rather than one team's problem.

The DORA research programme measures lead time for changes as one of its four key metrics, and its consistent finding that batch size and WIP reduction correlate with delivery performance is the large-sample version of the flow argument.

Google's SRE practice of capping operational work at 50 percent is the best-known formal budget for one of these buckets, and the enforcement mechanism, overflow returns to the development team, is the part most imitations omit.

Ontario's Employment Standards Act sets the statutory vacation and public holiday entitlements that put a floor under the availability subtraction for a Toronto-based team, which is why the 7 percent figure is a legal fact rather than a planning assumption.

The debate

Story points or item counts? Item counts, forecast by Monte Carlo. Points attempt to normalise size so that summing works, and the normalisation is exactly the thing teams cannot do reliably; resampling historical throughput needs no normalisation because the size distribution is already in the history. The counter-argument, that points force a useful conversation about complexity, is real and is better served by splitting items until they are small, which tightens the distribution as a side effect.

Is a focus factor demoralising to publish? The opposite, in practice. A team told it is delivering 29 percent of nominal capacity hears an accusation; a team shown that 25 of 35 person-days are consumed by named, itemised, mostly external commitments hears an explanation. The risk is publishing the aggregate without the itemisation, which invites "so make the meetings shorter."

Should reliability be a fixed percentage? A declared percentage, defended, and revisited quarterly. The counter-argument, that reliability work should be justified case by case, sounds rigorous and fails in practice because each individual case loses to a feature with a date. A budget converts many losing arguments into one winnable one, which is the same reasoning as an error budget.

Do percentile forecasts survive contact with executives? Better than point estimates, provided you lead with one number. Report P85 as "the date," mention P50 as the optimistic case, and never present a distribution without a recommended commitment, because an executive asked to choose a percentile will reasonably ask what you would choose.

Is measuring flow efficiency worth the effort? For one sample of 30 items, yes, decisively. Continuous measurement is usually not worth it, because the number rarely moves without intervention and the actions it implies (review SLA, decision cadence, dependency management) are durable once taken. Measure it, act, re-measure in a quarter.

Does adding people help a late project? Not inside the forecast horizon, and the honest number is the ramp: new engineers typically show up in throughput after 4 to 8 weeks, and until then they consume the throughput of whoever onboards them. Say the ramp cost out loud, because "add people" is otherwise the first lever a stakeholder reaches for.

Follow-up Q&A

"How much capacity does a team of seven actually have?"

Roughly 10 to 22 person-days a week of project work out of 35 nominal, depending on load. Subtract vacation and statutory holidays, about 7 percent in Ontario; sick and personal, about 3; meetings and ceremony, 10 to 20; on-call, which consumes most of one person's week; and then the categories you have to measure rather than assume: interrupts and support, hiring and onboarding, and forced upgrades. A healthy focus factor is 50 to 65 percent. Anything above 70 usually means something is not being counted, and the number only carries weight if it is measured rather than estimated, which a weekly 30-second split per person is enough to do.

"What is the three-bucket budget for?"

To make the split between feature work, reliability investment and keeping-the-lights-on explicit, so that it can be compared against reality. The artifact that changes a planning conversation is declared-versus-actual: 60/20/20 declared against 38/9/53 actual says the team did not underdeliver on features by 22 points because it was slow, it did so because KTLO consumed 2.7 times its budget. Then the useful question is why, which needs the KTLO itemised, because forced dependency upgrades, support requests from consuming teams and incident follow-up have different owners and different fixes.

"How do you forecast without estimates?"

Resample the team's own weekly throughput. Take 10 to 20 weeks of items-completed-per-week, count the remaining items, and simulate: repeatedly draw random past weeks until the remaining count is consumed, and record how many weeks it took. Ten thousand trials gives a distribution, and you report P50, P85 and P95. It needs no estimates because the historical throughput already contains the size distribution, the interruptions and the bad weeks, including the incident week that shows as a zero. The two real assumptions are that item sizes are roughly stable, which you get by splitting rather than estimating, and the scope discovery factor, which you state separately because it is the assumption most likely to be wrong.

"Why is cutting work in progress the lever?"

Little's Law: cycle time equals WIP divided by throughput, and it holds for any stable system. Twenty items in progress at four completions a week is a five-week average cycle time; cutting to eight items makes it two weeks, arithmetically, with no change in how fast anyone works. Throughput usually rises as well because context switching and blocked-item overhead fall, but the shortening does not depend on that. It is the rare intervention that is free and immediate.

"What does flow efficiency tell you?"

The fraction of an item's elapsed time that was active work, typically 5 to 20 percent. An item with a 14-day cycle time and 18 percent efficiency spent about 2.5 days being worked on and 11.5 days waiting, for review, for a dependency, for a decision, for a deploy window, for an environment. That redirects the improvement conversation from effort to queues: working faster addresses 2.5 days, removing queues addresses 11.5. In one case a review SLA, a weekly decision slot and removing deploy windows took median cycle time from 14 days to 8 and throughput from 5.2 to 7.1 items a week, with nobody working longer.

"How do you answer 'when will it be done'?"

With a probability, the assumptions, and the levers. "P50 is 24 March, P85 is 11 April, assuming scope stays at the current 62 items with a historical discovery factor of 20 to 40 percent, the team stays at seven, and the payments dependency lands by 3 March. If you need 24 March at high confidence, the levers are cutting about 15 items, and here is my ranking, or adding people, which historically shows up in throughput after four to six weeks." A date without a probability is a promise; with one it is a forecast; with levers it is a decision the stakeholder makes with you.

Common misconceptions

"Seven engineers means seven engineers of capacity." It means roughly three and a half to four and a half, and the difference is itemisable.

"Velocity measures productivity." It measures output in a unit that is not comparable across teams and drifts within one. Throughput in items, plus resampling, avoids the question.

"Estimate better." Estimation error is not the main source of forecast error; scope discovery and variance are, and both are handled by a distribution rather than by a better point estimate.

"The mean cycle time is the typical cycle time." Cycle time is right-skewed, so the mean sits well above the median and describes neither the typical item nor the tail.

"Work faster." With flow efficiency at 15 percent, effort addresses 15 percent of elapsed time. Queues are the other 85.

"Add people to catch up." New engineers reduce throughput for four to eight weeks before they add to it, which usually places the benefit after the date you were trying to hit.

Interview delivery note

Say this verbatim: "A team of seven has about four engineers of project capacity, and the way to make that credible is declared-versus-actual on three buckets. Sixty-twenty-twenty declared against thirty-eight, nine, fifty-three actual turns 'why are you behind' into 'here is where the capacity went and which of these do you want me to change'." It shows you convert a performance accusation into a resourcing decision with an artifact.

The senior-versus-staff separator is flow efficiency. A senior lead reports cycle time. A staff lead samples 30 items, finds that 2.5 of 14 days were active work, itemises where the other 11.5 went, review queues, dependency waits, decision latency, deploy windows, and then fixes the queues rather than the effort. Reporting that throughput rose 37 percent with nobody working longer is the version of this that persuades, because it makes the lever visible.

The second signal is refusing to give a bare date. Answering with P50 and P85, the assumptions behind them, and the specific levers with their costs, including that added people take four to eight weeks to appear in throughput, moves the conversation from a commitment you will be held to into a scoping decision the stakeholder makes with you.

Further reading

• Daniel Vacanti, Actionable Agile Metrics for Predictability, for throughput-based forecasting and the flow metric set.
• Troy Magennis's forecasting materials and Monte Carlo spreadsheets, for the simulation approach with split factors for scope discovery.
• Little, "A Proof for the Queuing Formula L = λW" (1961), for why the WIP relationship holds independent of distribution.
• Google's SRE Book on the 50 percent cap on operational work, including the overflow mechanism.
• The metrics a lead watches page, for how these numbers sit alongside the DORA set.

On-call design: rotation, page budget, interrupt shield, toil cap

What it is

On-call design is the set of explicit numbers that make production responsibility sustainable rather than attritional. Four of them, and each has a defensible target:

ROTATION SIZE     how often each person is on call.
                  1 week in N. N >= 6 is the sustainable floor for
                  a 24/7 rotation.

PAGE BUDGET       how many pages a shift may produce before the
                  rotation is declared broken. Google's SRE
                  guidance: no more than 2 events per 12-hour
                  shift, so there is time to investigate properly.

INTERRUPT SHIELD  a separate, rotating role that absorbs
                  non-urgent interrupts so the rest of the team
                  has uninterrupted time. Distinct from on-call.

TOIL CAP          a ceiling on operational work as a fraction of
                  the team's time, with a defined overflow
                  mechanism when it is exceeded. Google's number
                  is 50 percent.

What this is confused with: an on-call schedule. A schedule says who is responsible. A design says how much responsibility that is, what happens when it exceeds the budget, and who pays for reducing it. Most organisations have a schedule and no design, which is why the load only ever goes up.

Also confused: on-call and support. On-call is production incidents at any hour. Support is questions, requests and small fixes during working hours. Putting both on one person means the incident responder is also the person answering Slack, and neither job gets done.

The problem it solves

A rotation with no budget degrades monotonically, because every party's incentive points the same way.

A new alert is added:      free, to the person adding it
An alert that fires often
  but is rarely actionable: nobody owns deleting it
A service is onboarded to
  the rotation:            free, to the team handing it over
Fixing the underlying
  cause:                   costs a sprint, competes with features

So pages accumulate and nothing removes them.

And the cost is paid in a currency nobody puts on a dashboard:

A 4-person rotation, 24/7, at 11 night pages per week.

Each person is on call 13 weeks a year.
Each on-call week: ~2.75 night pages.
A night page costs the responder the rest of that night's sleep
plus a degraded following day.

Annual per person: ~36 disrupted nights, concentrated into 13
weeks.

Observable consequences, in order of appearance:
  1. people decline to join the team
  2. the best responders leave first, because they have options
  3. the rotation shrinks to 3, so each person is on call 1 week
     in 3
  4. the load per person rises by a third, and step 2 repeats

The failure mode is a doom loop, and the loop's gain is greater
than 1 once the rotation drops below about 5.

The design's job is to break that loop with numbers that make the load visible and give the excess somewhere to go.

Mechanics

Rotation size

N people, 24/7 primary rotation:
  each person is on call 1 week in N = 52/N weeks per year

  N=3   17.3 weeks/yr   one week in three. Unsustainable.
  N=4   13.0            common, and the level where people leave
  N=6    8.7            the practical floor
  N=8    6.5            comfortable
  N=12   4.3            people lose familiarity with the systems

The two failure directions:
  TOO SMALL  burnout, and the doom loop above
  TOO LARGE  each person is on call so rarely that they have not
             seen the system change since their last shift, so
             every page is a cold start

Target 6 to 8 for a 24/7 rotation. Below 6, the answer is not a better schedule, it is more people or fewer hours of coverage.

Secondary rotations matter more than people expect:

PRIMARY    takes the page
SECONDARY  escalation after N minutes unacknowledged, and a
           second pair of hands for a long incident

A secondary is not optional above a certain severity, because
a single primary who is asleep, driving, or already handling
one incident is a single point of failure with a human in it.

The cost is that being secondary is also a constraint on your
evening. Count it: a 6-person rotation with primary and
secondary means each person is constrained 2 weeks in 6, not 1.

That last line is the one omitted from most rotation arithmetic, and it means a "6-person rotation" with a secondary is a 1-in-3 constraint.

Follow-the-sun, and what it actually requires

Removes night pages entirely. Requires:
  - teams in 2 or 3 timezones roughly 8 hours apart
  - each capable of handling the same incidents, which means real
    knowledge distribution, not a runbook handoff
  - a genuine handoff protocol: open incidents, degraded
    components, changes in flight, what to watch
  - alignment of ownership, so a region is not paging about a
    service it cannot change

Where it fails: two regions with 12 hours between them and no
overlap, so the handoff is asynchronous and context is lost. And
a "follow the sun" arrangement where one region owns the code
and the other owns the pager, which is just outsourcing the pain.

The page budget, and enforcing it

The target: <= 2 paging events per 12-hour shift.

The reason for the specific number, from Google's SRE practice:
a page should be followed by a proper investigation and a
follow-up, and that takes hours. More than two per shift and the
responder is triaging, not resolving, so the underlying causes
are never removed and the rate never falls.

The budget only does work if exceeding it has a defined consequence:

The mechanism that works:

  IF pages per shift exceeds the budget for 2 consecutive weeks
  THEN the next sprint's reliability bucket is spent on the top
       page sources, and feature commitments are reduced
       accordingly.

That is an ERROR-BUDGET-SHAPED policy applied to human load, and
it works for the same reason: it converts many individually
losing arguments ("can we fix this alert?") into one policy
argument that was won in advance.

The weekly pager review is the operational half:

Every page from the past week, classified in a 30-minute meeting:

  ACTIONABLE     a human had to decide or act. Keep the alert.
  AUTOMATABLE    the response was mechanical (restart, scale,
                 failover). Automate the response, keep a
                 low-priority ticket for visibility.
  SHOULD BE A
  TICKET         real but not urgent. Downgrade to a ticket. This
                 is usually the largest category.
  SHOULD BE
  DELETED        not actionable, not urgent, or duplicative.
  FALSE          the alert fired without the condition being
                 true. Fix the alert or the threshold.

Every page leaves the meeting with an owner and one of those five
dispositions. A page that is discussed and left alone is the
default failure of this meeting.

Alert criteria worth stating as a rule:

A page must be:
  URGENT      it cannot wait until morning
  ACTIONABLE  there is something a human can do now
  NOVEL       it is not the fifth copy of the same condition

Anything failing one of the three is a ticket, a dashboard, or a
deletion. Symptom-based alerts (see USE and RED) satisfy these
far more often than cause-based ones, because a cause-based
alert fires whether or not users are affected.

The interrupt shield

Separate the interrupt-absorbing role from the pager.

Names vary: "support engineer", "sheriff", "batman", "goalie".
The design:
  - one person per week, rotating, DIFFERENT from the on-call
    primary
  - owns: incoming questions, small bug reports, triage of new
    tickets, the shared inbox and the team's Slack channel
  - explicitly NOT expected to make roadmap progress that week
  - has a written escalation path for anything they cannot
    answer in 15 minutes

The arithmetic that justifies it:

Research on interrupted work (Mark, Gudith and Klocke, CHI 2008)
found it takes on average about 23 minutes to return to the
original task after an interruption.

A team of 7 with 30 interrupts a week, spread across everyone:
  30 x 23 min = 11.5 hours of refocus cost, distributed as
  small losses nobody attributes to interruption.

Concentrated on one person:
  that person loses their week (which is planned for)
  the other 6 lose nothing
  -> the team recovers roughly 11.5 hours a week of focus time,
     at the cost of 1 planned person-week in 7.

The failure mode: the shield is assigned and then everyone is still messaged directly. The fix is social and mechanical: a single channel, a bot that redirects direct messages, and the shield answering publicly so the answer is findable next time.

Second-order benefit: the shield produces the documentation backlog. A person answering the same question three times writes it down, because they are the one who will be asked again.

The toil cap

TOIL is operational work that is manual, repetitive, automatable,
tactical, devoid of enduring value, and scales linearly with
service growth.

The cap: <= 50 percent of a person's time. Google's SRE model
enforces it with a defined overflow: when an SRE team's toil
exceeds the cap, work is handed BACK to the product development
team until it is under control.

The overflow mechanism is the part that matters, and it is what
most imitations omit. A cap with no consequence is a preference.

A cap you can actually operate in a non-SRE organisation:

- Measure toil per person per week from the three-bucket split
  (see capacity math).
- Declare the cap in the team charter: KTLO <= 30 percent, say.
- Define the overflow: sustained breach for 2 sprints means the
  next sprint's feature commitment is reduced and the reliability
  bucket doubled, with the lead's decision documented, not
  negotiated per instance.
- Review quarterly with the number, not the feeling.

The rest of the design

COMPENSATION
  Paid on-call, or time in lieu, or both. It is the honest lever,
  it prices the burden so the organisation feels it, and it makes
  the rotation something people will join. In many jurisdictions
  standby pay also has legal dimensions worth checking.

HANDOFF
  A written handoff at the end of each shift: open incidents,
  degraded components, changes landing, things to watch, and any
  alert that fired more than twice. 10 minutes, and it is the
  difference between a rotation and a relay of cold starts.

RUNBOOKS
  Every alert links to a runbook. A runbook that has not been
  used in 6 months is probably wrong; the pager review is where
  that gets caught.

ONBOARDING
  Nobody takes a primary shift alone until they have shadowed at
  least two and been secondary for one. And a new joiner's first
  shift is paired.

BLAMELESS FOLLOW-UP
  Every page above a severity threshold gets a written follow-up.
  Not a full postmortem for a routine page, but a paragraph with
  an action, because the action is the only thing that reduces
  next quarter's load.

A worked example: a rotation that shrank until it broke

A data-platform team. 5 engineers, 24/7 rotation, ownership of 6 services including the ingestion pipeline everything else depended on.

The state at the start:

Rotation                     5 people, primary only, no secondary
Pages per week                        47
Pages between 22:00 and 08:00         11
Median pages per 12-hour shift       3.4   (budget: 2)
Actionable rate (from a sample)       21%
Interrupt requests per week          ~34   (Slack, direct)
Attrition in the prior 12 months       3   (of 8; the rotation had
                                            been 8)
Open reliability tickets              61, none in the current sprint

Twenty-one percent actionable means four out of five pages did not need a human at that moment, which is the whole finding in one number.

The pager review, four weeks of pages classified:

188 pages classified:

  40   ACTIONABLE       genuine, human decision required
  61   AUTOMATABLE      "restart the consumer", "scale the pool",
                        "clear the stuck partition". Mechanical
                        response, done by hand every time.
  52   SHOULD BE A
       TICKET           real, not urgent: a disk at 78%, a certificate
                        expiring in 21 days, a batch job 40 minutes
                        late with a 6-hour SLA
  27   DELETED          not actionable at all: "CPU > 80%" on a
                        service that is supposed to run hot
   8   FALSE            a threshold that fired on a monitoring gap

Sixty-one automatable pages is a robot's job being done by a person at 3am, and 52 tickets-in- disguise is an alert-severity problem, not a reliability problem.

The work, sequenced by cost:

WEEK 1: DELETE AND DOWNGRADE. Free.
  - 27 deletions, agreed in the review
  - 52 downgraded to tickets with a daily digest instead of a page
  - 8 threshold fixes
  -> pages/week 47 -> 18, in one week, with no engineering work.

WEEKS 2-6: AUTOMATE THE MECHANICAL ONES.
  - stuck-partition detection and reset: 3 days
  - consumer restart on a defined health signal, with a
    circuit breaker so it does not loop: 4 days
  - connection-pool autoscaling: 2 days
  - each automation pages ONLY if it fails or fires more than
    3 times in an hour, which preserves the signal
  -> pages/week 18 -> 9

WEEKS 4-12: THE TOP THREE ACTIONABLE CAUSES.
  Of the 40 actionable pages, 23 came from three causes:
    - an unpartitioned table causing lock contention at month end
    - a dependency with no timeout, so its slowness became ours
    - a manual certificate renewal process
  Fixed: partitioning, timeouts plus a bulkhead, automated cert
  renewal.
  -> pages/week 9 -> 6

The 27-deletion, 52-downgrade week is the highest-return work in the whole programme and cost nothing but a meeting, which is the general shape: most pager pain is classification, not reliability.

Then the structural changes:

ROTATION: merged with the adjacent streaming team's rotation.
  5 + 4 = 9 people. Each person 1 week in 9 primary, and a
  secondary rotation offset so nobody is primary and secondary
  in consecutive weeks.
  Cost: 6 weeks of cross-training, 2 shadow shifts each, and a
  shared runbook set. Real, and it was the largest single cost.

INTERRUPT SHIELD: introduced separately from on-call.
  One person per week, not the on-call primary, owning the
  team channel and triage, with no roadmap commitment.
  34 interrupts/week x 23 min = ~13 hours of refocus cost
  previously spread across the team, now absorbed by one
  planned person-week.

PAGE BUDGET with an overflow rule:
  "<= 2 pages per 12-hour shift. Two consecutive weeks above it
   and the next sprint's reliability allocation doubles, with the
   feature commitment reduced accordingly."
  Written into the team charter and agreed with the PM in
  advance, which is the only time that agreement is cheap.

COMPENSATION: on-call stipend introduced, plus a day in lieu for
  any shift with a page between midnight and 06:00.

Agreeing the overflow rule before it fires is the whole trick, because after it fires the conversation is about a specific feature slipping, and it will lose.

Twelve months later:

                              before      after
rotation size                      5           9 (+ secondary)
on-call frequency         1 wk in 5   1 wk in 9 primary
pages per week                    47           6
night pages per week              11         0.4
median pages per shift           3.4         0.5
actionable rate                  21%         76%
interrupts hitting the
  wider team                  ~34/wk       ~4/wk
KTLO share of capacity           58%         26%
attrition (12 months)              3           0
open reliability tickets          61          19

The actionable rate is the number to watch, not the page count. A page count can be reduced by deleting alerts you needed; an actionable rate rising from 21 to 76 percent says the remaining pages are the right ones.

One thing that got worse, stated plainly:

Merging the rotations meant each person was on call for 11
services instead of 6, and mean time to acknowledge rose from
4.1 to 6.8 minutes in the first quarter, because responders were
less familiar with half the surface.

It returned to 4.4 minutes over the following two quarters as
cross-training took hold and runbooks improved.

This was raised as an objection before the merge, was correct,
and was accepted as a transitional cost against a rotation that
was losing three people a year.

Production evidence

Google's SRE Book specifies both numbers used above: a target of no more than two paging events per 12-hour on-call shift, with the rationale that a page deserves a proper investigation and follow-up, and a 50 percent cap on operational work with an explicit overflow mechanism that returns work to the product development team. The overflow is the part that makes the cap enforceable.

Google's definition of toil (manual, repetitive, automatable, tactical, without enduring value, and scaling linearly with service growth) is the operative one, and its "scales linearly with growth" clause is what distinguishes toil from ordinary operational work.

Mark, Gudith and Klocke, "The Cost of Interrupted Work" (CHI 2008) is the source for the roughly 23-minute resumption time after an interruption, which is the arithmetic behind concentrating interrupts on one person rather than distributing them.

PagerDuty's published operational guidance on rotation design, escalation policies and secondary rotations documents the single-primary risk and the standard remedy, and their incident-response documentation is the widely used reference for handoff practice.

Symptom-based alerting, alerting on user-visible effects rather than on causes, is the position taken in both Google's SRE material and in the USE and RED method literature, and it is the mechanism behind a high actionable rate.

Published on-call compensation practice varies widely by jurisdiction and employer, but paid standby is common in European engineering organisations and is increasingly so in North America, which is the evidence that pricing the burden is a live lever rather than a theoretical one.

The debate

Is a 6-person minimum too rigid? It is a floor, not a target, and the honest version is that below 6 you are choosing between reducing coverage hours, merging rotations, or accepting attrition. The counter-argument, that a small team with almost no pages can run a 4-person rotation comfortably, is true, and the test is the page rate rather than the headcount: 4 people with 2 pages a month is fine, 4 people with 47 pages a week is the doom loop.

Should on-call be paid? Yes, and the argument that it is "part of the job" ignores that it is a constraint on non-working hours. Payment does two things: it compensates the individual, and it puts the cost on the organisation's books where it can be compared against the cost of fixing the pages. An unpriced burden is optimised away last.

Should the interrupt shield be the same person as on-call? No. Combining them means the person handling a production incident is also the person expected to answer questions, and the incident loses. On small teams where separating them is impossible, the honest answer is to reduce one of the two loads rather than to pretend one person can do both.

Is a page budget gameable? Yes, by deleting alerts that were needed, which is why the actionable rate is the companion metric. A falling page count with a falling actionable rate means you deleted the useful ones. Report both.

Does follow-the-sun solve this? It removes night pages, which is the largest single harm, and it requires genuine capability in each region plus a real handoff. The failure is a region that owns the pager without owning the code, which relocates the pain without reducing it and adds a handoff to every incident.

Should automation be preferred to fixing the cause? Automating a mechanical response is the right immediate move, because it removes the 3am human, and it is not a fix. The risk is that automation hides the signal, so an automated remediation should still record its occurrences and page if it fires repeatedly or fails, which keeps the underlying rate visible for the quarterly review.

Follow-up Q&A

"What makes an on-call rotation sustainable?"

Four explicit numbers. A rotation of at least six for 24/7, because one week in four is where people begin to leave and the rotation then shrinks, raising the load, which is a loop with gain above one. A page budget of about two events per twelve-hour shift, so there is time to investigate rather than triage. An interrupt shield that is a separate person from the on-call primary. And a cap on operational work with a defined overflow, because a cap without a consequence is a preference. Every one of these is a number in a charter, agreed in advance, rather than a judgment made under pressure.

"What do you do first with a rotation getting 47 pages a week?"

Classify four weeks of pages in a meeting, into actionable, automatable, should-be-a-ticket, delete and false. In one case that was 40, 61, 52, 27 and 8 out of 188. The deletions and downgrades take one meeting and no engineering work and took the rate from 47 a week to 18. Then automate the mechanical responses, which is a robot's job being done by a person at 3am, and only then work the top actionable causes, which is the expensive part. Most pager pain turns out to be a classification problem, not a reliability problem.

"Why is the actionable rate more important than the page count?"

Because the page count is trivially gameable by deleting alerts you needed. An actionable rate, the fraction of pages where a human genuinely had to decide or act, tells you whether the remaining pages are the right ones. Going from 21 percent to 76 percent while the count fell from 47 to 6 is a strong result; the same count reduction with a falling actionable rate would mean you had deleted signal. Report them together, always.

"Why separate the interrupt shield from on-call?"

Because they are different jobs with different urgency, and combining them means the person handling a production incident is also the person expected to answer questions in Slack. The arithmetic also favours concentration: an interruption costs roughly 23 minutes of resumption time, so 30 interrupts a week spread across seven people is about eleven and a half hours of refocus cost invisibly distributed, whereas concentrating them on one planned person-week costs one week and returns that time to the other six.

"What makes a toil cap enforceable?"

The overflow mechanism. Google's SRE model caps operational work at 50 percent and, when a team exceeds it, hands work back to the product development team until it is under control. Most imitations copy the number and omit the consequence, which makes it advisory. A workable non-SRE version is a declared KTLO ceiling in the charter, measured from the three-bucket split, with a written rule that a sustained breach doubles the next sprint's reliability allocation and reduces the feature commitment accordingly, agreed with the product partner in advance, because after it fires the conversation is about a specific feature slipping and it will lose.

"What criteria should a page meet?"

Urgent, actionable and novel. If it can wait until morning it is a ticket. If there is nothing a human can do right now it is a dashboard or an automation. If it is the fifth copy of the same condition it should be deduplicated. Symptom-based alerts, on user-visible effects, satisfy these far more often than cause-based ones, because a cause-based alert fires whether or not anyone is affected, which is where most of the non-actionable volume comes from.

Common misconceptions

"A rotation is a schedule." A schedule says who. A design says how much, what happens when it is exceeded, and who pays to reduce it.

"Fewer pages is the goal." Fewer non-actionable pages is the goal. A count that falls while the actionable rate falls means signal was deleted.

"On-call is part of the job, so it should not be paid." It is a constraint on non-working hours, and pricing it is what puts the cost on the organisation's books next to the cost of fixing it.

"Automating the response fixes the problem." It removes the human at 3am, which is worth doing immediately, and it can hide the underlying rate unless the automation records and escalates on repetition.

"Small teams cannot afford an interrupt shield." Small teams pay for interrupts anyway, spread thinly and unmeasured. The shield makes the cost one planned person-week instead of an unattributed loss across everyone.

"A 50 percent toil cap is the control." The overflow mechanism is the control. The number without it is a preference.

Interview delivery note

Say this verbatim: "The first move on a broken rotation is not reliability work, it is classification. We classified four weeks of pages into actionable, automatable, ticket, delete and false, and the deletions and downgrades alone took us from 47 pages a week to 18 in one meeting with no engineering work. Twenty-one percent of pages were actionable, which meant four out of five did not need a human at that moment." It shows you diagnose before you spend, and the numbers are memorable.

The senior-versus-staff separator is agreeing the overflow rule before it fires. A senior lead proposes a page budget. A staff lead writes into the charter, with the product partner's agreement in advance, that two consecutive weeks above budget doubles the next sprint's reliability allocation and reduces the feature commitment, because after the budget is breached the conversation is about a named feature slipping and it will lose. Converting many individually losing arguments into one policy argument won in advance is the same mechanism as an error budget, and saying so shows you know why it works.

The second signal is naming a cost your own change created. Merging two rotations took mean time to acknowledge from 4.1 to 6.8 minutes for a quarter, because responders covered eleven services instead of six. That objection was raised before the merge, was correct, and was accepted against a rotation losing three people a year. Volunteering the downside makes the rest of the numbers credible.

Further reading

• Google's SRE Book, chapters on being on-call and on eliminating toil, for the two-events-per-shift guidance, the toil definition and the 50 percent cap with its overflow mechanism.
• Mark, Gudith and Klocke, "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008), for the resumption-time figure behind the interrupt shield.
• PagerDuty's operations documentation on rotation design, escalation policies and handoffs.
• The incident management page, for what happens after the page is acknowledged.
• The capacity math and forecasting page, for measuring the KTLO share that a toil cap constrains.

Unblocking: the four blocker types

What it is

Unblocking is the lead's highest-leverage daily activity, and it depends on one classification. A blocker is one of four kinds, and each has a different fix. Applying the wrong fix is why teams stay stuck while everyone works hard.

Type          What is missing              The fix
------------------------------------------------------------------
INFORMATION   an answer that exists        find it, or find who
              somewhere                    knows it

DECISION      an answer nobody has         make it, or force the
              committed to yet             person who can to make it

DEPENDENCY    something another team or    escalate, negotiate a
              system must do               date, or route around it

SKILL         the person cannot do it      pair, teach, or reassign
              yet

What this is confused with: "blocked" as a status. In most standups "blocked" is a single flag with a single implied response, usually "the lead will chase someone." That response is correct for exactly one of the four types. Chasing a dependency for a problem that is actually a skill gap wastes a week and leaves the engineer feeling watched rather than helped.

Also confused: unblocking and doing the work. A lead who unblocks by writing the code has removed today's blocker and guaranteed tomorrow's, because the engineer is no closer to being able to do it and now has a reason not to raise it next time.

The problem it solves

Blocked time is invisible in every metric a team reports, and it dominates cycle time.

An item with a 14-day cycle time and 18% flow efficiency:
  2.5 days of active work
  11.5 days of waiting

Where the waiting goes, from a typical sample:
   4.1 days  waiting for code review        (dependency, on people)
   3.2 days  waiting for another team's API (dependency)
   2.0 days  waiting for a decision         (DECISION)
   1.4 days  waiting for a deploy window    (dependency, on process)
   0.8 days  waiting for an environment     (dependency)

Almost none of that is the engineer working slowly, and none of it
appears in a status update beyond the word "blocked".

And the failure has a specific shape: the blocker that nobody owns.

Monday    "I'm blocked on the auth team's endpoint."
Tuesday   "Still blocked."
Wednesday "Still blocked."
Thursday  the lead asks who they have spoken to. Nobody. They filed
          a ticket on Monday and it has not been triaged.

Four days lost, and the honest reading is that the lead lost them,
not the engineer, because "still blocked" was accepted three times
without a named owner and a next action.

Mechanics

Classifying, in one question each

INFORMATION
  "Does someone already know this?"
  Symptoms: "I'm not sure how X works", "I don't know if we
  already have a Y", "I can't tell what this config does".
  Fix: find the answer or the person, in minutes, not by asking
  the engineer to keep searching. Then WRITE IT DOWN, because an
  information blocker that recurs is a documentation gap.

DECISION
  "Who is allowed to say yes, and have they been asked directly?"
  Symptoms: "we're waiting to hear back", "product hasn't
  decided", "we don't know which approach they want".
  Fix: make it if it is yours. If not, go to the person with a
  RECOMMENDATION and a deadline, not a question. Most stalled
  decisions are stalled because nobody framed a choice.

DEPENDENCY
  "What is the other team's actual commitment, and what is our
   plan if it slips?"
  Symptoms: "the platform team hasn't shipped it", "we need
  access", "the vendor hasn't replied".
  Fix: a named person on the other side, a date, and a
  route-around option costed before you need it.

SKILL
  "Could this person do this today with help, or not yet?"
  Symptoms: repeated "almost done", a branch with no commits for
  two days, an engineer going quiet, work that keeps being
  re-scoped.
  Fix: pair, teach, or reassign. THIS IS THE HARDEST TO SEE,
  because the engineer will usually describe it as one of the
  other three.

Skill blockers masquerade as the other kinds, and that is the classification error worth watching for. An engineer who does not know how to approach a problem will report it as waiting for information or a decision, because that is a socially safer thing to be blocked on.

The tell: the blocker does not resolve when the stated cause is
removed.

  "I'm blocked on the schema decision."
  Decision made Tuesday. By Friday, no progress.
  -> it was never the decision.

The question that surfaces it without accusation:
  "If I gave you the answer right now, what would you do first?"
A crisp answer means the stated blocker is real. A vague one
means the blocker is the approach, and that is a pairing
conversation, not a chasing one.

Decision latency, measured

Track how long decisions sit. It is the one blocker type that is entirely inside the lead's control.

Keep a decision log: what, who decides, raised when, resolved when.

  Decision                     raised    resolved   latency
  --------------------------------------------------------
  Cursor format for v2 API     Mar 3     Mar 4      1 day
  Whether to backfill or
    dual-write                 Mar 5     Mar 19    14 days  <-
  Retire the legacy endpoint   Mar 11    Mar 12     1 day
  Which queue for the DLQ      Mar 12    Mar 12     0 days

RULE: a decision that has sat more than 48 hours is the lead's
failure, not the team's.

Fourteen days on a decision is fourteen days of an engineer's work shaped around not knowing, which usually means abandoned branches, defensive designs that support both options, and a rewrite when the answer arrives.

The three reasons decisions stall, and the fix for each:

NOBODY KNOWS WHO DECIDES
  -> write it down once. A one-page decision-rights list ("who
     decides API shape, who decides schema, who decides scope")
     removes most recurrence.

THE DECIDER HAS NO FRAME
  -> never take a question upward. Take a recommendation:
     "I recommend A. B is the alternative; it costs two extra
      weeks and buys us X. I need an answer by Thursday or I will
      proceed with A."
     A deadline plus a default converts an open question into a
     confirmation, which people answer.

IT IS ACTUALLY REVERSIBLE AND NOBODY NOTICED
  -> most decisions are two-way doors. Say so explicitly and
     decide fast. Reserve the deliberation for the ones that
     are genuinely hard to reverse.

The 24-hour rule

Nobody is blocked overnight without a named owner and a next
action.

Not "the platform team is looking into it."
But  "Priya on platform owns it, she has committed to an answer
      by 2pm tomorrow, and if it slips we switch to the
      file-based path, which costs us a day."

Two components, both required:
  a NAME (a person, not a team)
  a NEXT ACTION with a time

"A team is looking into it" is not an owner, and the difference between a team name and a person's name is usually the difference between two days and two hours.

The escalation ladder

Escalation is a tool, not an admission of failure, and the failure mode is escalating too late rather than too eagerly.

An explicit ladder, published, so nobody has to decide in the
moment whether escalating is acceptable:

  Hour 0    engineer asks the other team directly, in their
            channel, with the specific ask and the deadline
  Hour 4    lead asks the other team's lead, peer to peer
  Day 1     lead raises it in the cross-team forum, or to their
            own manager as information ("here is a risk")
  Day 2     manager to manager
  Day 3+    director level, with a written summary: the ask, the
            impact in days, what we tried, what we need

The ladder is a SCHEDULE, not a judgment. You do not have to
decide whether this one is worth escalating; you escalate on the
clock.

The reason to publish it: heroic absorption. A lead who quietly absorbs a two-week dependency slip protects the other team from the consequence of their slip, so it recurs, and their own team is blamed for the delay. Escalating on a schedule is kinder to everyone including the team you are escalating about, because it surfaces the constraint while it is still cheap.

The tone that works, and it matters:

Not: "the platform team is blocking us again."
But: "we need the token endpoint by the 14th to hit our date.
      Right now it is unscheduled. Can we either get it
      scheduled, or agree that our date moves by the same
      amount?"

State the ask, the impact and the two acceptable outcomes. Never
present an escalation with only one acceptable outcome, because
that is a demand rather than a decision request.

Routing around

For every dependency, cost the route-around BEFORE you need it:

  Dependency: the auth team's new token endpoint
  Needed by:  Mar 14
  Route-around: call the legacy endpoint and translate in our
    service. Costs ~2 days now, plus ~1 day to remove later.
  Decision point: Mar 7. If it is not scheduled by then, we
    build the route-around.

Having this written down does two things: it makes the
escalation concrete ("here is what it costs us if you slip"),
and it means the decision to route around is made calmly a week
early rather than in a panic the day before.

A worked example: a team that was busy and not moving

A team of six, three months into a platform migration. Every standup reported progress. The burn-up chart was flat. The lead's first instinct, which was wrong, was that the estimates had been optimistic.

Two weeks of logging every stated blocker, classified:

41 blockers recorded.

  INFORMATION   17   "how does the old system handle X?",
                     "is there an existing client for Y?",
                     "what does this flag do?"
  DEPENDENCY    12   9 on one team (identity), 3 on infra
  DECISION       9   4 of them the same decision, raised four
                     times by different people
  SKILL          3   as stated. Actual count, after review: 7.

The three findings, in order of size:

1. Seventeen information blockers were one problem.

15 of the 17 were answered by two people: the two engineers who
had worked on the legacy system. Median time to get an answer:
6 hours, because both were in meetings and the questions arrived
by direct message where nobody else could see them.

Fix, in order of effect:
  a) a public channel for these questions instead of DMs. The
     same question was being asked by different people, and now
     the second asker could search.
  b) a 30-minute daily "legacy office hour" from one of the two,
     rotating. Bounded, so it stopped being an all-day interrupt.
  c) every answer written into a running FAQ doc by the ASKER,
     not the answerer, which is the only version that happens.

After 3 weeks: information blockers 17 per fortnight -> 4, and
median time to answer 6 hours -> 40 minutes.

The asker writes it down, not the answerer, is the detail that makes documentation actually accumulate, because the answerer has already solved their problem and the asker has just paid the cost of not having it.

2. The same decision raised four times.

"Do we dual-write during the migration, or backfill and cut over?"

Raised Mar 5, Mar 11, Mar 18 and Mar 26 by four different
engineers, each of whom worked around it differently in the
meantime. Never resolved, because it was raised as a question to
a group and everyone assumed someone else owned it.

Fix: the lead wrote a one-page recommendation.
  "I recommend dual-write. It costs ~5 engineer-days and about
   3 weeks of running both paths. Backfill is cheaper by 3 days
   but needs a 6-hour write freeze, which the payments team
   cannot accept in Q1. I need a decision by Thursday; absent
   one I will proceed with dual-write."

Resolved in 26 hours, in favour of dual-write.

Cost of the 21 days it sat: two engineers had built partial
support for BOTH paths, which was discarded. Roughly 6
engineer-days.

Twenty-one days of latency cost more than the decision itself cost to execute, and it resolved in a day once someone framed a choice with a default and a deadline.

3. Twelve dependency blockers, nine on one team.

All nine were on the identity team's new token endpoint.
Status, when the lead finally asked directly: unscheduled, and
the identity team did not know anyone was waiting, because the
ask was a ticket in a backlog with no requester follow-up.

The lead had not escalated because escalating felt like
complaining, which is the heroic-absorption failure exactly.

What happened after the peer-to-peer conversation:
  - identity scheduled it for the following sprint, 8 days out
  - the lead costed a route-around (translate the legacy token
    in-service, ~2 days) and set a decision point 3 days before
    the deadline
  - it landed on time and the route-around was not needed

Elapsed time from "lead asks the identity lead directly" to
"scheduled": 90 minutes.

Elapsed time it had been blocked before that: 31 days.

Thirty-one days against ninety minutes is the cost of not having an escalation schedule, and the lead's own account of why was that it never felt like the right day to escalate. A published ladder removes that judgment from the moment.

4. The hidden skill blockers.

Three were reported as skill. Four more surfaced when the lead
started asking "if I gave you the answer right now, what would
you do first?"

All four were the same engineer, six weeks into the team, on the
streaming components. They had reported information and
dependency blockers because those are safer to say.

Fix: two weeks of scheduled pairing, 2 hours a day, with a named
partner, framed as "we under-invested in your onboarding to this
part of the system", which is true and puts the failure where it
belongs.

Their cycle time on subsequent items fell from a median of 11
days to 4.

Framing the skill gap as an onboarding failure rather than a performance issue is both accurate and the only framing that gets it raised next time.

Aggregate result over the following six weeks:

                              before      after
blockers reported per
  fortnight                      41          14
median blocker age            3.2 days    0.6 days
decisions older than 48h         4           0
flow efficiency                 18%         34%
throughput (items/week)         4.1         6.9
items with no owner named
  after 24 hours                 11           0

Throughput rose 68 percent with no change in headcount, hours or estimation practice, because the constraint had never been how fast people worked.

Production evidence

Little's Law and flow efficiency measurements (see capacity math and forecasting) are the general evidence that waiting dominates cycle time: measured flow efficiency across organisations typically falls between 5 and 20 percent, which means blocked time is the majority of an item's life.

Amazon's "two-way door" framing, articulated in Jeff Bezos's shareholder letters, is the standard argument for deciding reversible things fast and reserving deliberation for irreversible ones. It is the direct remedy for the stalled-decision category.

The DORA research programme's consistent finding that reducing batch size and work in progress improves delivery performance is the same result from the other direction: smaller items spend less time blocked because they depend on fewer things.

Google's Project Aristotle identified psychological safety as the strongest predictor of team effectiveness, which is the mechanism behind skill blockers being reported as information or dependency blockers: an engineer will report the blocker that is safest to report.

Documented "office hours" practice in platform and developer-experience teams, bounding expert availability to a fixed window rather than an open interrupt channel, is a widely adopted pattern for exactly the information-blocker concentration described above.

The debate

Should a lead unblock by doing the work? Rarely, and it is the most tempting failure. Writing the code removes today's blocker and guarantees tomorrow's, because the engineer is no closer to being able to do it and has learned that raising it produces rescue rather than help. The exception is a genuine emergency with a deadline, and even then the follow-up pairing session is the part that matters.

Is a decision log bureaucratic? Four columns is not bureaucracy. The argument for it is that decision latency is the only blocker category entirely within the lead's control, so it is the one where measurement most directly produces improvement, and nobody notices a fourteen-day decision without a log.

Should you escalate on a schedule even when the other team is trying? Yes, because the schedule is about information flow rather than blame. The counter-argument, that escalating damages the relationship, is real and is addressed by tone: an escalation that offers two acceptable outcomes ("schedule it, or agree our date moves") is a decision request, and one that offers a single acceptable outcome is a demand.

Do route-arounds create technical debt? Yes, and costing them in advance is what makes that debt a decision rather than an accident. The failure is building the route-around in a panic the day before the deadline, when it will be worse and nobody will have agreed to remove it. Cost it early, set a decision point, and write the removal ticket at the same time.

Is the 24-hour rule too rigid for deep work? It is about ownership, not about resolution. An engineer can be blocked for a week as long as there is a named person and a next action, because what the rule prevents is the blocker with no owner, which is the one that stays blocked indefinitely.

Should skill blockers be named as such? To the individual, yes, and framed as an onboarding or assignment failure where that is true, which it usually is. Publicly, no. The team needs to see that raising a blocker produces help, and the fastest way to stop hearing about skill gaps is to make one person's skill gap a topic in standup.

Follow-up Q&A

"What are the four blocker types and why does the classification matter?"

Information, where the answer exists and someone has it. Decision, where nobody has committed to an answer yet. Dependency, where another team or system has to do something. And skill, where the person cannot do it yet. They matter because the fixes are different and unrelated: finding an answer, forcing a decision, escalating or routing around, and pairing or reassigning. Treating everything as a dependency, which is what "the lead will chase someone" amounts to, is correct for one of the four and wastes a week on the others.

"Which type is hardest to see, and how do you surface it?"

Skill, because engineers report it as one of the other three: waiting for information or a decision is socially safer than not knowing how to approach the problem. The tell is that the blocker does not resolve when its stated cause is removed. The question that surfaces it without accusation is "if I gave you the answer right now, what would you do first?" A crisp answer means the stated blocker is real; a vague one means the blocker is the approach. Then frame the fix as an onboarding or assignment gap where that is true, because that is both accurate and the only framing that keeps people raising it.

"How do you unstick a decision?"

Never take a question upward, take a recommendation with a default and a deadline. "I recommend A. B costs two extra weeks and buys X. I need an answer by Thursday, and absent one I will proceed with A." That converts an open question, which people defer, into a confirmation, which people answer. In one case the same migration decision was raised four times over 21 days by four engineers and resolved in 26 hours once it was framed that way, after two of them had already built partial support for both options at a cost of roughly six engineer-days.

"What is the 24-hour rule?"

Nobody is blocked overnight without a named owner and a next action. Not "the platform team is looking into it" but "Priya owns it, she has committed to an answer by 2pm tomorrow, and if it slips we switch to the file-based path at a cost of a day." Two required components: a person's name rather than a team's, and a next action with a time. The rule is about ownership rather than resolution, so a week-long blocker is fine if it has both.

"Why publish an escalation ladder?"

To remove the judgment from the moment, because the common failure is escalating too late rather than too eagerly. A lead who quietly absorbs a dependency slip protects the other team from the consequence of it, so it recurs, and their own team gets blamed for the delay. With a published schedule, hour zero to the team, hour four peer to peer, day one to the cross-team forum, day two manager to manager, you escalate on the clock rather than deciding whether today is the day. In one case a dependency sat 31 days and was scheduled 90 minutes after the first direct peer-to-peer conversation.

"How do you escalate without damaging the relationship?"

State the ask, the impact in days, what you have tried, and two acceptable outcomes. "We need the token endpoint by the 14th to hit our date; right now it is unscheduled. Can we get it scheduled, or agree that our date moves by the same amount?" An escalation with only one acceptable outcome is a demand, and it is what makes people route around you afterwards. Costing the route-around in advance also helps, because it turns the escalation into a concrete trade rather than a complaint.

Common misconceptions

"Blocked is a status." It is four different statuses with four different fixes, and the default response addresses one of them.

"Chasing the other team is unblocking." It is the fix for one category. Applied to a skill gap it wastes a week and leaves the engineer feeling watched.

"Escalating is a failure." Escalating late is. Absorbing a slip quietly protects the other team from the consequence and transfers the blame to yours.

"The lead should jump in and write the code." That removes today's blocker and teaches that raising a blocker produces rescue instead of capability.

"A decision that is taking a while is just a hard decision." Most stalled decisions are stalled because nobody framed a choice with a default and a deadline, and most are reversible anyway.

"Documentation should be written by the person who knows the answer." They have already solved their problem. The asker just paid the cost of not having it, which is why the asker writing it down is the version that accumulates.

Interview delivery note

Say this verbatim: "Every blocker is one of four kinds: information, decision, dependency or skill, and each needs a different fix. Skill is the one that hides, because engineers report it as one of the other three, and the tell is that the blocker does not resolve when its stated cause is removed." It gives the taxonomy and the non-obvious part in two sentences.

The senior-versus-staff separator is measuring decision latency and owning it. A senior lead unblocks people. A staff lead keeps a four-column decision log, treats anything over 48 hours as their own failure rather than the decider's, and takes recommendations upward with a default and a deadline instead of questions. Saying "a decision sat 21 days and cost six engineer-days of work built against both options, then resolved in 26 hours once I framed a choice" shows the mechanism rather than the sentiment.

The second signal is naming heroic absorption as a failure. Recognising that quietly absorbing another team's slip protects them from the consequence, guarantees the recurrence, and moves the blame onto your own team, and that the remedy is a published escalation schedule rather than better judgment in the moment, is the systems-thinking version of an interpersonal problem.

Further reading

• Jeff Bezos's shareholder letters on one-way and two-way doors, for deciding reversible things fast.
• Google's re:Work materials on psychological safety, for why the blocker that gets reported is the one that is safest to report.
• Daniel Vacanti's flow metrics work, for blocked time and work item age as first-class measurements.
• The capacity math and forecasting page, for flow efficiency, which is the quantitative form of this page's argument.
• The underperformance sequence page, for what happens when a skill blocker turns out not to be an onboarding gap.

Growing people: skill matrix, stretch, delegation, feedback

What it is

Growing people is the deliberate part of a lead's job that most leads do accidentally: assigning work to close named gaps rather than to whoever is free, sizing stretch so it is survivable, transferring authority one rung at a time, and giving feedback specific enough to act on.

Four instruments, each with a concrete form:

SKILL MATRIX       each person x each competency, with a current
                   level and a target. Turns "who's available?" into
                   "who needs this?"

STRETCH RATIO      roughly 70% known / 30% new. More than that and
                   you have set up a failure and called it growth.

DELEGATION LADDER  do it -> do it and tell me -> propose then do ->
                   decide and inform -> own it entirely.
                   Move one rung at a time, and SAY which rung.

SBI FEEDBACK       Situation, Behaviour, Impact. Specific, timely,
                   behavioural. Praise publicly, correct privately.

What this is confused with: career conversations. A quarterly conversation about ambitions is not development; the work someone does every day is the development. A lead who has a great career chat and then assigns the same person the same kind of task for six months has done nothing.

Also confused: delegation and abdication. Handing over a task without naming the rung means the engineer does not know whether to ask before acting, and the lead does not know whether to expect a proposal. Both then experience the other as unreasonable.

The problem it solves

Assignment by availability is the default, and it produces a team that is individually competent and collectively fragile.

Six months of assigning work to whoever is free:

  Alex   has done every streaming task, because Alex is fastest
         at them
  Sam    has done every frontend task, for the same reason
  Priya  has done whatever was left

Consequences:
  - Alex is the single point of failure for streaming, cannot take
    a holiday without risk, and is bored
  - Sam has not touched a backend service in a year and is now
    unpromotable at a company that expects breadth at the next
    level
  - Priya's growth is a function of what nobody else wanted
  - the bus factor on two systems is 1

Every one of those is a lead's decision that was never made deliberately.

And the feedback failure, which is the other half:

"You're doing great, keep it up."         -> unactionable
"Your communication could be better."     -> unactionable and
                                             slightly hurtful
"You need to show more ownership."        -> the single most
                                             common unactionable
                                             piece of feedback in
                                             engineering

The engineer cannot act on any of them, so nothing changes, so
the same feedback appears at the next review, by which point it
has become a rating.

Mechanics

The skill matrix

Competencies that matter for engineers (adjust to your ladder):
  domain knowledge      the product and its constraints
  systems design        decomposition, tradeoffs, failure modes
  code quality          readability, testing, maintainability
  operational           debugging production, on-call competence
  communication         writing, presenting, disagreeing well
  ownership             follow-through without prompting
  mentoring             growing others

Levels: 1 needs help, 2 does it, 3 does it well, 4 teaches it.

                domain  design  code  ops  comms  own  mentor
  Alex             4       3      3     4     2     3     2
  Sam              2       2      4     1     3     3     1
  Priya            3       2      3     2     4     2     2
  Dev (new)        1       3      3     2     3     2     3
  Jo               3       4      3     3     3     4     3

Reading the matrix is the point, and three readings come out of it immediately:

1. RISK. Alex is the only 4 in ops, and the only 4 in domain.
   Two single points of failure in one person.
   -> the next two production incidents get a deliberate
      second responder, and Alex's job is to narrate.

2. INDIVIDUAL GAPS. Sam is a 1 in ops and a 2 in domain, which
   is exactly what will block them at the next level.
   -> Sam takes the next on-call shift paired, and owns the next
      piece of work that requires understanding the domain
      rather than the code.

3. UNDERUSED STRENGTH. Dev is a 3 in mentoring and brand new,
   which is unusual and worth using: Dev onboards the next hire.
   Being trusted with that in month two is also the highest-
   value retention move available for a strong new joiner.

Keep it private to the lead. A shared matrix becomes a ranking, and people optimise for the number. Its purpose is to make assignment deliberate, not to publish an assessment.

Update it after every substantial piece of work, not quarterly, because the cost of maintaining it is what determines whether it survives.

The stretch ratio

An assignment should be roughly 70% within the person's current
capability and 30% new.

  90/10   comfortable, and it is not growth. Fine sometimes; a
          diet of it is why strong engineers leave.
  70/30   the target. Hard enough to learn, familiar enough to
          finish.
  50/50   possible with heavy support, and only for one thing at
          a time.
  30/70   a setup. The person will either fail publicly or be
          rescued, and both damage them.

The dimension of the stretch matters as much as the size. Stretching someone on technical complexity, on scope and ambiguity, and on visibility at the same time is three stretches, not one.

A new senior engineer's first stretch:

  BAD:  lead the cross-team migration, present to the VP monthly,
        and it uses a technology they have not touched.
        Three simultaneous stretches. This is a 30/70.

  GOOD: lead the cross-team migration (new: scope and
        coordination) in a technology they know well (familiar),
        with you presenting to the VP for the first two months
        and them taking it over in month three (staged).
        One stretch at a time, sequenced.

Naming which dimension is being stretched, out loud, to the person, is what turns an assignment into development. "This is a scope stretch, not a technical one; the technology is deliberately familiar so that the coordination is the hard part" tells someone what to be good at.

The delegation ladder

1. DO IT              I tell you exactly what to do.
2. DO IT AND TELL ME  You execute, and report back after.
3. PROPOSE, THEN DO   You bring me the plan; once I agree, you go.
4. DECIDE AND INFORM  You decide and act, then tell me what you did.
5. OWN IT ENTIRELY    You own the outcome. I hear about it in your
                      updates, not as an approval step.

Two rules, and both are commonly broken:

RULE 1: MOVE ONE RUNG AT A TIME.
  Jumping someone from 2 to 5 is not empowerment, it is
  abandonment, and when it goes wrong the lesson they learn is
  that they were not ready, which is not the lesson.

RULE 2: SAY WHICH RUNG, EXPLICITLY, PER AREA.
  "You own the caching layer entirely. On the API contract,
   bring me the proposal first, because it affects three other
   teams."
  Same person, two rungs, two areas. Without saying it, the
  engineer guesses, and half the friction between leads and
  seniors is a rung mismatch nobody named.

The most common failure is the lead who thinks they are at rung 4 and behaves like rung 3.

Lead says:  "You own this, go."
Lead then:  reviews every PR in detail, asks to see the design
            before it ships, and reverses a decision.

The engineer experiences this as being told they own something
and then not owning it, which is worse than being told rung 3
honestly. If you are going to review the design, say so: that
is rung 3, and rung 3 is a legitimate place to be.

Moving someone up is a decision with a visible marker, and saying it makes the promotion of trust real: "Last quarter you brought me proposals on the ingest work and I agreed with all of them, so from now on that area is decide-and-inform."

SBI feedback

SITUATION   when and where, specifically
BEHAVIOUR   what you observed, observable and not inferred
IMPACT      what it caused, on people or on outcomes

Vague:  "You need to communicate better."

SBI:    "In Tuesday's design review [S], when Priya raised the
         backfill concern you moved to the next slide without
         responding [B]. She stopped contributing for the rest of
         the meeting, and the backfill risk we hit last week was
         the thing she was raising [I]."

What makes it work is that behaviour is observable and therefore arguable. Someone can disagree that they moved past the concern, and that disagreement is a useful conversation. Nobody can productively disagree with "you need to communicate better."

The same structure for positive feedback, and it is under-used:

"In the incident on Thursday [S], you posted a status update
 every 15 minutes even though there was nothing new to say [B].
 That is why nobody from support interrupted the responders, and
 it is the reason the VP did not join the call [I]."

That tells them exactly which behaviour to repeat. "Great job on
the incident" does not.

Timing and setting:

TIMELY     within days. Feedback about something a month ago is
           about a memory, and the person has already repeated
           the behaviour several times without correction.
PRIVATE
  for correction    always
PUBLIC
  for praise        usually, and check: some people find public
                    praise uncomfortable, and it is worth asking
                    once rather than assuming.

One-to-ones

THEIR AGENDA FIRST. If you have a topic, it goes after theirs.
NOT A STATUS MEETING. Status is available in the tracker. If your
  1:1s are status updates, you have converted the only private
  channel you have into a report.
CAREER EVERY FOURTH ONE. Explicitly scheduled, so it does not get
  crowded out by whatever is urgent.
NOTES ARE SHARED. A running doc both people can edit, with
  actions. It makes the thread visible over months, which is what
  makes growth conversations concrete.
CANCEL RARELY. A cancelled 1:1 says the relationship is the
  flexible item. If you must, reschedule rather than skip.

Growth plans against the next level's rubric

Not: "get better at design."
But: mapped to the actual next-level rubric, with named artifacts
     as evidence.

  Rubric line (Staff): "drives technical direction beyond their
  own team"
  Current evidence: none
  Plan: own the cross-team schema-evolution proposal, write the
        RFC, run the review with the three consuming teams
  Artifact by end of quarter: the RFC, the review notes, and the
        adoption decision
  Who else needs to see it: the two staff engineers who will be
        in the calibration room

The last line is the one leads omit, and it is the difference
between doing the work and being promoted for it.

Adjectives do not survive a calibration room; artifacts do (see promotions and the calibration room).

A worked example: a team where nobody was growing

A team of five, stable for eighteen months, no attrition and no promotions. The lead's read was that the team was "solid." Two engineers had privately started interviewing elsewhere.

Building the matrix surfaced the shape of the problem:

                domain  design  code  ops  comms  own  mentor
  Alex             4       3      3     4     2     3     2
  Sam              2       2      4     1     3     3     1
  Priya            3       2      3     2     4     2     2
  Jo               3       4      3     3     3     4     3
  Dev              1       3      3     2     3     2     3

Assignment history, last 2 quarters, by system:
  streaming:  Alex 11 items, everyone else 2 combined
  API:        Sam 9, Jo 4
  data:       Jo 8, Priya 3
  frontend:   Sam 7, Priya 1

Three findings:

1. Alex owned streaming with a bus factor of 1, was a 2 in
   communication, and was one of the two interviewing. Their
   stated reason, in the eventual conversation: "I've been doing
   the same thing for two years and nobody has asked me to do
   anything else."

2. Sam was a 4 in code and a 1 in ops, and had been passed over
   in the last promotion cycle for "insufficient operational
   maturity", which nobody had told Sam in those words.

3. Priya was the strongest communicator on the team and had been
   given the leftovers, which is how a 4 in communication ends up
   with a 2 in ownership.

The reassignment, done deliberately over one quarter:

ALEX: moved off streaming as primary. Given the API rewrite
      (new domain, familiar difficulty: a technical stretch that
      is 70/30) AND the job of bringing Priya to a 3 in
      streaming. The mentoring assignment was explicit and
      framed as the growth: "your next level needs evidence you
      can grow others, and streaming is where you can."
      Delegation rung: 5 on streaming architecture, 3 on the API
      rewrite because it touches two other teams.

SAM:  next on-call shift paired with Jo, then two solo shifts,
      then owning the alert review. Framed with the actual
      reason: "the calibration feedback was operational
      maturity, and here is the specific evidence we need by
      the next cycle."
      Delegation rung: 2 on on-call initially, moving to 4.

PRIYA: given the cross-team migration coordination, which is a
      scope stretch in a familiar technology. Deliberately not
      also a technical stretch.
      Delegation rung: 3, moving to 4 in the second month.

JO:   already a 4 in ownership and design, and the growth was
      lateral: took the technical-direction work for the
      quarter, wrote the schema-evolution RFC, ran the review
      with three consuming teams. Mapped explicitly to the staff
      rubric line about influence beyond their own team.

DEV:  onboarded the new hire in month two, using the 3 in
      mentoring. Cost: about a day a week for six weeks.

SBI feedback, introduced at the same time, with one specific correction:

To Alex, about the communication 2:

  "In the incident review on the 14th [S], when the platform
   team asked why we hadn't caught it in the canary, you said
   'the canary is useless for this' and moved on [B]. Two things
   happened: the platform lead brought it up with me afterwards
   as 'your team thinks our tooling is useless', and the actual
   point you were making, which was right, didn't land [I]."

Alex's response was to disagree with the characterisation, and
the resulting 20-minute conversation was the useful part. The
behaviour changed within a month, which "you need to work on
your communication" had not achieved in two prior reviews.

Results after two quarters:

                                before      after
bus factor on streaming              1           2
bus factor on data                   1           2
promotions                           0    2 (Sam, Jo)
regretted attrition             2 at risk       0
matrix cells at level 1              3           1
matrix cells at level 4              6          10
items assigned to the person
  who most needed the skill        n/a    tracked; 14 of 22

Alex, six months later, had a 3 in communication, had grown
Priya to a 3 in streaming, and was in the following promotion
cycle with mentoring evidence they had not previously had.

Nobody was hired and nobody worked more hours. The change was that assignment stopped being a function of availability.

One thing that got worse, and it was predictable:

Throughput fell about 15% in the first six weeks.

Alex on the API rewrite was slower than Sam would have been.
Priya on streaming needed Alex's time. Sam's paired on-call
shifts consumed two people.

The lead flagged this in advance to the PM with a number and a
duration: "expect roughly 15% less for six weeks; this is the
cost of removing two bus factors and getting two people
promotable."

It recovered by week nine and exceeded the previous level by
week fourteen, because four people could now do work that
previously only one could.

Announcing the dip in advance with a number is what made it a plan rather than a slump, and it is the same move as pricing any other investment.

Production evidence

Situation-Behaviour-Impact is a feedback model developed and taught by the Center for Creative Leadership, and its documented rationale is precisely that behaviour is observable and therefore discussable, where inference and judgment are not.

The delegation ladder appears in several forms, notably in the "levels of delegation" used in management-training literature and in Jurgen Appelo's Delegation Poker; the shared claim across versions is that the failure is ambiguity about the level rather than the choice of level.

Google's Project Oxygen identified "is a good coach" and "helps with career development" among the behaviours most associated with effective managers, with the specific finding that regular, specific, actionable feedback separated the highest-rated managers from the rest.

Published engineering career ladders (Rent the Runway's, CircleCI's, Dropbox's, and the collection at levels.fyi and progression.fyi) are the concrete form of "map the growth plan to the next level's rubric," and their common structure, competencies with observable evidence, is what makes artifact-based plans possible.

Bus factor as an explicit risk measurement is standard practice in operational reviews, and pairing and deliberate rotation are the documented remedies; the connection to assignment policy, that a bus factor of one is a consequence of assigning by speed, is the part usually left implicit.

Research on stretch assignments in leadership development consistently finds that challenging assignments are the dominant developmental experience, with the caveat that support must scale with the stretch, which is the empirical basis for the 70/30 sizing rather than a larger one.

The debate

Should the skill matrix be shared with the team? Shared per-person, in the one-to-one, yes. Shared as a grid, no, because it becomes a ranking and people optimise for their row. The counter-argument, that transparency builds trust, is real and is better served by being explicit with each person about their own gaps and the plan, which is the part they can act on.

Is 70/30 too conservative? For a person with strong support and a low-stakes outcome, 50/50 works. The argument for 70/30 as the default is that the failure mode is asymmetric: an under-stretched engineer is bored and can be stretched next quarter, while an over-stretched one fails publicly and often concludes they are not capable, which takes far longer to undo.

Does assigning for growth cost delivery? Yes, in the short term, measurably. The honest number in one case was about 15 percent for six weeks, and the argument that carries it is that the alternative was two bus factors of one and two engineers interviewing elsewhere. Announce the dip with a number and a duration, because an unannounced dip is indistinguishable from a slump.

Is SBI formulaic? It reads as formulaic when used for trivial things, and the fix is to use it for feedback that matters rather than to abandon the structure. The value is that it forces you to identify a specific observable behaviour, and if you cannot, the feedback was not ready to give.

Should a lead delegate work they are better at? Usually yes, and this is the hardest instinct to override. The lead's throughput is not the team's constraint; the team's capability is, and every task a lead keeps because they are faster at it is a capability that stays at a bus factor of one. The exception is a genuine deadline emergency, and the follow-up transfer is what stops it becoming permanent.

Are career conversations useful at all? Yes, as calibration, and they are not development. Development happens in the assignments between the conversations, and a lead who has a great quarterly career chat and then assigns by availability has run a pleasant meeting.

Follow-up Q&A

"How do you decide who gets which piece of work?"

From a skill matrix rather than from who is free. Each person against each competency, with a current level and a target, updated after every substantial piece of work. Three readings fall out immediately: risk, where a competency has exactly one strong person, which is a bus factor of one you created; individual gaps, where the thing blocking someone at the next level is visible as a low cell; and underused strength, where someone is strong at something they never get to do. Then assignment becomes "who needs this" rather than "who is available," and you say out loud which dimension is being stretched.

"What is the right size for a stretch assignment?"

About 70 percent within current capability and 30 percent new, and the dimension matters as much as the size. Technical complexity, scope and ambiguity, and visibility are three separate stretches, and combining them is how a well-intentioned assignment becomes a setup. The good version of a first leadership stretch is new scope in a familiar technology with the lead handling the executive exposure for the first two months. The failure mode is asymmetric: an under-stretched engineer can be stretched next quarter, while an over-stretched one often concludes they are not capable, and that takes far longer to undo.

"What is the delegation ladder and where does it go wrong?"

Do it; do it and tell me; propose then do; decide and inform; own it entirely. Two rules. Move one rung at a time, because jumping from rung two to rung five is abandonment rather than empowerment. And say which rung, explicitly and per area, because the same person can be at rung five on one system and rung three on an API contract that affects three teams. The most common failure is a lead who says "you own this" and then behaves like rung three, reviewing every design and reversing decisions. Being told rung three honestly is better than being told rung five and experiencing rung three.

"What does actionable feedback look like?"

Situation, behaviour, impact. Instead of "you need to communicate better," say: in Tuesday's design review, when Priya raised the backfill concern you moved to the next slide without responding; she stopped contributing for the rest of the meeting, and the backfill risk we hit last week was what she was raising. Behaviour is observable, so it is arguable, and the disagreement is a useful conversation. Nobody can productively disagree with "communicate better," which is why it appears in three consecutive reviews and then becomes a rating. Use the same structure for praise, because "great job on the incident" does not tell anyone which behaviour to repeat.

"How do you write a growth plan that survives a promotion committee?"

Map it to the actual next-level rubric line, name the artifact that will be the evidence, and name who needs to see it. Not "get better at design" but: the rubric says drives technical direction beyond their own team, current evidence is none, the plan is to own the cross-team schema-evolution proposal and run the review, the artifact is the RFC and the adoption decision, and the two staff engineers who will be in the calibration room need to have seen it. The last part is what leads omit, and it is the difference between doing the work and being promoted for it, because adjectives do not survive a calibration room and artifacts do.

"What does assigning for growth cost?"

Short-term throughput, measurably. In one case about 15 percent for six weeks, because the person learning was slower than the person who already knew, and pairing consumed two people at once. It recovered by week nine and exceeded the previous level by week fourteen, since four people could then do work only one could before. The move that makes it a plan rather than a slump is announcing the dip in advance with a number and a duration, and naming what it buys: in that case removing two bus factors of one and making two people promotable, with two engineers who had been interviewing elsewhere staying.

Common misconceptions

"Assign work to whoever is free." That is how you get a bus factor of one on every system and a team where nobody's capabilities changed in two years.

"A career conversation is development." The assignments between the conversations are the development. The conversation is calibration.

"You own this" is delegation. Without naming the rung, the engineer guesses whether to ask first, and half the friction between leads and seniors is an unnamed rung mismatch.

"Feedback should be gentle." It should be specific. A vague soft signal followed later by a hard decision is the cruelest version, and it is what "you need to show more ownership" turns into at review time.

"Bigger stretches grow people faster." Beyond about 70/30 the person either fails publicly or is rescued, and both teach the wrong lesson.

"A lead should keep the work they are best at." The lead's throughput is not the constraint. Every task kept because you are faster is a capability that stays at a bus factor of one.

Interview delivery note

Say this verbatim: "I assign from a skill matrix rather than by who is free, because assigning by availability is how you end up with a bus factor of one on every system and a team whose capabilities have not changed in two years. And I name which rung of the delegation ladder someone is on, per area, because most friction between a lead and a senior engineer is an unnamed rung mismatch." Two mechanisms and the failure each prevents.

The senior-versus-staff separator is pricing the growth investment out loud. A senior lead assigns stretch work. A staff lead tells the product partner in advance to expect roughly 15 percent less throughput for six weeks, says what it buys, removing two bus factors and making two people promotable, and reports when it recovers. Announcing the dip converts an unexplained slump into an investment with a return date, and it is the same move as pricing any other technical investment.

The second signal is naming which dimension of a stretch is which. Saying "this is a scope stretch, not a technical one, so the technology is deliberately familiar and the coordination is the hard part" tells the engineer what to be good at, and it demonstrates that you know technical complexity, scope and visibility are three separate stretches that should not be combined.

Further reading

• The Center for Creative Leadership's materials on the Situation-Behaviour-Impact feedback model.
• Google's re:Work summary of Project Oxygen, particularly the coaching and career-development behaviours.
• Published engineering career ladders (Rent the Runway, CircleCI, Dropbox) and the progression.fyi collection, for rubric lines that growth plans can map to.
• The promotions and the calibration room page, for why artifacts rather than adjectives are the deliverable.
• The underperformance sequence page, for the path when growth investment does not close the gap.

PR review as a leadership lever

What it is

Code review is usually treated as a quality gate. It is also the largest hidden cost in a team's cycle time and the highest-frequency cultural artifact the team produces, which makes it one of the few things a lead can change that affects delivery speed, code quality and how people treat each other at the same time.

Four settings, each with a defensible number:

REVIEW SLA        first response within 4 business hours,
                  published. Not "reviewed", RESPONDED TO.

PR SIZE           under ~400 lines changed. Review quality
                  collapses beyond that, and large PRs get
                  approved rather than reviewed.

COMMENT TAXONOMY  prefixes: blocking: / suggestion: / nit: /
                  question: / praise:
                  Cheap to introduce, and it removes the
                  ambiguity that causes most review friction.

REVIEW ORDER      correctness -> design and boundaries -> tests ->
                  readability -> nits. In that order, explicitly.

What this is confused with: review as gatekeeping. A gate asks "should this be allowed in." A review that works asks "is this correct, is the design right, and what will the next person need to know." The gate framing produces reviewers who look for reasons to object and authors who write defensively.

Also confused: review latency and review thoroughness. They are independent, and teams routinely trade the wrong one: a review that takes two days and then rubber-stamps a 900-line diff has the worst of both.

The problem it solves

Review latency is usually the single largest component of cycle time, and it is invisible because nobody measures the waiting.

An item with a 14-day cycle time, sampled:

  2.5 days   active development
  4.1 days   waiting for review
  1.2 days   waiting for re-review after changes
  6.2 days   other waiting

Review accounts for 5.3 of 14 days: 38% of the item's life,
spent on work that is finished.

And the cost compounds: a PR waiting two days is a PR the author
has context-switched away from, so responding to comments now
costs a re-orientation, and the branch has drifted from main.

And unreviewed ambiguity produces interpersonal cost that nobody attributes to the review process.

A comment: "Why not use a map here?"

Author reads it as: you must change this.
Reviewer meant:     I'm curious, this is fine either way.

Result: the author rewrites, the reviewer is surprised, and both
conclude the other is difficult. Between two seniors this
escalates, because each assumes the other's intent is clear.

The prefix `question:` costs seven characters and removes the
entire failure mode.

Mechanics

The review SLA

Published: "First response within 4 business hours."

Two deliberate details:

RESPONSE, NOT APPROVAL. The commitment is that the author is not
  waiting in silence. A response can be an approval, a set of
  comments, or "this needs an hour of focus, I'll do it at 3pm."
  All three unblock the author's planning; silence does not.

BUSINESS HOURS. A PR opened at 5pm is not late at 9am. Making
  this explicit prevents an SLA from becoming an evening
  expectation.

Making the SLA achievable is the lead's job, not the reviewers':

- A scheduled review slot on everyone's calendar. 20 to 30
  minutes, daily, at a fixed time. This is the single highest-
  impact change, because it converts review from an interruption
  into planned work.
- Explicit reviewer assignment. "Anyone can review" means nobody
  does, and round-robin assignment with a bot removes the
  social cost of asking.
- Review is counted as work. If a person reviewed six PRs and
  shipped nothing, they had a productive day, and saying so in
  public is what makes the SLA real.
- Measure: time-to-first-review (p50 and p90), review queue
  depth, and PRs older than 24 hours. Three numbers on the
  team's dashboard.

The reason a scheduled slot works where exhortation does not is that review competes with focused work, and focused work always wins in the moment. Putting it on the calendar makes it lose once, in advance, which is the same governance move as any other declared budget.

PR size

Under ~400 lines changed. The specific number comes from the
review-effectiveness research (see production evidence), which
consistently finds defect-detection rate falling sharply past a
few hundred lines and review speed becoming implausible past
about 500.

The observable symptom of an oversized PR:

   120 lines   14 comments, 3 substantive
   450 lines    9 comments, 4 substantive
   900 lines    2 comments ("LGTM", "nit: typo")
  2,100 lines   1 comment ("approved")

Comment count per line falls off a cliff, and the reason is
that past a certain size the reviewer cannot hold the change in
their head, so they check the parts they understand and approve
the rest.

How to actually get small PRs, since "write smaller PRs" is not an instruction anyone can follow:

- STACKED PRs: a chain of small PRs each based on the previous,
  reviewed and merged bottom-up. Tooling exists because git does
  not model the chain.
- SEPARATE MECHANICAL FROM SEMANTIC. A rename touching 60 files
  and a behaviour change should never be the same PR. Land the
  rename first, alone, and say so in the description.
- FEATURE FLAGS. Incomplete work merges behind a flag, so a
  feature is five small PRs rather than one large one.
- A SIZE WARNING, NOT A BLOCK. A bot that comments "this is 780
  lines; consider splitting" is useful. A hard block produces
  three PRs with an artificial split and a broken main.

The comment taxonomy

blocking:    I will not approve until this changes. Use sparingly
             and always with a reason.
suggestion:  I think this would be better. Author decides.
nit:         trivial, take it or leave it, and I do not need a
             reply.
question:    I genuinely do not know. Not a disguised objection.
praise:      this is good and I want you to keep doing it.

The taxonomy does three things that are hard to get otherwise:

1. It makes the reviewer's authority explicit, so the author
   knows what they must do versus what they may do.
2. It forces the reviewer to decide how strongly they feel,
   which reduces the number of blocking comments, because
   typing `blocking:` on a stylistic preference feels wrong,
   correctly.
3. `praise:` gets used. Without a prefix inviting it, review
   comments are 100% criticism by construction, which is a
   strange thing to do to people every day.

question: is the one that resolves senior-to-senior friction, because the ambiguity between "I'm curious" and "you should change this" is exactly where two experienced engineers most reliably annoy each other.

A convention worth adding: a blocking comment must say why in terms of consequence.

Weak:     "blocking: don't use a mutable default here."
Better:   "blocking: mutable default argument, so the list
           persists across calls and the second caller sees the
           first caller's items."

The second is teachable and unarguable. The first is an
assertion of authority.

Automate everything mechanical

Humans should never comment on:
  formatting            -> formatter, enforced in CI and on save
  import order          -> linter with autofix
  naming conventions    -> linter where mechanical
  line length           -> formatter
  trailing whitespace   -> formatter
  test coverage floor   -> CI check
  dependency licences   -> CI check

Every one of these as a human comment costs a round trip, and
each round trip costs hours of latency for something a machine
decides deterministically.

The argument to make when someone resists the formatter: it is not about which style is better, it is that no human minute should ever be spent on it. Adopt the language's default (gofmt, black, rustfmt, prettier) so the style choice itself is not a discussion.

Review order, said out loud

1. CORRECTNESS       does it do what it claims? edge cases, error
                     paths, concurrency, the failure modes
2. DESIGN AND        is this the right place for this code? does
   BOUNDARIES        it put a dependency where it does not belong?
                     will the next change be harder?
3. TESTS             do they test behaviour? would they fail if
                     the code were wrong?
4. READABILITY       will the person who reads this in a year
                     understand it?
5. NITS              everything else

The order matters because reviewer attention is finite and front-loaded. A reviewer who starts with naming has spent their attention before reaching the concurrency bug.

And it matters because of what a review comment costs the author: a design comment on the first pass is a redesign, and a design comment after three rounds of nit fixing is a demoralising rewrite. Get the expensive comments out first.

Reviewer assignment

ROTATE, deliberately:
  - spreads context, so the bus factor on each area rises
  - prevents the single-owner bottleneck, where one person
    reviews everything in an area and becomes the constraint
  - is a growth mechanism: reviewing a system is one of the
    cheapest ways to learn it

PAIR-REVIEW FOR ONBOARDING: a new joiner reviews alongside an
  experienced reviewer for their first weeks. They learn the
  codebase and the review norms simultaneously, and it is far
  more effective than reading the style guide.

TWO REVIEWERS only where it earns its cost: security-sensitive
  paths, migrations, anything touching money. Everywhere else it
  doubles latency and produces diffusion of responsibility, where
  each reviewer assumes the other looked properly.

A worked example: 38 percent of cycle time spent on finished work

A team of eight, median cycle time 14 days, complaints in both directions: engineers said reviews were slow, and the lead's read from the retro was that people were "not prioritising review."

Measured for three weeks, 96 PRs:

time to first response      p50  9.4 hours   p90  38 hours
time to merge               p50  2.8 days    p90  6.1 days
PR size                     p50  340 lines   p90  1,180 lines
comments per PR             p50  4           p90  9
PRs merged with 0 or 1
  substantive comment                        41%
review round trips          p50  2           p90  5

Reviewer distribution: 2 of 8 people did 61% of all reviews.

Three findings, and the second one inverted the retro's conclusion:

1. The 9.4-hour p50 was almost entirely queueing, not reviewing.

Sampled 20 reviews, measuring actual time spent in the review:
  median time spent reviewing:    11 minutes
  median time the PR waited:      9.4 hours

So the cost was not reviewer effort, it was that review had no
scheduled place and lost every contest against focused work.

2. Forty-one percent of PRs merged with no substantive comment, concentrated in large PRs.

By size bucket, share merged with 0-1 substantive comments:

  < 200 lines       12%
  200-400           19%
  400-800           47%
  > 800             81%

Reading: past about 400 lines the review stops being a review.
The team was not under-reviewing because people were lazy; they
were under-reviewing because the artifact was unreviewable.

"Not prioritising review" was the wrong diagnosis, and the measurement is what changed it.

3. Two people did 61 percent of reviews, and both were the ones complaining loudest about interruption.

Cause: informal norm that the two most senior engineers reviewed
"anything important", which had grown to mean everything. Both
were the single reviewer for their areas, so both were a
bottleneck AND a bus factor.

The changes, in order of effect:

1. A DAILY 25-MINUTE REVIEW SLOT on everyone's calendar, 10:35,
   after standup. Not optional, and counted as work.
   -> time to first response p50 9.4h -> 2.1h, p90 38h -> 7h
   This was one calendar change and it was the largest single
   improvement in the whole programme.

2. A SIZE WARNING BOT at 400 lines, plus a stacked-PR workflow
   and a rule that mechanical changes ship separately.
   -> p50 PR size 340 -> 180, p90 1,180 -> 410
   -> PRs merged with 0-1 substantive comments 41% -> 17%

3. THE COMMENT TAXONOMY, introduced in one 10-minute standup and
   added to the PR template.
   -> review round trips p90 5 -> 3, because `nit:` comments
      stopped triggering a re-review cycle and `suggestion:`
      stopped being read as mandatory
   -> two specific recurring conflicts between senior engineers
      stopped, which the lead had previously been mediating
      about once a fortnight

4. ROUND-ROBIN REVIEWER ASSIGNMENT with a bot, excluding the
   author, weighted lightly toward people who had not touched
   that area.
   -> reviewer concentration 61% by 2 people -> 34%
   -> the two senior engineers' review load halved
   -> a side effect nobody predicted: two engineers who had
      never touched the streaming code reviewed it enough over
      a quarter to become secondary responders for it

5. FORMATTER AND LINTER made blocking in CI, with autofix on
   save.
   -> style comments per PR 2.1 -> 0.1

The formatter change was the least interesting and removed about a tenth of all comments, each of which had been costing a round trip.

Results after one quarter:

                            before      after
time to first response       9.4h        2.1h
time to merge (p50)         2.8 days     0.9 days
median cycle time            14 days     8 days
PR size (p50)               340 lines    180 lines
merged with 0-1
  substantive comments        41%         17%
review round trips (p90)       5           3
reviewer concentration
  (top 2 people)              61%         34%
escaped defects per
  month                        6.2         3.8

Escaped defects fell while review latency fell, which is the counter-intuitive part and the point of the exercise: the team was reviewing faster and better, because smaller changes are both quicker to review and possible to review properly.

One thing that did not work:

An initial attempt at a hard 400-line block in CI, before the
stacked-PR workflow existed, produced three PRs split at
arbitrary boundaries that individually did not compile, and one
merge that broke main.

Replaced with a warning plus tooling. The lesson: do not
constrain an artifact before providing the workflow that makes
the constraint achievable.

Production evidence

Cisco's large-scale code review study (Cohen et al., via SmartBear's published analysis) examined roughly 2,500 reviews across 50 developers and found defect-detection effectiveness dropping sharply with review size, with the practical recommendations of reviewing fewer than 200 to 400 lines at a time and limiting review sessions to about 60 minutes. Those are the numbers behind the 400-line guidance.

Google's code review practice, documented in its engineering practices guide, specifies both a fast response expectation (respond within one business day, and faster is better) and a change-size preference for small changes, with the explicit rationale that small changes are reviewed more thoroughly and merged faster.

Conventional Comments (conventionalcomments.org) is the published form of the prefix taxonomy, with labels including praise, nitpick, suggestion, issue and question, and its stated purpose is removing ambiguity about how strongly a comment is held.

Microsoft's and Google's published research on modern code review consistently finds that the dominant benefits reported by practitioners are knowledge transfer and design feedback rather than defect detection, which is the argument for reviewer rotation as a capability-spreading mechanism rather than only a quality one.

The DORA research programme's findings on batch size and lead time provide the systems-level version of the small-PR argument: smaller changes flow faster and fail less.

Automated formatting as a settled question is the position taken by Go (gofmt, with the explicit stance that the formatter's style is nobody's favourite and that is the point), Rust (rustfmt), and Python's black, all of which exist so that formatting stops being a review topic.

The debate

Is a review SLA realistic? Yes, if it is a response SLA rather than an approval SLA and if a scheduled slot exists. Without the calendar slot it is exhortation, and review loses every contest against focused work in the moment, which is exactly what the 9.4-hour p50 against 11 minutes of actual review time shows. The counter-argument, that scheduled review interrupts flow, is real and is why the slot goes immediately after an existing interruption like standup.

Should PR size be enforced? As a warning, yes; as a hard block, only after the workflow exists. A block without stacked-PR tooling produces artificial splits that do not compile, which is worse than a large PR. The observation that carries the argument is that past about 400 lines the comment rate collapses, so an unenforced norm plus visible data usually changes behaviour without a gate.

Is the comment taxonomy worth the ceremony? It is five prefixes, learned in a standup. The return is disproportionate because it removes the specific ambiguity that causes senior-to-senior friction, and because praise: is the only mechanism that makes review comments something other than uniformly negative. The failure is enforcing it with a bot, which makes it feel like process rather than a shared vocabulary.

Should two reviewers be required? Only where the cost is earned: security-sensitive paths, migrations, money. Everywhere else it doubles latency and produces diffusion of responsibility, where each reviewer assumes the other looked carefully, which measurably reduces the depth of both reviews.

Is code review the right place to catch defects? Partly, and the published research suggests the larger benefits are knowledge transfer and design feedback. That reframing matters for the lead, because it means reviewer rotation is a capability investment rather than an overhead, and it justifies assigning reviews to people who need the context rather than to whoever is fastest.

Should a lead review everything? No, and the instinct to is the same one that keeps a lead writing code. A lead who reviews everything is a bottleneck and a bus factor, and the two engineers doing 61 percent of reviews in the worked example were both the constraint and the ones most frustrated by it.

Follow-up Q&A

"Why is review latency the largest hidden cost in cycle time?"

Because it is time spent on work that is already finished, and nobody measures the waiting. In one measurement an item with a 14-day cycle time spent 5.3 days waiting for review and re-review, 38 percent of its life. The cost also compounds: a PR waiting two days is one the author has context-switched away from, so responding to comments requires re-orientation and the branch has drifted from main. The waiting was not reviewer effort at all: median actual review time was 11 minutes against a 9.4-hour median wait.

"How do you actually make a review SLA hold?"

Put a 20-to-30-minute review slot on everyone's calendar at a fixed time, immediately after an existing interruption like standup, and count review as work in public. Review competes with focused work and loses every contest in the moment, so the calendar makes it lose once, in advance. Then assign reviewers explicitly rather than relying on "anyone can review," which means nobody does. Commit to a response rather than an approval, so "this needs an hour of focus, I'll do it at 3pm" satisfies the SLA and still unblocks the author's planning. In one case that single calendar change took time to first response from 9.4 hours to 2.1.

"Why 400 lines?"

Because defect-detection effectiveness falls sharply past a few hundred lines, and the observable symptom is that comment density collapses. Measured by size bucket in one team, the share of PRs merged with zero or one substantive comment was 12 percent under 200 lines, 47 percent between 400 and 800, and 81 percent above 800. Past that size the reviewer cannot hold the change in their head, so they check the parts they understand and approve the rest. The team was not under-reviewing out of laziness; the artifact was unreviewable.

"What does the comment taxonomy buy?"

Three things. It makes the reviewer's authority explicit, so the author knows what they must change versus what they may. It forces the reviewer to decide how strongly they feel, which reduces blocking comments because typing blocking: on a stylistic preference feels wrong, correctly. And it makes praise: a thing that happens, which matters because without a prefix inviting it, review comments are 100 percent criticism by construction. The highest-value prefix is question:, because the ambiguity between "I'm curious" and "you should change this" is exactly where two senior engineers reliably annoy each other.

"What is the right review order and why?"

Correctness, then design and boundaries, then tests, then readability, then nits. Two reasons. Reviewer attention is finite and front-loaded, so a reviewer who starts with naming has spent it before reaching the concurrency bug. And the order matters for what a comment costs the author: a design comment on the first pass is a redesign, while the same comment after three rounds of nit-fixing is a demoralising rewrite. Get the expensive comments out first.

"Why rotate reviewers?"

It spreads context, so the bus factor on each area rises; it removes the single-owner bottleneck, which is usually also the person most frustrated by review load; and it is one of the cheapest ways to learn a system. The published research on modern code review finds that knowledge transfer and design feedback are the benefits practitioners report most, more than defect detection, which reframes rotation as a capability investment rather than an overhead. In one case round-robin assignment took the top two reviewers from 61 percent of all reviews to 34, and two engineers who had never touched the streaming code reviewed it enough over a quarter to become secondary on-call responders for it.

Common misconceptions

"Reviews are slow because people are not prioritising them." In one measurement the median review took 11 minutes and waited 9.4 hours. It is a scheduling problem, not a willingness problem.

"A thorough review takes a long time." Latency and thoroughness are independent. A two-day wait followed by a rubber stamp on a 900-line diff is the worst of both.

"Big PRs get more scrutiny because they matter more." Comment density collapses with size: above 800 lines, four in five merge with essentially no substantive comment.

"Requiring two reviewers is safer." It doubles latency and produces diffusion of responsibility. Reserve it for security, migrations and money.

"A comment is a comment." Without a prefix, a curious question reads as a mandate, which is the most common source of review friction between experienced engineers.

"The lead should review everything." That makes the lead a bottleneck and a bus factor, and it is the same instinct as a lead who keeps writing the code.

Interview delivery note

Say this verbatim: "Review latency is usually the largest hidden cost in cycle time, and it is a scheduling problem rather than a willingness problem. We measured the median review at eleven minutes of actual work and a nine-and-a-half-hour wait, so we put a 25-minute review slot on everyone's calendar after standup and time-to-first-response went to two hours." A measurement that reframes the problem and a fix that is one calendar change.

The senior-versus-staff separator is using the comment-density-by-size data to reject the obvious diagnosis. A senior lead asks people to review faster. A staff lead measures the share of PRs merged with no substantive comment by size bucket, finds it at 81 percent above 800 lines, and concludes that the team was not under-reviewing out of laziness but because the artifact was unreviewable, so the fix is PR size and the stacked-PR workflow rather than exhortation.

The second signal is not constraining an artifact before providing the workflow. Saying "we tried a hard 400-line block first, got three PRs split at arbitrary boundaries that did not individually compile and one broken main, and replaced it with a warning plus stacked-PR tooling" shows you learn from your own failed intervention and that you understand a constraint without an enabling workflow just relocates the problem.

Further reading

• SmartBear's published analysis of the Cisco code review study, for the defect-detection curve against review size and the 200-to-400-line guidance.
• Google's engineering practices guide on code review, for response-time expectations, small changes, and the reviewer's standard.
• Conventional Comments (conventionalcomments.org), for the published prefix taxonomy.
• Bacchelli and Bird, "Expectations, Outcomes, and Challenges of Modern Code Review" (ICSE 2013), for the finding that knowledge transfer and design feedback dominate the reported benefits.
• The capacity math and forecasting page, for flow efficiency, which is where review latency shows up as a system-level number.

Promotions won two quarters early, and the calibration room

What it is

A promotion is decided in a room you are not in, by people who mostly have not seen the work, using evidence that was produced months earlier. So the promotion is won two quarters before the cycle, by deliberately manufacturing the evidence and the witnesses, not by writing a good packet in the last two weeks.

The calibration room, mechanically:

  - 6 to 12 managers and senior ICs, plus a chair (often the
    director or an HR partner)
  - each candidate is presented by their manager, in 5 to 15
    minutes
  - the room compares candidates AGAINST THE RUBRIC and against
    each other, to keep the bar consistent across teams
  - one confident objection is far more powerful than three
    supportive nods, because "not yet" is the safe answer
  - the people in the room mostly have not seen your work, so
    they are evaluating your MANAGER'S ACCOUNT of it, and the
    corroboration of anyone in the room who has seen it

What this is confused with: promotion as a reward for a good year. Promotion is a statement that someone is already operating at the next level, which is a claim about scope and evidence rather than about effort or output. "They worked incredibly hard and delivered a lot" is the packet that loses, because it argues the current level well.

Also confused: the packet and the case. The packet is a document written in a two-week window. The case is the set of artifacts, witnesses and scope decisions accumulated over the preceding two to four quarters. The packet can only describe the case; it cannot create one.

The problem it solves

The predictable failure is a strong engineer who has done next-level work invisibly.

Q1  builds the migration tooling three teams later depend on.
    Nobody outside the team knows.
Q2  quietly prevents two incidents by catching design flaws in
    review. No artifact exists.
Q3  mentors two juniors to independence. Verbal only.
Q4  manager writes the packet. It says: "highly impactful,
    trusted by peers, drives quality."

In the room:
  chair:  "What is the evidence of scope beyond their team?"
  manager: "Three teams use the migration tooling."
  senior IC from another org: "I've not heard of it."
  chair:  "Let's revisit next cycle."

Nothing in that sequence was unfair. The work happened, and no
durable, attributable, corroborated evidence of it existed.

And the second failure: the person who has done the work but not at the required scope.

Rubric line, Staff: "influences technical direction beyond their
own team."

Candidate's evidence: excellent design work, all within the
team's own services, plus one cross-team consultation.

That is a genuine senior engineer performing very well. It is not
the next level, and a manager who argues otherwise loses
credibility for the next candidate they bring.

The remedy for both is the same and it is temporal: decide what the evidence will be, then assign the work that produces it, at least two quarters out.

Mechanics

Working backwards from the rubric

Take the ACTUAL rubric, line by line, not your summary of it.

  Rubric line              Current evidence      Gap
  ------------------------------------------------------------
  "solves ambiguous        the ingest redesign,  none
   problems"               Q2
  "influences technical    none outside the      THE GAP
   direction beyond        team
   their own team"
  "grows other             mentored one intern   partial: needs
   engineers"              informally            a sustained,
                                                 attributable
                                                 example
  "operational             on-call competent,    partial: no
   ownership"              no incident command   incident command

Two gaps. Both take a quarter of deliberate assignment to close,
and neither can be closed by writing better prose in the packet.

Then convert each gap into a named artifact with a date:

Gap: influence beyond the team

  Assignment: own the schema-evolution RFC that the three
  consuming teams need.
  Artifact:   the RFC document, the review meeting notes with
              the three teams, and the recorded adoption
              decision.
  Witnesses:  the two staff engineers who will be in the
              calibration room need to have read it and,
              ideally, commented on it.
  Date:       RFC circulated by end of Q1, adopted by mid-Q2,
              two quarters before the Q3 cycle.

The witness line is the one leads omit, and it is the difference between "the manager says they did this" and "someone in this room read it."

What counts as evidence

STRONG                              WEAK
------------------------------------------------------------
a written design doc with           "they're a great designer"
  named reviewers
an RFC other teams adopted          "they influence people"
an incident they commanded,         "they're strong
  with the write-up                  operationally"
a person they grew, who says so     "they mentor a lot"
  in writing
a measured outcome with a           "improved performance
  before/after number                significantly"
a system they own that other        "trusted with critical
  teams depend on                     work"

The test: could a stranger in the calibration room verify this in two minutes without asking you? Anything failing that test is an adjective.

And peer feedback is evidence, which means it must be solicited deliberately:

Ask, two quarters early, and be specific about what you need:

  "In the peer feedback round, could you write about the
   schema-evolution RFC specifically? What was useful about it
   for your team, and what would have happened without it. A
   short, concrete paragraph is worth more than a general
   endorsement."

Unsolicited peer feedback is uniformly positive and uniformly
vague, which makes it useless in the room. Solicited, specific
feedback is a citation.

The scope question, which is the real bar

Most promotion denials at senior-to-staff are about SCOPE, not
quality. The three dimensions:

  BLAST RADIUS   team -> several teams -> org -> company
  AMBIGUITY      given a task -> given a problem -> finds the
                 problem
  TIME HORIZON   this sprint -> this quarter -> this year ->
                 multi-year

A candidate can be excellent on quality and unarguably not at
the next level on all three. The lead's job in the two quarters
before is to CREATE the scope, not to argue about it later.

Creating scope is an assignment decision, and it usually means giving something up:

The cross-team migration coordination is the scope. Someone has
it now. Giving it to the candidate means the current owner does
something else, and that is a real cost with a real conversation
attached.

A lead who wants the promotion but will not reassign the scope
is asking the calibration room to promote someone for work they
were not allowed to do.

Preparing the room, not just the packet

THE CHAIR: knows the rubric best and asks the hardest question.
  Anticipate it. If the weakest line is operational ownership,
  the packet should address it before it is asked, with the
  specific evidence and, where the evidence is thin, an honest
  acknowledgment plus what has changed.

THE SKEPTIC: there is usually one, and their objection is
  usually specific. Find it in advance by pre-socialising: show
  the case to one or two people who will be in the room, a
  month before, and ask "what would you push back on?"
  That conversation is worth more than a week of packet
  editing.

THE CORROBORATOR: someone in the room who has seen the work
  first-hand. If nobody in the room has, the case rests entirely
  on your account, and one confident objection outweighs it.
  Manufacturing a corroborator is a two-quarter project: it
  means the candidate's work has to touch that person's
  world.

One confident detractor beats several supporters, because "not yet" is the reversible decision and the room is optimising against promoting someone who then struggles. So the work is not accumulating support, it is removing the specific objection.

The packet itself

Structure that survives scrutiny:

  1. THE CLAIM, in one sentence.
     "X is operating at Staff and has been for two quarters."
  2. RUBRIC LINE BY RUBRIC LINE. For each, the specific artifact
     and who can corroborate it.
  3. THE STRONGEST ITEM FIRST, and it should be a scope item,
     not an output item.
  4. THE HONEST GAP. Name the weakest line yourself, say what
     the evidence is, and what has changed. A packet with no
     weaknesses is either dishonest or describing someone who
     was promoted late.
  5. NO ADJECTIVES that are not immediately followed by an
     artifact.

Naming the weakest line yourself is counter-intuitive and it works, because the room will find it anyway, and finding it themselves reads as the manager either not knowing or concealing it.

The conversation with the candidate

TWO QUARTERS OUT, explicitly:
  "Here is the rubric. Here is where I think you are on each
   line. These two lines are the gap. Here is the work I am
   going to give you to close them, and here is the artifact I
   need to exist by June. This is not a guarantee, and I will
   tell you if my read changes."

NO SURPRISES. If the case is not going forward, say so before
the cycle, not after. The most damaging version is a candidate
who believes they are being put up and discovers in the
announcement that they were not.

AND SAY WHAT IS OUT OF YOUR CONTROL. Calibration compares across
teams and is subject to budget and headcount reality in some
organisations. Pretending it is purely meritocratic sets up a
worse conversation later.

A worked example: two candidates, one cycle

A team of nine. Two senior engineers, both strong, both wanting Staff. The lead started planning in Q1 for the Q3 cycle.

The rubric mapping, done in Q1:

Rubric line                     Candidate A       Candidate B
------------------------------------------------------------------
solves ambiguous problems       STRONG            STRONG
  (evidence)                    (ingest redesign) (search rewrite)
technical direction beyond      NONE              partial: one
  own team                                        cross-team design
                                                  review
grows other engineers           informal only     STRONG (two
                                                  people promoted
                                                  to senior)
operational ownership           STRONG (commanded partial: on-call
                                two incidents)    competent, no
                                                  incident command
written communication           weak: no durable  STRONG (three
                                artifacts         published design
                                                  docs)

The read: both had one large gap and one partial gap, and they were different gaps, which meant different assignments rather than the same advice.

Candidate A's two quarters:

GAP: influence beyond the team, and no durable written artifacts.

Assignment: own the event-schema standard that four teams needed
  and nobody owned. Explicitly a scope stretch in a familiar
  technology.

  Q1  RFC drafted. Circulated to four teams. Two rounds of
      revision from genuinely hostile feedback from one team,
      which A handled by scheduling a call rather than replying
      in the doc. That behaviour was itself later cited.
  Q2  adopted by three of four teams. The fourth declined with a
      documented reason, which A wrote up rather than hiding.
      A ran a 30-minute session at the engineering all-hands.

Artifacts by end of Q2:
  - the RFC, with 31 comments from 9 people across 4 teams
  - the adoption decision record, including the declining team's
    rationale
  - the all-hands recording
Witnesses in the room: the staff engineer from the platform team
  who had pushed back hardest and then supported it, and the
  director who chaired the adoption decision.

The hostile reviewer becoming a supporter was worth more than an easy adoption would have been, because it produced a corroborator with credibility precisely from having disagreed.

Candidate B's two quarters:

GAP: operational ownership, no incident command.

Assignment: incident commander training, then commander on the
  rotation, plus ownership of the quarterly reliability review.

  Q1  shadowed two incidents as scribe, took the IC training.
  Q2  commanded three incidents including one Sev1 lasting
      4 hours. Wrote all three postmortems. Ran the reliability
      review with the director present.

Artifacts:
  - three postmortems, one of which changed a platform-wide
    practice (the canary scope change)
  - the reliability review deck and the resulting funded work

A complication, handled honestly: the Sev1 went badly for the
first 40 minutes. B misdiagnosed and pursued the wrong path.
The postmortem said so, in B's own words, and described what
they changed.

The lead's decision was to include it in the packet rather than
omit it, on the reasoning that the room would otherwise hear
about it from the platform director who was on the call, and
hearing it from the manager first with the learning attached is
strictly better.

Including the failure was the right call and it was argued about internally. In the room, the platform director's comment was that B's postmortem was the most honest one they had read that year, which is not a sentence that would have existed had the packet omitted it.

Pre-socialisation, one month before the cycle:

The lead showed both cases to two people who would be in the
room and asked: "what would you push back on?"

On A: "The RFC is good. Is there evidence they can operate when
       there is no obvious right answer, or was the schema
       standard a case where the answer was clear and the hard
       part was coordination?"
  -> a real gap in the framing. The lead added the ingest
     redesign as the ambiguity evidence and reframed the RFC as
     the scope evidence, rather than trying to make one artifact
     carry both.

On B: "Three incidents in one quarter, and one of them went
       badly. Is that enough of a track record?"
  -> anticipated. The packet added the two shadowed incidents,
     the training, and a statement from the on-call lead about
     B's subsequent shifts.

Both objections were raised in the actual room, in almost the
same words, and both were already addressed in the packet.

Finding the objection a month early and answering it in the packet is the single highest-return activity in the whole process, and it costs two 20-minute conversations.

Outcome:

A: promoted. The discussion took 6 minutes. The platform staff
   engineer's corroboration was the decisive contribution: "I
   disagreed with the first draft and they came to me rather
   than arguing in comments. Three of my team's services depend
   on the outcome."

B: promoted. The discussion took 19 minutes, almost all of it
   about the Sev1. The chair's summary: "the postmortem is
   next-level work regardless of how the incident went."

The lead's read afterwards, recorded for the next cycle: A's
case was won in Q1 when the schema standard was reassigned away
from the person who had it. Everything after that was
documentation.

"The case was won when the scope was reassigned" is the compressed version of this whole page.

And one candidate who was not put up, handled explicitly:

A third senior engineer had asked about Staff in Q1. The lead's
honest read was two gaps and no realistic path within two
quarters, because the scope needed did not exist on the team.

That was said in Q1, in those words, along with what would need
to be true and roughly when. It was an uncomfortable
conversation and it was better than the alternative, which was
an ambiguous "let's see how the year goes" followed by an
announcement in which they were not included.

They were promoted the following year.

Production evidence

Calibration as a formal process is documented practice at Google, Meta, Amazon, Microsoft and most large technology companies, with the stated purpose of maintaining a consistent bar across managers and teams. The structure, a manager presenting a case to a panel that mostly has not observed the work, is what makes corroboration and artifacts decisive.

Published engineering career ladders (Rent the Runway's, CircleCI's, Dropbox's, Square's, and the collection at progression.fyi) all express levels in terms of scope and observable evidence rather than tenure or output volume, which is the basis for working backwards from rubric lines.

Amazon's Bar Raiser program, though a hiring mechanism, is the clearest documented instance of the asymmetry that also governs promotion panels: a designated participant empowered to block, on the principle that a wrong "yes" is more costly and less reversible than a wrong "no."

Research on structured evaluation and bias underpins why written artifacts and specific solicited feedback outperform general impressions: unstructured evaluation correlates more strongly with similarity to the evaluator, which is one reason "could a stranger verify this in two minutes" is a useful test for evidence.

Google's guidance on promotion packets and comparable published internal materials from other companies consistently emphasise concrete impact statements with measurable outcomes over descriptive praise, which is the same distinction as artifacts against adjectives.

The debate

Is it cynical to plan a promotion two quarters out? The alternative is a system where the outcome depends on whether the year's work happened to produce visible evidence, which favours people already positioned to do visible work. Deliberate planning makes the criteria explicit and available to everyone, and the lead who does it for one person and not another is the one behaving unfairly.

Should you include a failure in a packet? When the room will hear about it anyway, yes, with the learning attached. The counter-argument, that it hands the skeptic ammunition, is real, and the resolution is that an unmentioned failure surfacing from another participant is far worse: it reads as the manager not knowing or concealing. When the failure is genuinely unknown outside the team, the call is closer and the deciding question is whether the learning from it is itself next-level evidence.

Is scope creation fair to the person who currently has the scope? It is a real cost and it must be an explicit conversation, not a quiet reassignment. A lead who will not have that conversation is asking the room to promote someone for work they were not allowed to do, which is the version that actually harms the candidate.

Does pre-socialising the case game the process? It surfaces objections early so they can be addressed with evidence rather than with argument in the room. That improves the decision's information quality, and a case that cannot survive a friendly skeptic a month early was not going to survive a hostile one on the day.

Should you tell someone they are not going up? Always, early, with the specific gaps and what would close them. The counter-argument, that it demotivates, has it backwards: the demotivating version is an ambiguous "let's see," followed by an announcement that does not include them, which also destroys trust in every subsequent conversation.

Is the calibration room meritocratic? Partly, and pretending it is entirely so sets up a worse conversation later. Budget, headcount, cross-team comparison and the relative persuasiveness of different managers all affect outcomes, and saying that plainly to a candidate, alongside the parts that are within their control, is more respectful than the alternative.

Follow-up Q&A

"When is a promotion actually decided?"

Two quarters before the cycle, when the scope is assigned. The calibration room evaluates artifacts and corroboration, and both take a quarter to produce and a quarter to be noticed. The packet can only describe the case; it cannot create one. In one instance the compressed postmortem of a successful case was that it was won in Q1 when the cross-team schema standard was reassigned to the candidate from the person who held it, and everything after that was documentation.

"How do you decide what work to assign?"

Work backwards from the actual rubric, line by line, not from a summary of it. For each line, write what evidence exists today. The lines with no evidence are the gaps, and each gap converts into a named artifact with a date and a set of witnesses: the RFC document, the review notes from the three consuming teams, the recorded adoption decision, circulated by end of Q1 so that the two staff engineers who will be in the calibration room have read it. The witness line is the one leads omit, and it is what turns "the manager says they did this" into "someone in this room saw it."

"What counts as evidence in a calibration room?"

Anything a stranger could verify in two minutes without asking you. A design doc with named reviewers, an RFC other teams adopted, an incident someone commanded with the write-up, a person they grew who says so in writing, a measured outcome with a before and after number. Everything else is an adjective: "great designer", "influences people", "strong operationally", "improved performance significantly." A packet made of adjectives argues the current level well.

"Why is one objection more powerful than several supporters?"

Because "not yet" is the reversible decision and the room is optimising against promoting someone who then struggles. So the work is not accumulating support, it is removing the specific objection. That is why pre-socialising matters: show the case to one or two people who will be in the room a month early and ask what they would push back on. In one cycle both objections found that way were raised in the actual room in nearly the same words, and both were already answered in the packet. Two twenty-minute conversations, and it is the highest-return activity in the process.

"Would you include a failure in a promotion packet?"

If the room will hear about it anyway, yes, with the learning attached, because hearing it from the manager first is strictly better than hearing it from a participant who was on the call. In one case a candidate misdiagnosed the first forty minutes of a Sev1, said so in their own postmortem, and the platform director in the room called it the most honest postmortem they had read that year. That sentence would not have existed had the packet omitted the failure. When the failure is genuinely unknown outside the team the call is closer, and the deciding question is whether the learning is itself next-level evidence.

"What do you tell someone who is not going up this cycle?"

Tell them in the quarter before, not after the announcement, with the specific rubric lines, what evidence is missing, what would close it, and roughly when that is realistic. If the required scope does not exist on the team, say that too, because it is the truth and it changes what they should do. The uncomfortable early conversation is better than an ambiguous "let's see how the year goes" followed by an announcement that does not include them, which damages trust in every subsequent conversation you have with them.

Common misconceptions

"Promotion rewards a great year." It is a statement that someone is already operating at the next level, which is a claim about scope and evidence, not about effort or output.

"Write a strong packet." The packet describes a case that already exists. Two weeks of writing cannot create two quarters of artifacts and witnesses.

"Impact is enough." At senior-to-staff, most denials are about scope: blast radius, ambiguity and time horizon. Excellent work entirely inside one team is a strong senior engineer.

"Never mention a failure." An unmentioned failure surfacing from someone else in the room reads as the manager not knowing or concealing it, which costs more than the failure did.

"Support in the room is what matters." One confident objection outweighs several supporters, because deferral is the safe decision. Remove the objection rather than accumulating nods.

"The process is purely meritocratic." Budget, cross-team comparison and manager persuasiveness all affect outcomes, and saying so alongside what is controllable is more respectful than pretending otherwise.

Interview delivery note

Say this verbatim: "A promotion is decided two quarters before the cycle, when the scope is assigned. The room evaluates artifacts and corroboration, and both take a quarter to produce and a quarter to be noticed, so the packet can only describe a case it cannot create." It states the mechanism and rules out the thing most people optimise.

The senior-versus-staff separator is manufacturing a corroborator deliberately. A senior lead writes a good packet. A staff lead identifies that nobody in the calibration room has seen the candidate's work first-hand, treats that as a two-quarter problem, and assigns work that touches a specific person's world so that a credible participant can say "three of my team's services depend on this." In one case the decisive contribution came from the engineer who had pushed back hardest on the first draft, which is worth more than easy support precisely because they had disagreed.

The second signal is pre-socialising to find the objection. Showing the case to a future participant a month early and asking what they would push back on costs twenty minutes, surfaces the specific objection that would otherwise land unanswered, and converts the room from a debate into a confirmation. It is the same instinct as taking a recommendation upward rather than a question.

Further reading

• Published engineering career ladders (Rent the Runway, CircleCI, Dropbox, Square) and the progression.fyi collection, for rubric lines expressed as scope and evidence.
• Amazon's published description of the Bar Raiser role, for the asymmetry between a wrong yes and a wrong no in a panel decision.
• Google's re:Work materials on structured evaluation, for why specific written evidence outperforms general impressions.
• The growing people page, for the assignment mechanics that produce the evidence.
• The underperformance sequence page, for the same no-surprises principle applied in the other direction.

Product partnership: options with costs

What it is

Product partnership is the working relationship between an engineering lead and a product manager, and it has one defining behaviour: in discovery, you supply options with costs, not verdicts.

VERDICT       "That'll take six weeks."
              "That's not possible."
              "We'd need to rewrite the pricing service first."

OPTIONS WITH COSTS
              "A is two weeks and covers the top three merchant
               types. B is six weeks, covers everything, and makes
               the multi-currency work in Q3 nearly free because
               it lands the rate-lookup abstraction. I'd pick B if
               multi-currency is still on the roadmap, A if it
               isn't. Which is it?"

The second answer contains the same engineering judgment, and it hands the decision to the person whose decision it is while making your reasoning inspectable.

The other half of the job: own the non-functional requirements, because PMs almost never write latency, availability or cost targets, and if you do not, nobody will.

What this is confused with: being accommodating. A partner who says yes to everything is not a partner, they are a queue. Options with costs is a form of pushback, and a much more effective one than refusal, because it makes the cost visible rather than making you the obstacle.

Also confused: protecting the team. A lead who protects the team by being obstructive wins the individual battle and loses the partnership, and the PM starts routing around them, at which point the team is protected from nothing.

The problem it solves

The verdict-based relationship degrades in a predictable sequence.

Week 1   PM: "can we ship X by the 14th?"
         Lead: "no, that's six weeks of work."
Week 3   PM asks a different engineer, who says "probably doable."
Week 5   PM commits to a customer without asking.
Week 7   Lead escalates about process. PM's manager hears it as a
         complaint about their PM.
Week 9   the lead is invited to fewer discovery conversations,
         because they are "the person who says no", and now
         hears about commitments after they are made.

Nobody behaved unreasonably at any single step. The first
answer contained no information the PM could use, so they went
looking for information elsewhere.

"No, six weeks" is a true statement that is useless, because it does not tell the PM what a shorter version would look like, what the six weeks buys, or what would have to be true for the date to work. Every one of those is something the lead knows and the PM does not.

And the non-functional gap:

A feature spec, as written:
  "Merchants can see a live view of their orders."

Not written, and nobody will write it unless the lead does:
  - how live is live? 1 second? 30 seconds? 5 minutes?
  - what happens when the merchant has 200,000 orders?
  - what is the availability target, and what does degraded look
    like?
  - what is the cost ceiling? A 1-second refresh for 40,000
    merchants is a materially different system from a 30-second
    one.

These get decided anyway: by whoever writes the code, implicitly,
under deadline pressure, and discovered in production.

Mechanics

Constructing an options set

Three options is the useful number, and they should differ in kind rather than in size.

Bad options (all the same option at different sizes):
  A: 4 weeks   B: 6 weeks   C: 8 weeks

Good options (different shapes, different costs, different
consequences):

  A  NARROW: the top 3 merchant types only. 2 weeks. Covers 71%
     of order volume. Leaves the long tail on the old flow, which
     we would keep running.
     Risk: two flows to maintain until the tail is migrated.

  B  FULL: all merchant types. 6 weeks. Also lands the
     rate-lookup abstraction, which makes the Q3 multi-currency
     work roughly 3 weeks cheaper.
     Risk: the 14th is not achievable.

  C  MANUAL-ASSIST: A, plus a support tool so the ops team can
     handle the tail by hand. 3 weeks. Covers 100% of merchants
     from the merchant's point of view.
     Risk: ~4 hours a week of ops time until we do B.
     Cost: ~$X/month of ops capacity, which is a real number
     someone should decide to spend.

My recommendation: C if the 14th is a hard external commitment,
B if it is a preference, because B's Q3 saving exceeds C's
difference within a quarter.

Four properties make an options set useful:

1. EACH OPTION IS ACTUALLY SHIPPABLE. An option that requires a
   later phase to be valuable is not an option, it is a
   milestone.
2. THE COST IS IN THE PM'S UNITS where possible: coverage,
   merchants, volume, revenue exposure, ops hours. Weeks alone
   is an engineering unit.
3. THE CONSEQUENCE IS NAMED, including the ones you would rather
   not mention. "Two flows to maintain" is the cost of A, and
   omitting it makes A win a decision it should not.
4. YOU RECOMMEND ONE, with the condition attached. A set of
   options with no recommendation is abdication wearing the
   costume of neutrality.

The recommendation with a condition is the highest-value sentence: "I'd pick B if multi-currency is still on the roadmap, A if it isn't" tells the PM exactly what fact decides it, and that fact is usually one they have and you do not.

Owning the non-functional requirements

Write them into the spec yourself, as numbers, before the work
starts:

  LATENCY      p50 and p99, at the user-visible boundary
  FRESHNESS    how stale may the data be
  AVAILABILITY the target, and what degraded mode looks like
  SCALE        the largest realistic case, not the median
  COST         a ceiling, in currency per month or per unit
  RETENTION    how long is the data kept, which is also a
               compliance question
  ACCESS       who may see it, which is where most rework comes
               from

For each, ask the PM ONE question that produces the number:

  "How stale can this be before a merchant would call support?"
  -> gets you a freshness target from someone who knows the
     customer, which is far better than you guessing.

  "What is the biggest merchant we need this to work for?"
  -> gets you the scale case. The answer is often startling and
     always cheaper to hear now.

Translating each into product language is what makes it survive prioritisation:

Engineering framing        Product framing
------------------------------------------------------------
"we need to add caching"   "this cuts checkout p99 by 300ms,
                            and our own data says every 100ms
                            there has historically moved
                            conversion by X"
"the pipeline needs        "right now a merchant sees yesterday's
 rework"                    numbers until 10am, which is the
                            second-most-common support ticket"
"we should fix the         "a bad deploy currently takes 25
 deploy process"            minutes to roll back, so a
                            checkout-breaking bug costs us
                            roughly $Y of orders"

The pattern: state the user-visible or money consequence, and use the company's own historical numbers rather than industry claims. "Amazon found 100ms costs 1 percent of sales" is a citation about Amazon; "our last three latency regressions each moved conversion by this much" is an argument about you.

Knowing the product

A lead who cannot name the product's north star metric looks
disconnected, and reasonably so.

Know, and be able to say without looking:
  - the north star metric and its current value
  - the two or three inputs that move it
  - which of your systems touches which input
  - the current quarter's product goal, in the PM's words
  - the top 3 sources of support tickets

The last one is the most under-used. Support tickets are a
free, continuously updated list of what your systems do badly,
expressed in customer language, and almost no engineering lead
reads them.

Pushing back well

NEVER: "that's not possible"
       (it is; you mean it is expensive, and saying the wrong
        word costs you credibility when something genuinely is
        impossible)

INSTEAD, three shapes depending on what is wrong:

TOO MUCH FOR THE TIME
  "Here is what fits in that window, and here is what it leaves
   out. If the cut is unacceptable, the date moves. Which do you
   want to change?"
  -> the scope/date/quality triangle, offered as a choice rather
     than asserted as a law.

WRONG PROBLEM
  "Before we build this, the thing merchants actually complain
   about is X, and I think this solves Y. Can we check?"
  -> only credible if you read the support tickets, which is why
     that habit matters.

MISSING A CONSTRAINT
  "This works until a merchant has more than about 50,000
   orders, and 40 of them do. We can build it as specified and
   it will break for our biggest customers, or we can spend two
   extra weeks. Your call, and I'd spend the two weeks."
  -> the non-functional requirement, surfaced as a decision.

Always offer at least two acceptable outcomes. A pushback with one acceptable outcome is a refusal, and refusals are what get leads routed around.

The process conversation, separated

When a PM commits to a date without asking, there are two problems, and solving only the immediate one guarantees a repeat.

THE DATE: solved with options and costs, immediately, in front of
whoever needs it. Do not litigate the process here.

THE PROCESS: a separate, calm, private conversation, framed as
helping them rather than correcting them.

  "I want to make sure you can commit to dates confidently. For
   that you need me in the room before the number goes out.
   What would make that easy for you?"

Framing it as making them more credible works far better than
"don't do that again", which produces defensiveness and no
change.

IF IT REPEATS: escalate with data, not grievance. The specific
commitments, what they cost in engineer-weeks, and a proposed
working agreement. And bring your own manager as a peer
conversation with theirs, not as a complaint.

A worked example: a lead who was being routed around

A payments team. The lead had a reputation, stated in their own performance feedback, as "protective of the team" and "sometimes a blocker." Discovery conversations were happening without them.

What was actually happening, from four months of examples:

Ask 1: "Can we support instalment plans by end of quarter?"
  Answer given: "Not without rewriting the settlement service."
  What the PM did: nothing for three weeks, then scoped a
  narrower version with a different engineer.

Ask 2: "Can merchants see live order status?"
  Answer given: "Sure, that's easy."
  What happened: built with a 5-second poll, no scale
  requirement written down, and it fell over for the four
  largest merchants in week two.

Ask 3: "Can we ship the refunds change by the 14th?"
  Answer given: "That's six weeks of work."
  What the PM did: committed to the 14th anyway, having heard
  from someone else that a partial version was possible.

Three different failure modes: a verdict with no options, a yes with no non-functional requirements, and a refusal that was routed around.

The change, applied over one quarter:

Ask 1, re-answered in the new form:

"Three options.

 A. Instalments for the two card processors that already support
    it natively. 3 weeks. Covers about 62% of instalment-eligible
    volume based on last quarter. The other processors show
    'not available', which is a product decision you should
    make rather than me.

 B. Full coverage, which needs the settlement service to handle
    multi-leg transactions. 9 weeks. It also removes the
    reconciliation workaround that costs finance about 6 hours
    a month, so finance would get that back.

 C. A, plus a manual settlement process for the remaining
    processors, run by ops. 4 weeks. Covers 100% from the
    merchant's view, costs ops roughly 5 hours a week, and I
    would want a hard expiry on it, because manual settlement
    processes never get removed on their own.

 I'd pick A if the goal is learning whether merchants want
 instalments at all, and B if we already know they do and this
 is about coverage. Which is it?"

The PM's answer took 30 seconds: it was a learning goal. They
shipped A.

The 30-second answer is the point. The original verdict cost three weeks of stalled discovery and produced a worse plan; the options set resolved it in one conversation because it asked the PM a question only they could answer.

Ask 2, re-answered with non-functional requirements written first:

The lead wrote five lines into the spec before estimating:

  Freshness: how stale can order status be before a merchant
    calls support?              -> PM's answer: "under a minute
                                    is fine, they're not
                                    watching it continuously"
  Scale: largest merchant?      -> 212,000 open orders
  Availability: what does
    degraded look like?         -> "showing a slightly stale
                                    number is fine; showing an
                                    error is not"
  Cost ceiling?                 -> nobody had thought about it;
                                    agreed at $2,000/month
  Access: who can see it?       -> merchant's own orders only,
                                    plus support with an audit
                                    log

The 5-second poll implied by "live" would have been:
  40,000 merchants x 12 polls/min = 480,000 req/min
A 45-second refresh with server-push for changes:
  ~2,000 req/min plus a change stream.

Same product outcome. Roughly two orders of magnitude of
infrastructure difference, decided by one question to the PM
about what "live" meant.

"How stale can this be before a merchant calls support" is a question the PM can answer in five seconds and the engineer cannot answer at all, which is the general shape of a good non-functional question.

Ask 3, and the process conversation:

The date conversation, in the room, immediately:

  "By the 14th we can ship refunds for single-item orders, which
   is 78% of refund requests. Multi-item and partial refunds
   would follow in three weeks. Alternatively everything by the
   5th of next month. If the 14th is a customer commitment
   that's already made, tell me and we'll do the first one."

It was a customer commitment already made. They shipped the
78% version, and the customer was satisfied because their
volume was single-item.

The process conversation, two days later, privately:

  "That worked out, and I want to make it easier next time. If
   I'm in the room before a date goes to a customer, I can tell
   you what fits, which is usually more than you'd assume. What
   would make it easy to loop me in?"

The PM's honest answer: "I didn't because I expected you to say
no, and I needed to give them something."

That sentence is the actual finding, and it is a diagnosis of
the lead's behaviour rather than the PM's.

"I expected you to say no" is the whole page in five words, and it was only available because the conversation was framed as help rather than correction.

Measured over the following two quarters:

                                before      after
lead present in discovery
  conversations                   ~40%        ~95%
commitments made without
  engineering input             4/quarter    0
NFRs written before estimate    0 of 11      11 of 13
rework attributable to a
  missed NFR                    3 features     0
features shipped as a narrower
  option than originally asked   0             5

Five features shipped as a narrower option is the number that mattered to the PM, because each one arrived earlier than the full version would have, and in three cases the full version turned out not to be needed.

The reputation change, and the honest part:

The next round of feedback described the lead as "the person who
finds the version we can actually ship."

The lead's own read, recorded: nothing about their engineering
judgment changed. The same constraints were true before. What
changed was that the judgment arrived in a form the PM could
act on, and that they asked the PM questions instead of
answering questions the PM had not asked.

Production evidence

Marty Cagan's product-discovery writing (Inspired, and the Silicon Valley Product Group materials) argues explicitly for engineers participating in discovery rather than receiving specs, with the stated reason that engineers are the largest source of ideas about what is newly possible, and that the cost of an approach is information only they have.

The "options with costs" pattern is the practical form of the same argument, and it appears in engineering-leadership writing as the alternative to feasibility verdicts, on the grounds that a verdict transmits a conclusion while withholding the inputs.

Service level objectives as a product artifact is the position taken in Google's SRE materials: availability and latency targets are product decisions with cost consequences, and the SRE practice of negotiating them with product owners exists because leaving them implicit means they are set by accident.

The scope-date-quality triangle and the practice of cutting scope rather than quality is standard delivery guidance, and the specific form that works with a product partner is offering the choice rather than asserting the constraint.

Support-ticket analysis as a product input is standard in customer-experience practice and unusual in engineering leadership, which is what makes it a differentiator: the tickets are a continuously updated, customer-worded list of what your systems do badly.

Amazon's widely cited latency-to-revenue findings and Google's comparable published results are the reason latency-to-conversion translation is credible as a category, and the stronger version of the argument uses your own historical numbers rather than theirs.

The debate

Is "options with costs" just avoiding a decision? No, and the distinguishing feature is the recommendation with a condition attached. A set of options with no recommendation is abdication; a set with "I'd pick B if multi-currency is still on the roadmap" is engineering judgment plus the explicit statement of which fact decides it, and that fact usually belongs to the PM.

Should engineers write non-functional requirements, or should PMs? In principle PMs; in practice nobody does unless the lead does. The productive version is that the lead writes the question and the PM supplies the number: "how stale can this be before a merchant calls support" is answerable by the PM in seconds and not answerable by the engineer at all.

Is it the lead's job to know the north star metric? Yes, and a lead who cannot name it will be treated as a service function, reasonably. The counter-argument, that engineers should be shielded from business context to focus, has it backwards: without it, every prioritisation argument the lead makes is in engineering units, which lose.

Should you ever say no? Yes, for things that are genuinely unsafe, illegal or impossible, and sparingly enough that it retains meaning. Saying "not possible" when you mean "expensive" spends the word, and then the one time something truly is impossible you have no way to say so.

Is protecting the team from the PM part of the job? Protecting focus is; being the obstacle is not. A lead who blocks is routed around, and a team whose lead is routed around is not protected, it is uninformed. The version that works is absorbing the negotiation rather than the refusal.

Does the process conversation actually work? When it is separated from the immediate decision and framed as making the other person more credible, usually. When it is held in the same conversation as the date, it reads as blame and produces defensiveness, which is why the separation is the mechanism rather than the wording.

Follow-up Q&A

"What does 'options with costs' look like concretely?"

Three options that differ in kind rather than in size, each independently shippable, each with its cost expressed in the PM's units and its consequence named including the inconvenient ones, plus your recommendation with the condition that decides it. "A covers the top three merchant types in two weeks and 71 percent of volume, but leaves two flows to maintain. B is six weeks, covers everything, and makes the Q3 multi-currency work three weeks cheaper. C is A plus an ops tool, three weeks, 100 percent coverage from the merchant's view at about four hours a week of ops time. I'd pick B if multi-currency is still on the roadmap, A if it isn't." The last sentence tells the PM exactly which fact decides it, and that fact is usually theirs.

"Why is 'that'll take six weeks' a bad answer?"

Because it is true and contains nothing the PM can act on. It does not say what a shorter version would look like, what the six weeks buys, or what would have to change for the date to work, and all three are things the lead knows and the PM does not. The observable consequence is that the PM goes looking for that information elsewhere, gets a less-informed answer from someone else, and the lead stops being invited to discovery. In one case a PM said plainly: "I didn't loop you in because I expected you to say no, and I needed to give them something."

"Who owns the non-functional requirements?"

Nominally the PM, actually nobody unless the lead writes them, and they get decided anyway by whoever writes the code under deadline pressure. The workable division is that the lead writes the question and the PM supplies the number: how stale can this be before a merchant calls support, what is the biggest merchant this must work for, what does degraded look like, what is the cost ceiling, who may see it. In one case asking what "live" meant produced "under a minute is fine," which was the difference between 480,000 requests a minute and about 2,000.

"How do you translate platform work into product language?"

State the user-visible or money consequence, using your own historical numbers rather than industry claims. Not "we need caching" but "this cuts checkout p99 by 300 milliseconds, and our own data says every 100 milliseconds there has moved conversion by X." Not "the deploy process needs work" but "a checkout-breaking bug currently takes 25 minutes to roll back, which costs roughly this much in orders." The company's own numbers are an argument about you; a citation about Amazon is an argument about Amazon.

"How do you push back without becoming the person who says no?"

Always offer at least two acceptable outcomes, because a pushback with one is a refusal. Depending on what is wrong: for too much in the time, "here is what fits and here is what it leaves out; if the cut is unacceptable the date moves, which do you want to change." For the wrong problem, "the thing merchants actually complain about is X and this solves Y, can we check," which is only credible if you read the support tickets. For a missing constraint, "this breaks above 50,000 orders and 40 merchants are above that; we can ship as specified and break for our biggest customers, or spend two extra weeks, and I'd spend them."

"A PM commits to a date without asking you. What do you do?"

Separate the two problems, because solving only the immediate one guarantees a repeat. The date gets options and costs, immediately, in front of whoever needs it, with no process litigation. The process gets a separate private conversation days later, framed as making them more credible rather than correcting them: "if I'm in the room before a date goes out, I can tell you what fits, which is usually more than you'd assume; what would make it easy to loop me in?" If it repeats after that, escalate with data rather than grievance: the specific commitments, what they cost in engineer-weeks, and a proposed working agreement, brought as a peer conversation between managers rather than a complaint.

Common misconceptions

"Giving options is indecisive." Options without a recommendation are. Options with a recommendation and the condition that decides it are engineering judgment made inspectable.

"Saying no protects the team." It gets you routed around, after which the team is not protected, it is uninformed about commitments already made.

"The PM owns the requirements." They own the functional ones. Latency, freshness, scale, availability and cost get decided by whoever writes the code unless the lead writes them down first.

"'Not possible' is a strong position." It is usually the wrong word for "expensive," and using it that way spends the credibility you need for the rare case that is genuinely impossible.

"Business context distracts engineers." Without it every prioritisation argument you make is in engineering units, and engineering units lose.

"Fix the process in the moment." Litigating the process during the date conversation reads as blame. Separating them by a couple of days is the mechanism, not the wording.

Interview delivery note

Say this verbatim: "My job in discovery is to supply options with costs, not verdicts. 'Six weeks' is true and useless; three shippable options with the cost in the PM's units, the consequences named, and a recommendation with the condition attached, lets them decide with my judgment included rather than going to find a less-informed answer elsewhere." It names the behaviour and the failure it prevents.

The senior-versus-staff separator is owning the non-functional requirements by asking the PM the question rather than guessing the number. A senior engineer estimates the feature as specified. A staff engineer writes freshness, scale, availability, cost and access into the spec before estimating, and asks one question per line that only the PM can answer, such as "how stale can this be before a merchant calls support." In one case that single question was the difference between 480,000 requests a minute and 2,000, for the same product outcome.

The second signal is separating the date from the process. Handling the immediate commitment with options in the room, then holding the process conversation privately days later framed as making the PM more credible, is what produced the honest answer "I didn't loop you in because I expected you to say no." That sentence is a diagnosis of the lead, and you only get it if the conversation is not framed as a correction.

Further reading

• Marty Cagan, Inspired, and the Silicon Valley Product Group materials on engineers in discovery.
• Google's SRE Book on service level objectives as negotiated product decisions with cost consequences.
• Your own product's support-ticket taxonomy, which is the cheapest continuously updated list of what your systems do badly.
• The a PM promises a date and a director wants a date you cannot commit to pages, which are the scenario forms of this page.

Retention: knowing each person's actual motivator

What it is

Retention as a lead's discipline is two things: knowing what each individual actually wants, which is usually not what you assume, and noticing the departure three months before the resignation.

The six motivators, and they are not equally distributed:

  SCOPE        wants a bigger problem, more ownership, harder
               work
  LEARNING     wants to be growing; boredom is their exit signal
  MONEY        wants compensation, and says so or does not
  TITLE        wants the label, often for reasons outside this
               company (visa, family, next role, credibility)
  FLEXIBILITY  wants control over when and where; often
               non-negotiable for reasons you do not see
  TEAMMATES    stays for the people; the exit signal is someone
               else leaving

Most people have a primary and a secondary, and they change over time. A person motivated by learning at 26 may be motivated by flexibility at 34 for reasons that have nothing to do with work, and a lead operating on a two-year-old model of them is managing someone who no longer exists.

What this is confused with: engagement surveys and perks. An aggregate satisfaction score tells you the team's average and nothing about the person who is leaving. Retention is individual, and the information is in one-to-ones, not in a dashboard.

Also confused: retention and counter-offers. By the time someone has an offer, the decision is mostly made, and a counter-offer resolves the symptom that was easiest to name. Most regretted attrition is visible three months out, and that is where the intervention belongs.

The problem it solves

The default failure is a lead who assumes their own motivator is universal.

A lead motivated by scope, managing five people:

  Alex   also scope-motivated. Well served, gets bigger problems.
  Sam    learning-motivated. Given more of the same work, which
         reads to the lead as "trusting them with the important
         system" and reads to Sam as being stuck.
  Priya  flexibility-motivated, with a caregiving situation the
         lead does not know about. Offered a promotion that comes
         with more meetings at fixed times. Declines. The lead
         reads this as low ambition.
  Jo     money-motivated, in a market where their skills are
         repricing. Has never raised it, because raising it feels
         crass. Interviewing.
  Dev    teammate-motivated. Fine, until Alex leaves.

Four of five are being managed against the wrong model, and the
lead's own read is that the team is "solid".

And the cost of one regretted departure is large and mostly invisible:

Direct:      recruiting fees or recruiter time, interview loop
             time across 5 to 8 people, onboarding
Indirect:    3 to 6 months to full productivity for a
             replacement, and the departing person's knowledge
             leaves with them
Second-order: the team's remaining members reassess. A senior
             departure is often followed by others within two
             quarters, because it makes leaving thinkable.

Conservative estimates for a senior engineer commonly land
between six months and a year of salary, all in, and the
second-order effect is the part that is never counted.

Mechanics

Finding the actual motivator

You cannot ask "what motivates you" and get a useful answer, because people answer with what they think is expected. Ask about specifics and infer.

Questions that produce real information:

  "What was the best three-month stretch you've had at work,
   here or anywhere? What made it good?"
  -> the answer names the motivator without the person having
     to classify themselves.

  "If you could stop doing one thing entirely, what would it
   be?"
  -> the friction. Often flexibility or scope in disguise.

  "What's something you want to be able to do in two years that
   you can't do today?"
  -> learning, and specifically which learning.

  "When you look at people a level or two above you here, whose
   job would you actually want?"
  -> distinguishes people who want the next level from people
     who want more of what they do now, which is the most common
     mismatch in promotion conversations.

  "Is there anything about how we work that's harder for you
   than it needs to be?"
  -> the flexibility question, asked in a way that does not
     require disclosing why.

And then watch what they choose when given a choice, because stated and revealed preferences differ:

Offered an interesting but low-visibility project versus a
routine but high-visibility one:
  takes the interesting one   -> learning or scope
  takes the visible one       -> title, or promotion-directed

Offered a conference or the equivalent in a bonus:
  -> learning versus money, cleanly

Consistently protects a specific time block
  -> flexibility, and the reason is not your business unless
     they offer it

Write it down, per person, and revisit it every six months, because the failure is not usually ignorance, it is an out-of-date model.

The three-month signals

Most regretted attrition is visible in advance if you are looking, and the signals are behavioural rather than stated.

STRONG SIGNALS (something changed)
  - stopped arguing. A person who used to push back in design
    reviews and now agrees with everything has disengaged, not
    mellowed. THIS IS THE EARLIEST AND MOST RELIABLE SIGNAL.
  - stopped talking about the future. No more "next quarter we
    should", no opinions about the roadmap.
  - declining optional things they used to do: interviews,
    onboarding, the guild, the brown bag.
  - suddenly using vacation in single days, or a cluster of
    "appointments"
  - their work is fine and their initiative is gone. Tickets
    closed, nothing proposed.
  - social withdrawal: leaves the team channel banter, stops
    joining the optional coffee

WEAK SIGNALS (often nothing)
  - LinkedIn activity. Recruiters spam everyone.
  - one bad week
  - complaining. A person who complains is still invested;
    the ones who stop complaining are the ones to worry about.

"Stopped arguing" is the signal worth memorising, because it is early, behavioural, and counter-intuitive: engagement looks like friction, and a lead who enjoys the quieter version has mistaken disengagement for maturity.

Acting on a signal

DO NOT: ask "are you thinking of leaving?" It is unanswerable
        honestly, and it puts the person in the position of
        either lying or disclosing before they are ready.

DO:     name the change, specifically, and ask an open question.

  "You used to push back hard in design reviews and I've noticed
   you haven't in a while. That was useful to me and I miss it.
   What's changed?"

That is SBI feedback applied to a retention signal: a specific
situation, an observable behaviour, and the impact, followed by
a question rather than a conclusion.

The answers you get are usually one of:
  - a specific grievance you can address
  - "I'm bored", which is a fixable assignment problem
  - "I don't think I'm going anywhere here", which is a
    fixable-if-true career conversation
  - a life change you did not know about
  - or nothing, in which case you have at least signalled that
    you are paying attention

Recognise before they ask

The rule: address the motivator before the person raises it,
because by the time they raise it, they have already spent
weeks deciding whether to.

MONEY      Do the market check yourself, annually, per person.
           If someone is 15% below market for their level, that
           is your problem to fix before they discover it, and
           an off-cycle adjustment costs a fraction of a
           replacement.
           The uncomfortable truth: people rarely ask, and the
           ones most underpaid are often the ones least likely
           to.

SCOPE      Give the bigger problem before they ask for it. A
           person who has to ask for scope has already
           concluded you were not going to offer it.

LEARNING   Rotate deliberately. Boredom in a strong engineer is
           a retention risk with a cheap fix, and it is almost
           always cheaper than the replacement.

TITLE      Find out WHY the title matters. Sometimes it is a
           visa, a family expectation, or a credibility problem
           with an external partner, and some of those have
           solutions that are not a promotion.

FLEXIBILITY Say yes where you can, quickly, and without
           requiring an explanation. The cost is usually near
           zero and the loyalty return is disproportionate.

TEAMMATES  When someone leaves, the follow-up conversation with
           their closest colleagues is not optional. A
           departure makes leaving thinkable for everyone
           nearby.

The money one deserves the emphasis: internal raises are almost always cheaper than replacement, and the arithmetic is not close, yet the process for a proactive adjustment is usually harder than the process for a backfill requisition. That asymmetry is an organisational bug a lead can sometimes fix by arguing it in advance rather than in a resignation week.

The stay conversation

Run it before there is a problem, once or twice a year, explicitly framed.

"This isn't a performance conversation and it isn't a career
 plan. I want to know what would make you stay for another two
 years, and what would make you leave. You don't have to answer
 the second one."

Then ask:
  - "What is the best part of your job right now?"
  - "What is the part you'd change if you could?"
  - "What would another company have to offer you for you to
     take the call seriously?"   <- the most informative
     question, and it works because it is hypothetical
  - "Is there anything you want that you haven't asked for
     because you assumed the answer was no?"

The last question is the one that surfaces flexibility and
scope requests people have silently written off.

Counter-offers

The position: usually do not, and know why.

By the time someone has an offer:
  - the decision is mostly made; the offer is the conclusion of
    a process that started months earlier
  - a counter-offer fixes the most nameable reason, usually
    money, which is often not the actual reason
  - published follow-up on accepted counter-offers is
    consistently poor: a large fraction leave within a year
    anyway
  - and it teaches the team that resigning is the mechanism for
    a raise

THE EXCEPTIONS, and they are real:
  - the reason is genuinely and solely compensation, they are
    genuinely underpaid, and you can fix it permanently rather
    than as a retention bonus
  - the departure is catastrophic on a specific timeline and you
    need three months, in which case be honest that it is a
    bridge

Either way, treat the resignation as a failure of the previous
three months, and run the retrospective on yourself.

A worked example: five people, five different problems

A team of nine, two regretted departures in the previous year, a third person the lead suspected was looking. The lead's own model, written down before the conversations, turned out to be wrong for four of the five people they examined.

The stay conversations, run over two weeks:

PERSON   lead's assumed motivator   actual
------------------------------------------------------------
Alex     scope                      scope. Correct.
Sam      scope (they were the       LEARNING. "I've been the
         strongest engineer, so      streaming person for two
         the lead assumed they       years. I could do it in my
         wanted more of it)          sleep, and that's the
                                     problem."
Priya    money                      FLEXIBILITY. Had declined a
                                     promotion because it added
                                     three fixed-time meetings a
                                     week, and had never
                                     explained why.
Jo       learning                   MONEY. Market for their
                                     specialisation had moved.
                                     Had never raised it: "it
                                     felt like a bad look."
Dev      teammates                  TITLE, for a specific
                                     external reason: a
                                     permanent-residency
                                     application where the job
                                     title was material.

Four of five wrong is not unusual, and each wrong model had produced a specific management error:

Sam:   given MORE streaming work, as a reward. Read as being
       trapped.
Priya: read as unambitious for declining a promotion, which had
       quietly affected how the lead assigned work.
Jo:    given conference budget and interesting problems, which
       they enjoyed and which did not address the thing.
Dev:   given more responsibility without a title change, which
       was precisely the wrong currency.

The interventions, and their cost:

SAM (learning): moved off streaming as primary within six weeks,
  onto the new search-relevance work, which was genuinely
  unfamiliar. Paired with the job of growing Priya into
  streaming, which also fixed a bus factor.
  Cost: about six weeks of reduced throughput.
  Sam, six months later: "this is the first time in two years
  I've had to look something up."

PRIYA (flexibility): the three fixed meetings became two, one
  async. The promotion was re-offered and accepted.
  Cost: near zero. The lead's own note: "this was available the
  entire time and I never asked."

JO (money): market check confirmed roughly 18% below the current
  market for their specialisation. The lead built the case with
  three comparable data points and took it to their director as
  a retention risk with a number attached, before Jo had an
  offer.
  Outcome: an off-cycle adjustment of 14%, six weeks later.
  Cost of the adjustment, annualised: roughly a fifth of the
  all-in cost of replacing them.
  Jo's reaction, which is the part worth recording: relief,
  followed by "I didn't know that was something I could ask
  for."

DEV (title): the title mattered for a permanent-residency
  application, which the lead had no way to know and Dev had not
  volunteered because it felt like a personal matter. The
  company had a "Senior Engineer II" title that existed in the
  ladder and was not being used. Dev met the bar for it on the
  rubric. Granted at the next cycle, three months early.
  Cost: zero, other than the calibration conversation.

ALEX (scope): already correct. Given the cross-team platform
  ownership, which was the next available scope.

Two of the four fixes cost essentially nothing and had never been asked for, which is the recurring finding: the constraint was information, not budget.

The three-month signal, caught on the third person:

The engineer the lead suspected was looking had stopped pushing
back in design reviews about two months earlier. The lead had
noticed it and read it as "they've settled in".

The conversation, using SBI:
  "You used to be the person who found the hole in a design, and
   you haven't done that in a couple of months. That was useful
   to me and I've missed it. What changed?"

The answer: they had proposed a significant architectural
direction eight months earlier, it had been declined without a
reason they found satisfying, and they had concluded that
proposing things was not worth the effort.

That is a specific, addressable, entirely self-inflicted
problem. The lead's fix: revisited the original proposal
properly, wrote down why two-thirds of it was now viable and
one-third was not, and gave them the two-thirds to own.

They stayed. Their own later account was that the decision to
leave had been about 70% made when the conversation happened.

"Stopped arguing" was the only visible signal and it had been misread as maturity, which is the specific error this page exists to prevent.

Twelve months later:

                              before      after
regretted attrition        2 in 12 mo      0
people >10% below market        2           0 (both adjusted)
declined promotions             1           0
average tenure at review
  of motivator model           n/a      6 months, written down
stay conversations held         0        2 per person per year

And the honest caveat the lead recorded:

One of the two fixes that "cost nothing" (Priya's meetings) was
only free because the lead had authority over the meeting
structure. The money fix required a director who was willing to
run an off-cycle adjustment, which is not universally available.

Recorded so that the next person reading this does not conclude
that all retention problems are free to fix. Some are budget
problems, and the lead's job there is to make the arithmetic
visible early rather than to pretend otherwise.

Production evidence

Exit-interview research consistently finds that the reasons people give for leaving differ from the reasons that actually drove the decision, and that the decision typically forms over months, which is the empirical basis for the three-month window and for the limited value of counter-offers.

Published analyses of accepted counter-offers consistently report high subsequent turnover within a year, which is the evidence behind treating a counter-offer as a bridge rather than a fix.

Cost-of-turnover estimates for technical roles commonly range from six months to over a year of salary when recruiting, interviewing, onboarding and time-to-productivity are included, which is what makes a proactive market adjustment cheap by comparison.

Google's Project Oxygen identified career development and individual attention among the manager behaviours most associated with team outcomes, and its finding that managers matter measurably for retention is the large-sample version of this page's argument.

Self-determination theory (Deci and Ryan), and Daniel Pink's popularisation as autonomy, mastery and purpose, is the research basis for treating motivation as individually varied and largely intrinsic above a compensation threshold, which is why a single perk or a single lever does not work across a team.

"Stay interviews" are an established retention practice in HR literature, explicitly designed to gather the information an exit interview gathers, at a point where it can still be used.

The debate

Should you ask directly whether someone is leaving? No. It is unanswerable honestly and forces a disclosure before they are ready, and the answer you get is uninformative either way. Naming the observed behavioural change and asking an open question gets the real information, because it is about something specific you both saw.

Are counter-offers ever right? Rarely, and the two exceptions are real: when the reason is genuinely and solely compensation and you can fix it permanently, and when you need a specific bridge and are honest that it is one. Otherwise it fixes the most nameable reason rather than the actual one, and it teaches the team that resigning is the raise mechanism.

Is it the lead's job to fix compensation? To surface it with data, yes, always. The counter-argument that compensation is HR's domain is how people end up 18 percent below market without anyone noticing, and the person most underpaid is often the one least likely to raise it. The lead may not control the outcome; they control whether the arithmetic is visible before the resignation.

Do stay conversations feel artificial? Somewhat, the first time, and the framing removes most of it: saying explicitly that it is not a performance conversation and not a career plan resets the expectation. The alternative is learning the same information in an exit interview, where it is free to say and useless to act on.

Is high retention always good? No. A team with zero turnover for years accumulates a fixed set of perspectives and often has people who have stopped growing and stayed anyway. The goal is zero regretted attrition, and distinguishing the two honestly is part of the job.

Should you tell someone their motivator? Not as a label. Use it to make decisions, not to categorise people to their face, because the categories are a lead's working model rather than a truth about anyone, and being told you are "money-motivated" lands badly and inaccurately.

Follow-up Q&A

"How do you find out what actually motivates someone?"

Not by asking what motivates them, because people answer with what they think is expected. Ask about specifics and infer: what was the best three-month stretch you have had and what made it good; if you could stop doing one thing entirely what would it be; whose job a level or two above you would you actually want. Then watch revealed preference, which is what they choose when given a real choice between an interesting low-visibility project and a routine high-visibility one, or between a conference and the equivalent bonus. Write it down per person and revisit every six months, because the usual failure is an out-of-date model rather than no model.

"What is the earliest reliable signal that someone is leaving?"

They stopped arguing. A person who used to push back in design reviews and now agrees with everything has disengaged, and it is counter-intuitive because it looks like maturity and it is more comfortable for the lead. Other behavioural signals: no more opinions about next quarter, declining the optional things they used to do like interviews and onboarding, initiative gone while output stays fine. Weak signals include LinkedIn activity and complaining, and complaining is genuinely inverted: someone who complains is still invested, and the ones who stop are the ones to worry about.

"What do you do when you see the signal?"

Not "are you thinking of leaving," which is unanswerable honestly and forces a premature disclosure. Name the specific change with the impact and ask an open question: "you used to be the person who found the hole in a design and you haven't in a couple of months; that was useful to me and I've missed it, what changed?" In one case the answer was that a proposal had been declined eight months earlier without a satisfying reason, and they had concluded proposing things was not worth it. The decision to leave was about 70 percent made, and the fix was revisiting the proposal properly and giving them the two-thirds that was still viable.

"Why is a proactive market adjustment the right move?"

Because replacement costs commonly run from six months to over a year of salary all in, so a 14 percent adjustment is a fraction of the alternative, and because the people most underpaid are often the least likely to raise it. In one case an engineer was 18 percent below market for their specialisation and had never mentioned it because "it felt like a bad look." Their reaction to the adjustment was relief followed by "I didn't know that was something I could ask for." The lead's job is to do the market check annually per person and make the arithmetic visible before the resignation, even where they do not control the outcome.

"Should you counter-offer?"

Usually not. By the time there is an offer, the decision formed months earlier and the offer is the conclusion; a counter fixes the most nameable reason, usually money, which is often not the actual one; accepted counter-offers show consistently high subsequent turnover; and it teaches the team that resigning is the raise mechanism. The real exceptions are a genuine and sole compensation gap you can fix permanently rather than as a retention bonus, and a specific timeline where you need a bridge and say honestly that it is one. Either way the resignation is a failure of the previous three months, and the retrospective is on yourself.

"What is a stay conversation and how do you frame it?"

A twice-yearly conversation explicitly framed as neither a performance review nor a career plan: what would make you stay another two years, and what would make you leave, and you do not have to answer the second. The most informative question is hypothetical, "what would another company have to offer for you to take the call seriously," because it is safe to answer honestly. The most useful is "is there anything you want that you haven't asked for because you assumed the answer was no," which surfaces the flexibility and scope requests people have silently written off, and those are often the ones that cost nothing.

Common misconceptions

"Everyone is motivated by growth and interesting work." That is one of six motivators, and it is frequently the lead's own, projected onto the team.

"A complaining engineer is a flight risk." Complaining is investment. The one who stopped complaining and stopped arguing is the one to worry about.

"Ask them if they are happy." It is unanswerable honestly. Name a specific behavioural change and ask what happened.

"If they wanted more money they would ask." The most underpaid people are frequently the least likely to ask, and the lead's annual market check is the mechanism that does not depend on them asking.

"A counter-offer buys you time." Sometimes, and it usually fixes the most nameable reason rather than the real one, with high subsequent turnover and a lesson for the rest of the team.

"Zero attrition is the goal." Zero regretted attrition is. A team with no turnover for years often contains people who stopped growing and stayed.

Interview delivery note

Say this verbatim: "Most regretted attrition is visible three months out, and the earliest signal is that they stopped arguing. Someone who used to find the hole in a design and now agrees with everything has disengaged, not matured, and it is easy to miss because the quieter version is more comfortable for the lead." It is specific, counter-intuitive, and it is the observation that separates a lead who watches people from one who watches tickets.

The senior-versus-staff separator is doing the market check before anyone asks. A senior lead responds to a resignation. A staff lead runs an annual per-person market comparison, finds someone 18 percent below market for their specialisation, builds the case with three comparable data points, and takes it to their director as a retention risk with a number attached before an offer exists. The arithmetic, an adjustment costing a fraction of a replacement, is available to anyone; making it visible in the right week is the leadership.

The second signal is assuming your model of each person is wrong until checked. Saying "I wrote down what I thought motivated each of five people and I was wrong about four, and each wrong model had produced a specific management error, giving the bored engineer more of the work they were bored by and reading a flexibility constraint as low ambition" demonstrates that you treat your own read as a hypothesis.

Further reading

• Google's re:Work summary of Project Oxygen, for manager behaviours associated with retention and development.
• Deci and Ryan's self-determination theory, and Daniel Pink's Drive, for the research basis behind individually varied intrinsic motivation.
• HR literature on stay interviews, for the practice of collecting exit-interview information while it can still be used.
• The growing people page, for the assignment mechanics that address the scope and learning motivators.
• The inheriting a team with low morale page, for the situation where several of these signals are already present.

Hiring: scorecard first, and defending the bar

What it is

Hiring as a lead's discipline has three parts, and the first one determines the other two:

1. WRITE THE SCORECARD BEFORE THE LOOP.
   What this role must be able to do, which signals prove it,
   and which interview produces each signal. Written down before
   anyone is interviewed.

2. INTERVIEW TO IT, CONSISTENTLY.
   Same questions, same rubric, same evidence standard across
   candidates. Otherwise you are measuring rapport and calling
   it judgment.

3. DEFEND THE BAR, WHICH MEANS SAYING NO TO A "FINE" CANDIDATE
   AND ARTICULATING WHY.
   A hire you are unsure about is a no. Bar defense is a lead
   responsibility, and it is unpopular exactly when it matters
   most.

And a fourth that is usually treated as someone else's job and is not: onboarding. A named buddy, a shipped change in week one, and a 30/60/90 with explicit success criteria.

What this is confused with: hiring as filtering. A filter asks who to eliminate. A scorecard asks what evidence would convince you, which is a different question and produces different interviews: an interviewer with a filter looks for reasons to reject, and an interviewer with a scorecard looks for specific signals and notices when they are absent.

Also confused: a high bar and a slow process. They are independent, and the two failures are symmetric: hiring someone you were unsure about, and losing a strong candidate to a three-week gap between rounds.

The problem it solves

Without a scorecard written first, the loop measures rapport.

Five interviewers, no shared scorecard. The debrief:

  "Strong. Really enjoyed talking to them."
  "Solid. Nothing concerning."
  "I liked them. Good culture fit."
  "Fine on the coding, bit quiet."
  "I'd hire them."

Four hires, one weak yes, zero evidence, and one phrase
("culture fit") that in practice usually means similarity to
the interviewer.

Six months later the same team cannot say why the hire is
struggling, because nobody ever wrote down what the role
required.

And the asymmetry that makes bar defense hard is real, not imagined:

The cost of a wrong yes:
  - the person struggles, which is bad for them
  - the team absorbs the gap, usually the strongest people
  - 6 to 12 months to a performance process, which consumes an
    enormous amount of a lead's time
  - the team's own bar quietly resets, because the standard is
    now visible

The cost of a wrong no:
  - you interview more candidates

These are not comparable, and every process pressure pushes the
other way: the requisition is open, the team is stretched, the
recruiter has a metric, and you have just spent six hours on
someone who is "fine".

Mechanics

The scorecard, written first

For a senior backend engineer on a payments team:

  MUST HAVE                       Signal from        Bar
  --------------------------------------------------------------
  designs a system with           system design      can name
  explicit failure modes                             failure modes
                                                     unprompted and
                                                     say what
                                                     happens in each

  writes correct code under       coding             works, handles
  ambiguity, and asks about                          the edge case
  the ambiguity                                      they identified

  debugs production, reasons      debugging /        forms a
  from evidence                   incident round     hypothesis and
                                                     says what would
                                                     disprove it

  operates in a domain with       domain deep-dive   asks about
  correctness constraints                            idempotency,
  (money)                                            reconciliation
                                                     or audit
                                                     without prompting

  disagrees productively          behavioural        a real example
                                                     where they
                                                     changed their
                                                     position

  NICE TO HAVE
  payments domain experience
  Kotlin specifically (we can teach this)

  NOT REQUIRED, and say so explicitly so nobody screens on it
  a degree
  experience at a company of our size
  familiarity with our exact stack

Two properties do the work:

EACH SIGNAL IS OWNED BY EXACTLY ONE INTERVIEW. Otherwise three
people assess the same thing and nobody assesses the fourth,
which is the most common loop design failure. Assign it in
writing, in the loop invite.

THE BAR IS WRITTEN AS OBSERVABLE EVIDENCE, not as a level. "Can
name failure modes unprompted" is checkable. "Strong system
design" is a feeling.

The "not required" list is worth writing explicitly, because unwritten preferences operate anyway, and a screening step that quietly filters on a stack or a company tier is where most of a pipeline's diversity disappears before anyone is interviewed.

Structure, and why it beats rapport

SAME QUESTIONS across candidates for a given role, so you have a
  comparison rather than five separate impressions.
A RUBRIC PER QUESTION with what a weak, adequate and strong
  answer contains, written in advance.
EVIDENCE IN THE WRITE-UP: what the candidate said, not how you
  felt. "Asked what happens if the callback is delivered twice,
  then designed for it" is evidence. "Great instincts" is not.
INDEPENDENT WRITE-UPS BEFORE THE DEBRIEF, submitted, so nobody
  anchors on the loudest voice. This is the single cheapest
  quality improvement in a hiring loop.
WRITTEN FEEDBACK WITHIN 24 HOURS, because memory degrades fast
  and a write-up produced three days later is a reconstruction.

The research finding behind all of this is consistent: unstructured interviews are weak predictors of job performance and strongly reflect interviewer similarity, and structure is what converts an interview from a social interaction into a measurement.

Defending the bar

THE RULE: a "fine" candidate is a no. If you are talking
yourself into it, that is the answer.

THE ARTICULATION, which is the part that makes it defensible:
  not "I just didn't feel it"
  but "the scorecard says they must be able to reason from
       evidence in a production debugging scenario. In the
       debugging round they guessed three times without checking
       anything, and when I asked what would disprove their
       hypothesis they didn't have an answer. That is the
       signal we said we needed and it was absent."

That is arguable, checkable and specific, and it is what makes
a no survive pressure from a recruiter with a metric and a hiring
manager with an open requisition.

The pressures are predictable, so prepare the responses:

"We've been looking for four months."
  -> "And a wrong hire costs us a year. What changed about the
      role that would make this candidate right?"

"They're better than nobody."
  -> Not true. The team absorbs the gap, usually the strongest
     people, and the standard resets visibly.

"We can coach them up."
  -> Sometimes, and only for teachable things you have named in
     advance and have capacity to teach. "We can teach Kotlin"
     is credible; "we can teach them to reason from evidence"
     usually is not.

"The other four said yes."
  -> Then say your specific evidence and let the room weigh it.
     A no with evidence is a contribution; a no without it is
     an obstruction, which is why the articulation matters.

And the inverse discipline, which is less discussed: do not block on a preference. A no that is really "they did not solve it the way I would have" is the same failure in the other direction, and it is why the scorecard is written before you meet anyone.

Calibrating interviewers

NEW INTERVIEWERS shadow twice, then are shadowed twice, before
  running a round alone.
DISAGREEMENT IS THE TRAINING SIGNAL. When two interviewers reach
  opposite conclusions from the same round, that conversation is
  worth more than any training material.
TRACK OUTCOMES where you can: which interviewers' strong-hire
  signals correlate with people who do well at 12 months. Small
  samples, so treat it as a conversation starter rather than a
  score.
ROTATE, so that the loop is not four people who think alike, and
  so the load does not concentrate on the same three seniors.

Onboarding, which is part of hiring

A NAMED BUDDY. One person, named before day one, whose explicit
  job is to be interruptible for six weeks. Not the lead.

A SHIPPED CHANGE IN WEEK ONE. Small, real, in production.
  It proves the pipeline works for them, it forces every access
  and tooling problem to surface immediately, and it is the
  single strongest early signal to the new person that they are
  going to be effective here.
  Keep a standing list of small, safe, genuinely useful changes
  for exactly this.

A 30/60/90 WITH EXPLICIT SUCCESS CRITERIA, written and shared:
  30  environment working, shipped 2-3 small changes, met the
      people they will work with, can describe what the team
      owns
  60  owns a small feature end to end, on-call shadow completed,
      contributing in design reviews
  90  fully in the rotation, owns a meaningful piece of work,
      has raised at least one thing they think we do badly

The last one at 90 days is deliberate: a new person's outside
view has a short shelf life, and asking for it explicitly is the
only way most people will offer it.

Onboarding failures show up as hiring failures, and the distinction matters because the fix is different. A person who is struggling at four months when nobody named a buddy, they shipped nothing for three weeks, and no success criteria existed, is not a hiring mistake yet.

A worked example: a loop that was measuring rapport

A team hiring two senior engineers. Twelve months of history: 34 onsite loops, 6 offers, 5 hires, of whom 2 were struggling at the twelve-month mark and one had left.

The audit of the existing loop:

No scorecard existed. The loop was:
  - two coding rounds (different interviewers, same kind of
    problem)
  - one system design
  - one "culture / values"
  - hiring manager conversation

Signal coverage, reconstructed from write-ups:
  coding                  covered 3 times (both coding rounds
                          and half the design round)
  system design           covered once, inconsistently
  debugging / production  NEVER ASSESSED
  domain correctness      NEVER ASSESSED
  disagreement            assessed by 3 different people with
                          3 different standards

Write-up quality:
  contained specific evidence          31%
  contained only impressions           69%
  submitted before the debrief         22%

Of the 34 loops, the correlation between "which interviewer
liked them most" and the eventual decision was the strongest
pattern in the data.

Debugging and production reasoning were never assessed, and both struggling hires were struggling on exactly that, which is not a coincidence but a direct consequence: the loop could not have detected it.

The rebuild:

1. SCORECARD, written by the lead with two senior engineers, in
   90 minutes. Five must-haves, each owned by exactly one round.

2. LOOP REDESIGNED to match:
     coding              (1 round, was 2)
     system design       (1)
     production debugging (1, NEW: a real incident from our own
                          history, with the logs and dashboards)
     domain deep-dive     (1, folded into the hiring manager
                          conversation)
     behavioural, structured on disagreement and ownership (1)

3. RUBRICS per question, one page each, with weak/adequate/strong
   descriptions written before the first candidate.

4. INDEPENDENT WRITE-UPS submitted before the debrief, enforced
   by the scheduling tool. This one change took write-ups
   containing specific evidence from 31% to 88%, because a
   write-up you cannot revise after hearing others' opinions has
   to stand on its own.

5. 24-HOUR FEEDBACK SLA, tracked.

The independent-write-up change was free and produced the largest single improvement in evidence quality, which is consistent with the anchoring research and was the easiest thing to sell internally because it removed no one's autonomy.

The bar defense, tested twice in the first quarter:

CANDIDATE 1: four yeses, one no (the debugging round).
  The no, articulated: "the scorecard says reasons from evidence
  in production. Given real logs, they proposed three causes in
  four minutes without looking at anything, and when I asked
  what would rule out the first one they said 'we'd have to try
  it'. That is the signal we said we needed."

  The recruiter noted the requisition had been open five months.
  The hiring manager asked whether it was coachable. The
  articulation was specific enough that the answer was "not in
  the timeframe we'd need", and it was a no.

CANDIDATE 2: three yeses, one no, one weak yes.
  The no was "they didn't solve the design the way I would
  have", which under questioning did not map to any scorecard
  line. That no was overridden, correctly, and the interviewer
  was re-calibrated.

Both outcomes are the process working, and the second is the
one people forget: the bar is defended against soft yeses AND
against preference-based nos.

Results over the following twelve months:

                              before      after
onsite loops                     34          29
offers                            6           7
hires                             5           6
struggling at 12 months           2           0
regretted attrition               1           0
write-ups with specific
  evidence                       31%         88%
write-ups before debrief         22%        100%
median time from onsite to
  decision                     6 days      1.5 days
candidate-declined offers         1           0

Offer rate went up while the bar went up, which surprised the team and has a straightforward explanation: a structured loop with a 24-hour feedback SLA and a 1.5-day decision is a better candidate experience, and the one previously declined offer had cited the slow process.

Onboarding, changed at the same time:

Before: no buddy, first commit at a median of 19 days, no
  written success criteria. Two of the five previous hires had
  said in retrospect that they "didn't feel useful for two
  months".

After: named buddy before day one, a standing list of small
  safe changes, a written 30/60/90.
  median days to first production change: 19 -> 3
  the 90-day "what do we do badly" question produced, from the
  first three hires: an undocumented deploy step, a misleading
  runbook, and an onboarding doc that had been wrong for a year.

All three were fixed, which is a return on a question that
costs nothing.

Asking a new hire at 90 days what the team does badly is the cheapest audit available, and the answers expire: within six months they will have normalised everything they noticed.

Production evidence

Structured interviewing's predictive advantage over unstructured interviewing is one of the most consistently replicated findings in industrial and organisational psychology (the Schmidt and Hunter meta-analyses being the widely cited synthesis), and it is the empirical basis for same-questions, same-rubric, evidence-in-the-write-up.

Google's re:Work materials document their move to structured interviewing with defined rubrics and independent written feedback before the debrief, along with their published finding that unstructured interviews correlate weakly with performance while adding a strong similarity bias.

Amazon's Bar Raiser program is the clearest institutionalised form of bar defense: a trained interviewer outside the hiring team, empowered to block, existing precisely because a hiring manager under pressure will lower the bar. The asymmetry it encodes, that a wrong yes is more costly and less reversible than a wrong no, is the argument this page makes.

The scorecard-first practice is codified in Geoff Smart and Randy Street's Who as the "scorecard" step, with the same rationale: define the outcomes and competencies before meeting anyone, or you will evaluate against an impression formed in the first minutes.

Anchoring effects in group evaluation are well documented, and the practical countermeasure, collecting independent judgments before discussion, is standard in structured hiring at Google, Amazon and others.

Onboarding research consistently associates early role clarity and early meaningful contribution with time-to-productivity and first-year retention, which is the basis for the shipped-change-in-week-one practice.

The debate

Is a high bar worth a longer search? Yes, and the arithmetic is not close: a wrong hire costs six to twelve months of a lead's attention plus the team absorbing the gap, and a wrong no costs more interviews. The legitimate counter-argument is that an unfilled role also has a cost, and the honest resolution is to fix the pipeline rather than to lower the bar, because lowering it is irreversible in a way that a slower search is not.

Does "culture fit" have any legitimate use? As commonly used, no: in practice it means similarity to the interviewer and it is where bias enters an otherwise structured loop. The legitimate version is values alignment against written, behaviourally defined values ("gives and receives direct feedback", "makes decisions with incomplete information"), assessed with structured questions. If you cannot say which written value the concern maps to, it is not a values concern.

Should the hiring manager be in the loop? Yes, and they should not be the only strong voice. Amazon's Bar Raiser exists precisely because the hiring manager has an interest in filling the requisition, and the structural answer is someone in the room whose incentive is the bar rather than the role.

Is a take-home better than a live coding round? It measures something closer to the job and it excludes people with caregiving responsibilities and second jobs unless it is genuinely time-boxed and respected. The position: offer a choice where you can, cap the take-home at about two hours, and never let a "two-hour" take-home be one where the best candidates spend eight.

Should you hire for potential? For junior roles, largely yes. For senior and staff roles, potential is not the bar; demonstrated scope is, and hiring someone into a level they have not operated at is setting them up in front of an audience. The honest version is to hire them at the level they have demonstrated and say what would move them.

Is fast feedback worth the process cost? Yes, and it is close to free. A 24-hour written feedback SLA improves evidence quality because memory degrades, and a decision within two days of the onsite measurably improves offer acceptance, which the worked example saw directly.

Follow-up Q&A

"Why write the scorecard before the loop?"

Because otherwise the loop measures rapport and calls it judgment. A scorecard names what the role must be able to do, which observable signal proves each capability, and which single interview owns each signal. In one audit the loop assessed coding three times, system design once and inconsistently, and production debugging never, and both hires struggling at twelve months were struggling on production debugging. That is not bad luck; the loop was structurally incapable of detecting it. Writing the "not required" list explicitly matters too, because unwritten preferences operate anyway and a screen that quietly filters on a stack or a company tier removes people before anyone is interviewed.

"What makes a no defensible?"

Specific absent evidence tied to a named scorecard line. Not "I didn't feel it" but "the scorecard says they must reason from evidence in a production scenario; given real logs they proposed three causes in four minutes without checking anything, and when asked what would rule out the first they said we would have to try it." That is checkable and arguable, and it survives a recruiter with a metric and a five-month-old requisition. The inverse discipline matters equally: a no that is really "they did not solve it the way I would have" maps to no scorecard line and should be overridden.

"What is the single cheapest improvement to a hiring loop?"

Independent written feedback submitted before the debrief. It costs nothing, removes nobody's autonomy, and it stops the loudest voice from anchoring the room. In one case it took the share of write-ups containing specific evidence from 31 percent to 88 percent, because a write-up you cannot revise after hearing others' opinions has to stand on its own. Pair it with a 24-hour feedback deadline, since a write-up produced three days later is a reconstruction rather than a record.

"How do you handle the pressure to lower the bar?"

Prepare the responses, because the pressures are predictable. To "we've been looking four months": a wrong hire costs us a year, and what changed about the role that would make this candidate right. To "they're better than nobody": not true, because the team absorbs the gap, usually the strongest people, and the standard resets visibly. To "we can coach them up": credible only for things you named as teachable in advance and have capacity to teach, so "we can teach Kotlin" is fine and "we can teach them to reason from evidence" usually is not. The asymmetry is the whole argument: a wrong yes costs six to twelve months and a wrong no costs more interviews.

"What does good onboarding look like, and why is it a hiring topic?"

A named buddy before day one whose explicit job is to be interruptible for six weeks, a shipped production change in week one, and a written 30/60/90 with success criteria. It is a hiring topic because onboarding failures present as hiring failures, and the fix is different: someone struggling at four months who had no buddy, shipped nothing for three weeks and had no written criteria is not a hiring mistake yet. Keep a standing list of small safe changes so the week-one ship is always possible, because it forces every access and tooling problem to surface immediately.

"What is the most under-used thing in onboarding?"

Asking at 90 days what the team does badly, as an explicit written expectation rather than an offhand question. A new person's outside view has a short shelf life; within six months they will have normalised everything they noticed. From the first three hires in one team it produced an undocumented deploy step, a misleading runbook, and an onboarding document that had been wrong for a year, all of which were fixed. It is the cheapest audit available and it also tells the new person their perspective is wanted.

Common misconceptions

"You know a good candidate when you see one." Unstructured interviews are weak predictors of performance and strongly reflect similarity to the interviewer, which is what "I just liked them" usually measures.

"A high bar means a slow process." They are independent. In one rebuild the bar rose, evidence quality rose, and time from onsite to decision went from six days to a day and a half, which improved offer acceptance.

"Better than nobody." The team absorbs the gap, usually the strongest people, and the visible standard resets. The comparison is not to an empty seat, it is to the next candidate plus the cost of being wrong.

"Culture fit is a real signal." As commonly used it means similarity to the interviewer. The legitimate version is written, behaviourally defined values, and if a concern maps to none of them it is not a values concern.

"The hiring manager should decide." They have an interest in filling the requisition, which is exactly why a bar-raising voice with a different incentive exists in mature processes.

"Hire for potential." For junior roles, largely. At senior and staff, potential is not the bar and hiring someone into a level they have not operated at sets them up to struggle publicly.

Interview delivery note

Say this verbatim: "I write the scorecard before the loop: what the role must be able to do, which observable signal proves it, and which single round owns that signal. Otherwise you assess coding three times, never assess production debugging, and then cannot explain why the hire is struggling on production debugging a year later." It names the practice and the exact failure it prevents, with a consequence that is concrete.

The senior-versus-staff separator is articulating a no in scorecard terms under pressure. A senior engineer says a candidate did not feel right. A staff engineer says which named signal was required, what the candidate actually did and said that showed its absence, and whether it is teachable in the time available, which is what makes a no survive a recruiter with a metric and a five-month-old requisition. And the same person overrides a no that turns out to be "they did not solve it the way I would have," because the discipline runs in both directions.

The second signal is treating onboarding as part of hiring. Naming a buddy before day one, keeping a standing list of small safe changes so a new hire ships to production in week one, and writing a 30/60/90 with success criteria is what makes "this hire is struggling" a diagnosable statement rather than a conclusion about the person.

Further reading

• Google's re:Work guides on structured interviewing, rubrics and independent written feedback.
• Amazon's published description of the Bar Raiser role, for institutionalised bar defense and the wrong-yes asymmetry.
• Geoff Smart and Randy Street, Who, for the scorecard-first method.
• Schmidt and Hunter's meta-analytic work on selection methods, for the predictive validity of structured versus unstructured interviews.
• The promotions and the calibration room page, for the same evidence-versus-adjectives discipline applied internally.

Written-first culture, ADRs, and managing up

What it is

A written-first culture is one where decisions, designs and status exist as durable documents by default, and meetings are for the things a document cannot do. Three instruments and one habit:

DESIGN DOCS / RFCs   the proposal, circulated for comment before
                     the work starts

ADRs                 architecture decision records: short,
                     immutable, one per decision, capturing
                     context, the decision, and the consequences

MEETING AUDIT        no agenda, no meeting. No decision, shorter
                     meeting. Status meetings become async
                     updates.

MANAGING UP          a monthly one-pager to your director:
                     progress, risks named early, and asks.

The unifying claim: decisions that are not written down get relitigated, and every relitigation costs the same argument again with worse memory and different people.

What this is confused with: documentation. Documentation describes how a system works now. A written-first culture is about capturing why a decision was made, at the moment it was made, which is the information that decays fastest and is impossible to reconstruct later.

Also confused: written-first and asynchronous-only. The point is not to eliminate conversation, it is that the conversation should start from a document and end in one. A design review with no pre-read is a meeting where six people hear an idea for the first time and are asked to evaluate it.

The problem it solves

Undocumented decisions are re-made, and each re-making is more expensive than the first.

March      the team decides to use Postgres rather than DynamoDB
           for the ledger, because of the multi-row transaction
           requirement. Discussed in a meeting. Nothing written.

August     a new senior engineer proposes DynamoDB. Nobody can
           remember the full reasoning, only the conclusion.
           Two days of debate, the same conclusion, plus
           unnecessary friction.

November   an architecture review asks why the ledger is not on
           DynamoDB like everything else. The two people who
           were in the March meeting have left.
           Three days of investigation to reconstruct an
           argument that took forty minutes originally.

A ten-line ADR written in March would have cost fifteen minutes.

And the meeting failure, which is the same problem in the time domain:

A weekly one-hour status meeting, 9 people:
  9 person-hours per week = ~1.1 person-days
  x 46 weeks = ~52 person-days a year

For information that is (a) already in the tracker, (b) relevant
to at most two people at a time, and (c) delivered in a format
nobody can search.

The same content as a written async update takes about 5 minutes
each to write and 3 minutes to read: ~1.2 person-hours a week,
and it is searchable.

And the managing-up failure, which is the most consequential for the lead personally:

A director with eight teams reporting through them hears from
your team when:
  - something goes wrong
  - a deadline is missed
  - someone escalates about you

They have no independent view of your team's progress, risks, or
judgment, so their model of you is built entirely from
exceptions, and every exception is negative by construction.

The lead who sends a monthly one-pager has a director whose model
is built from the lead's own framing, updated before the news.

Mechanics

Design docs and RFCs

WHEN: before non-trivial work starts. The test is whether
someone could reasonably have done it a different way. If yes,
write the doc.

STRUCTURE that survives:
  1. The problem, in user or business terms, with a number if
     one exists
  2. Constraints, including the non-obvious ones (compliance,
     an existing contract, a team's capacity)
  3. Options considered, at least two, with the cost of each
  4. The recommendation, and the condition that decides it
  5. What we are NOT doing, and why
  6. Risks and how we would know if we were wrong
  7. A rollout and rollback plan

REVIEW: circulated with a deadline for comments, then a meeting
ONLY if there is unresolved disagreement. Most docs do not need
a meeting, and the ones that do have a much better meeting
because everyone has read it.

Section 5, what we are not doing, is the one that prevents the most future argument, because the question that comes back in six months is almost always "why didn't you just...".

Architecture Decision Records

ADRs are deliberately smaller than design docs, and the constraints are what make them survive.

ONE DECISION PER RECORD.
NUMBERED AND IMMUTABLE. You do not edit an ADR to change the
  decision; you write a new one that supersedes it, and mark the
  old one superseded. The history is the value.
SHORT. Half a page to two pages. An ADR that takes an hour to
  write does not get written.
IN THE REPO, next to the code, so it is found by the person
  reading the code.

# ADR-014: Ledger stored in Postgres, not DynamoDB

Status: Accepted (2024-03-11). Supersedes none.

## Context
The ledger must record double-entry postings. A single business
event produces 2 to 8 rows that must all commit or none. Our
default datastore for new services is DynamoDB.

DynamoDB transactions are limited to 100 items and cannot span
tables, and our reconciliation query pattern is a range scan by
(account, time) with aggregate sums, which requires either a
secondary index per query shape or a separate analytics path.

Expected volume: ~40M postings/year, ~14 GB/year including
indexes. This is small.

## Decision
Store the ledger in Postgres, with postings in a single table
partitioned by month.

## Consequences
+ multi-row atomicity is a native transaction
+ reconciliation is SQL, so finance can be given read access
+ the volume is comfortably within a single instance for years
- diverges from the org default, so the on-call rotation needs
  Postgres competence (see ADR-016)
- we own vacuum and partition maintenance
- if volume grows 100x this decision should be revisited; the
  trigger is >500M postings/year

## Alternatives considered
DynamoDB with a transactional write of up to 8 items and a
separate analytics export: rejected because reconciliation
becomes a second system and finance cannot self-serve.

The "consequences" section including the negatives is what makes an ADR trustworthy, and the revisit trigger with a number is what makes it useful later: the November architecture review reads "revisit above 500M postings a year" and checks the current number instead of reopening the argument.

What deserves an ADR:

YES: choice of datastore, a language or framework introduction,
     an API style, an auth model, a consistency model, a
     significant deviation from an org standard, a decision to
     accept known debt
NO:  which library for date formatting, naming conventions,
     anything a linter can enforce, anything reversible in an
     afternoon

The meeting audit

NO AGENDA, NO MEETING. Circulated in advance, with the DECISION
  the meeting exists to make. "Discuss X" is not a decision.

NO DECISION, SHORTER MEETING. If a meeting has no decision to
  make, it is an update, and updates are written.

STATUS MEETINGS BECOME ASYNC UPDATES. Written by each person,
  read by whoever needs it, searchable afterwards.

A PRE-READ, AND SILENT READING TIME. The Amazon-style practice
  of opening a meeting with 10 to 20 minutes of silent reading
  works because it removes the "did everyone read it" problem
  entirely rather than hoping.

EVERY RECURRING MEETING GETS AN EXPIRY DATE. Meetings are
  created for a reason and outlive it. A quarterly review where
  each recurring meeting must be re-justified removes several
  every time.

DECISIONS AND ACTIONS WRITTEN DOWN, IN THE MEETING, WITH OWNERS.
  A decision that exists only in six people's memory will be
  remembered six different ways.

The single highest-return audit action is deleting or async-ing one recurring status meeting, and the arithmetic (9 people, one hour, 46 weeks, 52 person-days a year) is usually enough to carry it.

Managing up: the monthly one-pager

One page, monthly, to your director. Same structure every time
so it can be skimmed.

  WHAT SHIPPED           3 to 5 bullets, with the outcome, not
                         the activity. "Refunds latency p99 from
                         2.1s to 340ms" not "worked on refunds".

  WHAT'S NEXT            the next month, briefly.

  RISKS                  named early, with your assessment and
                         what you are doing. THIS IS THE MOST
                         VALUABLE SECTION and the one people
                         omit.
                         "The identity dependency is unscheduled.
                          If it is not scheduled by the 7th we
                          build a two-day workaround. I do not
                          need help yet; I will tell you if that
                          changes."

  ASKS                   specific, with what happens if the
                         answer is no. "I need a decision on the
                         Q3 headcount split by the 20th; without
                         it I will plan for the lower number."

  PEOPLE                 one or two lines: someone doing
                         well and worth remembering at
                         calibration, or a risk.

Three properties make it work:

1. RISKS BEFORE THEY ARE NEWS. A director's worst experience is
   learning about a problem from someone else's escalation. A
   lead who names risks a month early is the lead they trust,
   and this is almost entirely a function of habit rather than
   judgment.

2. ASKS WITH A DEFAULT. "I need X by the 20th; absent an answer
   I will do Y" is answerable. An open question is deferrable.
   Same mechanism as unsticking a decision.

3. OUTCOMES, NOT ACTIVITY. A director cannot evaluate "worked on
   refunds". They can repeat "refunds p99 went from 2.1s to
   340ms" upward, and being repeatable upward is what makes a
   one-pager travel.

The people section is the under-used one, because calibration rooms are months away and a director who has seen a name in three consecutive one-pagers alongside a specific artifact arrives with a prior.

Incident communications

FIXED CADENCE. Every 30 minutes during a Sev1, even if the
  update is "no change, still investigating, next update at
  14:30". A predictable cadence stops people asking, which is
  itself a load on the responders.

AUDIENCE-APPROPRIATE DETAIL.
  status page / customers: impact, scope, what to do, next
    update time. No internals.
  internal broad: impact, what is known, what is being tried,
    who is commanding, next update.
  responders: everything.

NO SPECULATION. "We believe it may be the database" becomes
  "the database is down" in the third retelling, and it will
  reach a customer.

BLAMELESS POSTMORTEM with action items that have OWNERS AND
  DATES. An action item without both is a wish, and the
  measurable form of postmortem quality is the completion rate
  of its actions.

A worked example: a lead who was invisible until something broke

A lead of nine, eighteen months in post, strong delivery, and a performance conversation in which their director described them as "hard to read" and said they had "limited visibility into what the team is doing." The lead's own view was that they were shipping and not complaining, which they had assumed was the ideal.

The audit:

DECISIONS
  Design docs written in 18 months: 2
  ADRs: 0
  Decisions re-litigated in the previous quarter, counted from
  meeting notes and threads: 6, consuming an estimated 9
  engineer-days

MEETINGS
  Recurring team meetings: 5, totalling 4.5 hours per person
  per week
  Of those, meetings with a written agenda: 1
  Meetings whose purpose was a decision: 1
  Weekly status meeting: 9 people x 1 hour = 52 person-days a
  year

UPWARD COMMUNICATION
  Written updates to the director in 18 months: 0
  Times the director learned of a team problem from someone
  else first: 4

"Four times the director learned about my team's problem from someone else" is the finding, and it fully explains the "hard to read" feedback without needing any other explanation.

The changes:

1. ADRs, introduced with a template and a rule: any decision
   someone could reasonably have made differently gets one, half
   a page, in the repo.

   First quarter: 11 ADRs written, median length 340 words,
   median time to write 18 minutes.

   The team back-filled 4 for decisions already made, which took
   longer (the reasoning had to be reconstructed) and was worth
   it: the ledger/Postgres decision was one of them, and it was
   questioned two months later by an architecture review and
   answered by linking the ADR.

   Decisions re-litigated the following quarter: 1.

2. MEETING AUDIT.
     - the weekly status meeting was replaced with a written
       async update, 5 minutes to write, posted by Tuesday noon
       -> recovered ~48 person-days a year
     - two recurring meetings were found to have outlived their
       reason and were deleted
     - the remaining three got written agendas with a named
       decision, and a rule that no agenda by the evening before
       cancels the meeting
     -> recurring meeting time per person: 4.5 h/week -> 1.5

     The cancellation rule was invoked 3 times in the first
     month and 0 times after that, which is how a forcing
     function is supposed to work.

3. THE MONTHLY ONE-PAGER, started immediately.

   Month 1 was awkward: the lead had to reconstruct what had
   shipped, and found they could not express two months of work
   as an outcome, which was itself a useful finding.

   Month 3's risks section named an upcoming dependency
   problem. The director, having been told a month early, moved
   it in a planning conversation the lead was not in. The lead's
   note: "the risk section did work I could not have done
   myself."

   Month 5: the director forwarded the one-pager to their own
   VP, unedited. That is the outcome the format is designed for
   and the lead had not anticipated it.

"The director forwarded it unedited" is the test of whether a one-pager is written in outcomes, and it is the mechanism by which a lead's work travels two levels up without them being in the room.

Twelve months later:

                                  before      after
design docs / ADRs                  2 / 0      6 / 31
decisions re-litigated per
  quarter                             6          0-1
recurring meeting hours per
  person per week                    4.5        1.5
written updates to director           0         12
director learning of a problem
  from someone else first             4          0

And the performance conversation the following year described the lead as "the person whose risks I hear about first," which is a sentence that came directly from the risks section of a monthly document, and cost roughly 30 minutes a month.

Two things that did not work, recorded honestly:

1. An attempt to require a design doc for everything produced
   four documents in a month, three of which were for work
   nobody would have done differently, and the practice was
   quietly abandoned by the team within six weeks.
   Replaced with the test: could someone reasonably have done
   this a different way? That test produced 6 docs in a year,
   all of which were read.

2. A shared "decision log" spreadsheet, separate from the repo,
   which nobody updated after the second week. ADRs in the repo
   next to the code worked because they were where the reader
   already was.
   The general lesson: a written artifact that lives away from
   the work does not survive.

Production evidence

Architecture Decision Records were introduced by Michael Nygard in "Documenting Architecture Decisions" (2011), with the specific design constraints described here: one decision per record, numbered, immutable, superseded rather than edited, and stored with the code. The practice appears in the ThoughtWorks Technology Radar and is widely adopted, with tooling (adr-tools) and template collections maintained publicly.

Amazon's six-page narrative memo practice, replacing slide presentations, and its accompanying silent reading period at the start of the meeting, is the best-documented instance of written-first decision-making at scale, and the silent-reading detail exists precisely because relying on pre-reading does not work.

Google's design document culture and its published engineering practices treat a design doc with named reviewers as the durable artifact of a decision, and the same artifact is what promotion packets cite as evidence.

Blameless postmortems with owned, dated action items are specified in Google's SRE Book, which also identifies action-item completion rate as the measurable indicator of whether a postmortem process is real.

Incident communication at a fixed cadence is standard in PagerDuty's and Atlassian's published incident-response documentation, with the stated rationale that a predictable next-update time reduces inbound interruptions to responders, which is a load-shedding argument rather than a courtesy one.

Research on distributed and asynchronous work consistently finds that written, searchable decision records disproportionately benefit people who were not in the room, which includes future hires, other time zones, and anyone who joins the team after the decision.

The debate

Does written-first slow things down? It front-loads the cost and removes a larger recurring one. A ten-line ADR costs fifteen minutes and prevents a two-day re-litigation eight months later, and the observed rate in one team was six re-litigations a quarter costing about nine engineer-days. The legitimate objection is that a heavy documentation requirement produces documents nobody reads, which is why the test is whether someone could reasonably have decided differently.

Should ADRs be editable? No, and this is the constraint people most often relax. An edited ADR loses the history, which is the entire value: the useful artifact is "we decided X in March for these reasons, and superseded it in November for these other reasons", and an edited record shows only the current state, which the code already shows.

Are status meetings ever justified? For a team in crisis, in the first weeks of a reorganisation, or where the point is the social contact rather than the information, yes and say so. For steady-state information transfer, no, and the arithmetic, 52 person-days a year for nine people, usually settles it without further argument.

Is a monthly one-pager self-promotional? It is the mechanism by which a director's model of you is built from your framing rather than from exceptions, and every exception is negative by construction. The counter-argument, that the work should speak for itself, describes a world where your director has time to observe your team, and they have eight. The version that becomes self-promotional is one written in activity rather than outcomes.

Should risks always be surfaced upward? Named, yes; escalated, not necessarily, and the distinction is worth making explicit in the document. "Here is a risk, here is what I am doing, I do not need help yet, I will tell you if that changes" gives the director information without transferring the problem, which is what makes them trust the next one.

Does silent reading time in meetings work? Yes, and the discomfort is the point. Relying on people to pre-read fails often enough that the meeting degrades into a presentation, and ten to twenty minutes of reading is cheaper than an hour of a badly informed discussion.

Follow-up Q&A

"Why write down decisions rather than just the design?"

Because the reasoning decays fastest and is impossible to reconstruct. Documentation says how a system works now, which the code also says. A decision record says why this option was chosen over the alternatives, under what constraints, and what would make it worth revisiting, and none of that is recoverable from the code. In one team, six decisions were re-litigated in a single quarter at a cost of about nine engineer-days, and in each case the conclusion was the same as the original: they were paying for the same argument twice with worse information.

"What makes an ADR different from a design doc?"

Scope and lifecycle. One decision, half a page to two pages, numbered, immutable, and stored in the repo next to the code. You never edit an ADR to change a decision; you write a new one that supersedes it and mark the old one superseded, because the history is the value. A design doc is the proposal for a body of work with options and a rollout plan; an ADR is the durable record of one choice within it. The consequences section must include the negatives, and a revisit trigger with a number ("revisit above 500M postings a year") is what lets a future reviewer check a fact instead of reopening the argument.

"What is the meeting audit?"

No agenda, no meeting, with the agenda naming the decision the meeting exists to make, since "discuss X" is not a decision. No decision, shorter meeting, because an update is written rather than performed. Status meetings become async written updates. Recurring meetings get an expiry date and are re-justified quarterly, because meetings outlive their reason. And decisions and actions are written down in the meeting with owners, because a decision held in six memories is remembered six ways. The highest-return single action is usually converting one recurring status meeting: nine people for an hour over 46 weeks is 52 person-days a year.

"What goes in a monthly one-pager to your director?"

What shipped, in outcomes rather than activity; what is next; risks named early with your assessment and what you are doing; asks with a default; and a line or two on people. The risks section is the most valuable and the most commonly omitted, because a director's worst experience is learning about a problem from someone else's escalation. Phrase risks so they inform without transferring: "the identity dependency is unscheduled; if it is not scheduled by the 7th we build a two-day workaround; I do not need help yet and I will tell you if that changes."

"How do you know a one-pager is written well?"

If your director forwards it unedited. That only happens when it is written in outcomes rather than activity, because "refunds p99 went from 2.1 seconds to 340 milliseconds" is repeatable upward and "worked on refunds" is not. It is also the mechanism by which a lead's work reaches two levels up without them being in the room, which is worth more than most things a lead can do with thirty minutes a month.

"What are the rules for incident communication?"

A fixed cadence, typically every 30 minutes during a Sev1, including updates that say nothing has changed and when the next one is, because a predictable next-update time stops people interrupting the responders. Audience-appropriate detail: impact and next update time for customers, more for the internal audience, everything for responders. No speculation, because "we believe it may be the database" becomes "the database is down" by the third retelling and will reach a customer. And a blameless postmortem whose action items have owners and dates, with completion rate as the measurable indicator of whether the process is real.

Common misconceptions

"Documentation is the same as decision records." Documentation describes the current state, which the code also does. A decision record captures the reasoning, which nothing else preserves.

"Update the ADR when the decision changes." Editing destroys the history, which is the value. Write a superseding record.

"Written-first means fewer conversations." It means conversations start from a document and end in one. A design review with no pre-read is six people evaluating an idea they are hearing for the first time.

"Good work speaks for itself." Your director has eight teams and hears about yours through exceptions, which are negative by construction.

"Surfacing a risk means asking for help." Naming a risk with your plan and an explicit "I do not need help yet" gives information without transferring the problem, and that is what makes the next one credible.

"Everyone will read the pre-read." They will not often enough that the meeting degrades. Silent reading time at the start is cheaper than an hour of badly informed discussion.

Interview delivery note

Say this verbatim: "Decisions that are not written down get relitigated, and the second argument is more expensive than the first because the people who had the context have left. A ten-line ADR costs fifteen minutes; we were re-litigating six decisions a quarter at about nine engineer-days." The claim plus the arithmetic that makes it an argument rather than a preference.

The senior-versus-staff separator is the risks section of an upward update. A senior lead reports progress. A staff lead names a risk a month before it becomes news, with their own assessment, what they are doing about it, and an explicit statement of whether they need help. That gives the director information without transferring the problem, and it is why they trust the next one. The observable outcome, "the person whose risks I hear about first", is a reputation built from thirty minutes a month of a fixed-format document.

The second signal is knowing why a decision record must be immutable. Saying "you never edit an ADR; you supersede it, because the useful artifact is that we decided X in March for these reasons and changed to Y in November for these others, and an edited record shows only the current state, which the code already shows" demonstrates you understand what the artifact is for rather than that you have seen a template.

Further reading

• Michael Nygard, "Documenting Architecture Decisions" (2011), for the original ADR format and its constraints.
• Amazon's narrative-memo practice and its silent reading period, as documented in Jeff Bezos's shareholder letters and subsequent accounts.
• Google's SRE Book on blameless postmortems, including action-item completion rate as the measure of whether the process is real.
• PagerDuty's and Atlassian's incident-response documentation on communication cadence and audience-appropriate detail.
• The unblocking page, for the decision-latency measurement that a written decision record makes possible.

Managing former peers, and glue work

What it is

Two problems that share a root: work and authority that exist but are not acknowledged.

Managing former peers is the transition from being one of the group to holding information and decisions the group does not have. The relationship does not survive by being left alone, because it has changed whether or not anyone says so.

What actually changed on day one:
  - you know things they do not (compensation, performance
    conversations, reorganisation plans, who is leaving)
  - your casual opinion is now a directive, whether you meant it
    that way or not
  - complaining to you is now a risk for them, so you stop
    hearing the complaints
  - your friendship has an asymmetry it did not have before

Glue work, in Tanya Reilly's framing, is the coordination, communication and maintenance work that makes a team function and that no promotion rubric rewards.

Examples: noticing the design gap between two teams, writing the
onboarding doc, running the incident retro, unblocking someone
by finding the right person, keeping the roadmap coherent,
answering the same question for the fifth time, updating the
runbook, chasing the dependency.

Properties: essential, invisible, uncredited, and it accretes on
whoever is most conscientious, which is not randomly
distributed.

What this is confused with: glue work and low-value work. It is high-value work with no attribution mechanism. The failure is not that people do it; it is that they do it instead of the work that gets them promoted, and nobody made that trade deliberately.

Also confused: managing former peers and being liked. A lead who optimises for the friendship being unchanged will avoid the conversations that make them a lead, and the team notices that faster than the lead does.

The problem it solves

The former-peer transition fails silently, in one of two directions.

DIRECTION 1: nothing is said, so nothing is renegotiated.
  Week 2  a former peer vents about another engineer, as they
          always did. The lead now cannot un-know it, and must
          either act on it or explicitly not act on it. Either
          way the friendship has been used as a channel.
  Week 6  the lead makes an offhand comment about an approach.
          The engineer treats it as a decision, because it is
          one now. The lead is surprised. The engineer is
          annoyed at being second-guessed later.
  Week 12 the lead gives the interesting migration work to
          their closest former peer, because they trust them.
          Two other people notice. Nobody says anything, and the
          lead's read is that everything is fine.

DIRECTION 2: overcorrection.
  The lead becomes distant and formal with everyone, treats
  their former closest colleague more harshly than others to
  prove impartiality, and loses the relationships that made
  them a credible lead in the first place.

The second failure is more common among conscientious people and is more damaging, because distance is read as a change in respect rather than a change in role.

And the glue work failure has a measurable shape:

A team of eight. One person, over a year:
  - wrote and maintained the onboarding doc
  - ran every incident retro
  - was the informal answer desk for the legacy system
  - noticed and fixed three cross-team design mismatches before
    they shipped
  - kept the roadmap page current

At promotion time their packet said: "highly trusted, the
person everyone goes to."

The calibration room asked for evidence of technical scope. It
did not exist, because they had spent the year doing the work
that produced no artifact.

The team could not function without them and the process could
not promote them, and both statements were true simultaneously.

This distributes unevenly along predictable lines, which is what makes it a fairness problem and not only a career one: the person who notices the gap and quietly fills it is disproportionately likely to be a woman or someone from an underrepresented group, and the promotion consequence compounds.

Mechanics

The transition conversation, done explicitly and early

Have it individually, in the first two weeks, with everyone, including the people you were not close to.

The four things to say out loud:

1. WHAT CHANGED, NAMED.
   "I now know things I can't share, and I'll say 'I can't talk
    about that' rather than deflect, so you'll know the
    difference between me not knowing and me not being able to
    say."

2. WHAT DID NOT CHANGE.
   "I still want you to tell me when I'm wrong. That is more
    useful to me now, not less, and it will get harder for you
    to do, so I'm going to keep asking."

3. THE WEIGHT PROBLEM.
   "My opinions now land heavier than I intend. If I say
    something that sounds like a decision and I meant it as a
    thought, ask me which one it was. I will not be annoyed."

4. THE ASK.
   "What would you want me to do differently now that I'm in
    this role? And is there anything about this that's
    awkward?"

The fourth question is the one that produces information, and
only if you ask it in week one, before there is a specific
incident it could be about.

The specific version for a close friend, held separately:

"Two things I want to say out loud. One, I'm going to be
 careful about fairness in a way that might feel like distance,
 and it isn't. Two, if you ever feel like I'm treating you
 harder than others to prove a point, tell me, because I might
 be and I won't notice."

Naming the overcorrection risk in advance is what makes it
correctable later, because you have given them permission to
raise it.

The first-quarter fairness discipline

Everyone is watching for favouritism, and they are watching the assignments rather than the words.

For the first quarter, over-index on visible fairness:

- ASSIGNMENT: write down who got what interesting work and
  check the distribution monthly. Not because you are biased,
  but because you cannot see your own pattern and other people
  can.
- ACCESS: if one person's 1:1 regularly runs long and others
  end on time, that is visible. Equalise it deliberately.
- INFORMATION: do not let your former close colleagues learn
  things first because you talk to them more. Announce to the
  group, then discuss individually.
- SOCIAL: continuing to have lunch with the same two people
  every day is a signal, whether you intend it or not. It is
  worth changing for a quarter and then relaxing.
- CORRECTION: the trap in the other direction. If you find
  yourself giving your friend harder feedback than the same
  behaviour would earn from someone else, that is
  overcorrection, and it is unfair in a way that is harder to
  see.

And the trap that is specific to a newly promoted technical lead:

KEEPING THE FUN WORK.

You were promoted because you were good at the technical work,
you still enjoy it, and there is a plausible story ("this is
the risky part, I should do it").

Every time you do, you take the most developmental piece of
work away from someone who needed it, and you signal that the
interesting work is not available to them.

The test: over a quarter, what fraction of the most
technically interesting work did you keep? If it is more than
roughly a tenth, that is the pattern, and it is the single
most common failure of a first-time technical lead.

Seeing glue work

You cannot distribute or credit what you cannot see, and it is invisible by construction.

The audit, once a quarter, half an hour:

For the last quarter, list the things that happened that were
not on anyone's roadmap:
  - who onboarded the new hires?
  - who ran the retros?
  - who noticed the cross-team problem before it shipped?
  - who answers the questions in the team channel?
  - who updated the runbooks after the last incident?
  - who chased the dependency?
  - who wrote the doc nobody was assigned to write?
  - who organised the offsite, the on-call swap, the rota?

Then count, per person. The distribution is almost never even,
and the lead's prior about who is doing it is frequently wrong,
because the whole property of glue work is that it is done
quietly.

The three responses, and all three are needed

1. DISTRIBUTE IT.
   Rotate the visibly non-promotable parts: retros, onboarding,
   the answer-desk role, the runbook. A named rotation removes
   it from "whoever is most conscientious", which is the actual
   allocation mechanism today.
   Some of it should also just stop: a meeting that only
   exists because someone keeps organising it is a candidate
   for deletion rather than rotation.

2. MAKE IT VISIBLE AND CREDITED.
   Glue work with an artifact is promotable; glue work without
   one is not. So convert where you can:
     answering the same question 5 times  -> the FAQ, with
                                             their name on it
     noticing the cross-team gap          -> a written design
                                             note circulated to
                                             both teams
     running retros                       -> a written pattern
                                             analysis across a
                                             quarter of
                                             incidents
   This is not cosmetic. The written version is genuinely more
   valuable, and it is also the version that survives to
   calibration.

3. PROTECT THE PROMOTION PATH.
   Tell the person explicitly: "you're doing a lot of the work
   that keeps this team running, I see it, and it will not get
   you promoted on its own. So I'm rotating half of it away
   from you, and I'm giving you [named technical scope] which
   will."
   Saying it out loud is necessary, because the person doing
   the glue work usually believes it is what a good colleague
   does, and stopping feels like letting people down.

Point 3 is the conversation people avoid because it sounds like devaluing the work. The framing that works is that the work is valuable, the reward system does not see it, and the lead's job is to manage that gap rather than to pretend it does not exist.

And in the calibration room, value it explicitly:

Not: "they're the glue of the team."   (an adjective)
But: "they built the onboarding path that took our
      time-to-first-commit from 19 days to 3, ran the retro
      programme whose action-item completion rate is 84%
      against an org average of 40%, and caught two cross-team
      design mismatches before they shipped, one of which the
      platform team's own review had missed."

Same work. The second version is scope evidence.

A worked example: a promotion, a rotation, and a friendship

An engineer promoted to lead of the team they had been on for two years, with eight reports, two of whom were close friends and one of whom had also applied for the role.

The first two weeks: individual transition conversations with all eight.

The four points, said the same way to everyone. Then the
question: "is there anything about this that's awkward?"

Answers worth recording:

The person who had also applied: "Honestly, yes. I'm fine with
  it, and I'd like to know what you think I'd need to be
  considered next time."
  -> that is a career conversation the lead could not have
     initiated without it being patronising, and it became a
     concrete plan.

A close friend: "I'm worried you'll be weird with me."
  -> which is exactly the overcorrection risk, named by the
     other person in week one, and the lead's answer ("I might
     be, and you should tell me") made it correctable.

A quieter engineer the lead had not been close to: "It'll be
  fine as long as decisions get explained. Before, things just
  happened and nobody said why."
  -> a specific process request from someone who would not have
     volunteered it unprompted, and it became the team's
     decision-log practice.

Three of eight conversations produced information the lead would not otherwise have had, and all three came from the same closing question.

The first-quarter fairness data:

The lead tracked assignment of "interesting" work (defined in
advance as: new systems, cross-team scope, anything with
external visibility) for one quarter.

Month 1, before tracking:
  of 6 such items, 4 went to the two former close colleagues.
  The lead's own read at the time was "they were the right
  people".

That distribution was not visible until it was written down,
which is the point of writing it down.

Months 2-3, corrected:
  of 9 items, 2 to those two, 7 distributed. Two went to people
  who were slower at them, which cost time and was the price.

Four of six is not a subtle bias and the lead did not see it, which is the general argument for measuring assignment rather than trusting the read.

The fun-work trap, caught by a report:

Month 4, in a 1:1, an engineer said: "you took the rate-limiter
rewrite. That was the piece I wanted."

The lead's justification had been that it touched the payment
path and was risky. It was also the most interesting thing on
the roadmap.

Count for the quarter: of 5 items the lead considered the most
technically interesting, they had kept 2.

Handed it over, with two weeks of pairing. It took longer. The
engineer's own later feedback was that it was the thing that
made them believe they had a future on the team.

Keeping two of the five most interesting items is 40 percent, which is far past the tenth this page recommends and was invisible until someone said it.

The glue-work audit, run at the end of the first quarter:

Non-roadmap work in the quarter, by person:

  Priya    onboarding doc + onboarded 2 hires, ran 5 of 6
           retros, answers ~70% of the team-channel questions,
           maintains the runbooks, organised the on-call swap
           twice
  Jo       ran 1 retro, wrote 1 runbook
  Alex     none identified
  Sam      chases the identity-team dependency weekly
  (four others: negligible)

Priya was carrying roughly 60% of the identified glue work.

Priya's technical output that quarter was the lowest on the
team, and the lead's prior read of that had been "steady but
not stretching".

"Steady but not stretching" was a misreading of someone doing 60 percent of the team's invisible work, and it would have become a calibration statement.

The three responses, applied:

DISTRIBUTE: retros became a named rotation, one per person per
  cycle. The answer-desk role became a weekly rotation (this
  also became the interrupt shield). Onboarding became a named
  buddy assignment per hire rather than defaulting to Priya.
  One recurring meeting Priya had been organising was deleted
  entirely, because nobody could say what it was for.

MAKE VISIBLE: Priya's onboarding work became a written
  onboarding path with her name on it and measured outcomes
  (time-to-first-commit 19 days -> 3). The retro work became a
  written quarterly pattern analysis, which found that 4 of 11
  incidents that quarter had the same root cause, which nobody
  had noticed one retro at a time.

PROTECT THE PATH: the explicit conversation.
  "You're doing about 60% of the work that keeps this team
   running. I see it, it's valuable, and it will not get you
   promoted on its own, which is a failure of the system rather
   than of you. So I'm rotating half of it away, and I'm giving
   you the streaming migration, which is the scope you need."

  Priya's response, recorded because it is the common one:
  "But then who does it?"
  -> the answer had to be concrete (the rotation, by name, with
     dates) before she would let go of it.

"But then who does it" is the reliable response, and a vague answer means nothing changes, because the person doing glue work stops only when they can see it is genuinely covered.

Results, one year on:

                              before        after
glue work share, most-loaded
  person                        ~60%          ~22%
interesting work to former
  close colleagues            4 of 6      2 of 9, then even
lead's share of the most
  interesting work               40%          ~10%
Priya's promotion             not in cycle  promoted, on the
                                            streaming migration
                                            plus the onboarding
                                            and retro artifacts
regretted attrition               n/a           0

The person who had also applied for the lead role was promoted
to senior the same cycle, on the plan built from that first
awkward conversation.

And one thing that did not resolve cleanly:

One of the two close friendships did become more distant, and
the lead's honest assessment was that this was partly
unavoidable and partly their own overcorrection. It was raised
by the friend, months later, using the permission granted in
the week-one conversation.

The lead's recorded note: "I was harder on him in reviews than
I would have been on anyone else, to prove to myself I wasn't
favouring him. He noticed before I did."

Recorded because the alternative reading, that the transition
conversation solves this, is not true. It makes it discussable.

Production evidence

Tanya Reilly's "Being Glue" talk and essay is the canonical treatment: it names the category, argues that the work is essential and non-promotable, documents that it accretes on the most conscientious people, and makes the case that leaders must both distribute it and value it explicitly rather than relying on gratitude.

Research on non-promotable tasks (Babcock, Recalde, Vesterlund and Weingart's work on the "office housework" pattern, published in the American Economic Review and summarised in The No Club) finds that such tasks are disproportionately assigned to and volunteered for by women, and that the effect persists in randomised settings, which is why this is a fairness issue rather than only a career one.

Google's re:Work materials on manager transitions and the broader literature on first-time managers consistently identify the peer-to-manager transition as the highest-failure-rate transition, with the two documented failure modes being avoidance of difficult conversations and overcorrection into distance.

Camille Fournier's The Manager's Path and Michael Lopp's writing both treat the explicit transition conversation with former peers as a required early action rather than an optional courtesy, on the grounds that the relationship has already changed and the only question is whether it is renegotiated deliberately.

Published engineering career ladders express advancement in terms of scope and artifacts, which is the structural reason glue work does not promote: it produces outcomes without artifacts, and the calibration room reads artifacts.

Proximity bias research in hybrid teams documents the analogous invisibility problem for remote workers, and the remedy is the same: measure the distribution rather than trusting a manager's recollection of who did what.

The debate

Should you keep any technical work as a lead? Some, and the useful boundary is that you should keep work that nobody's growth depends on: the tedious migration, the on-call shift, the boring but necessary refactor. What you must not keep is the most interesting piece, because that is the developmental one, and the plausible story ("this is the risky part") is always available.

Is the transition conversation awkward enough to skip? It is awkward for ten minutes and the alternative is awkward for a year. The specific value is the closing question, "is there anything about this that's awkward", which only produces information if asked in week one before there is an incident it could be about.

Can you stay friends with a former peer you now manage? Differently, yes, and pretending nothing changed is the failure. The overcorrection is the more common and more damaging error among conscientious people, and it is only correctable if you named the risk early and gave them permission to raise it, because you will not notice it yourself.

Should glue work simply be eliminated? Some of it, yes, and the audit usually finds a recurring meeting or a report nobody can justify. Most of it is genuinely necessary, which is why rotation plus artifact conversion is the answer rather than deletion. The version that fails is telling people to stop doing it without saying who does it instead.

Is converting glue work to artifacts just gaming the promotion system? The written version is genuinely more valuable: a written onboarding path serves every future hire where a helpful colleague serves one, and a quarterly retro pattern analysis found a repeated root cause that one-retro-at-a-time had missed. The artifact is better work, and being promotable is a side effect rather than the purpose.

Should you tell someone their glue work will not promote them? Yes, explicitly, and the framing matters: the work is valuable, the reward system does not see it, and managing that gap is the lead's job. Leaving it unsaid means the person discovers it at calibration, which is both worse and later.

Follow-up Q&A

"What actually changes when you start managing former peers?"

You hold information you cannot share, so silence now means something; your casual opinion is a directive whether you intend it or not; complaining to you becomes a risk for them, so you stop hearing the complaints that used to reach you; and the friendship has an asymmetry it did not have. None of that is optional, so the only question is whether it gets renegotiated deliberately. The conversation is four points, said individually to everyone in the first two weeks, and it ends with "is there anything about this that's awkward," which only produces an honest answer if you ask before there is a specific incident it could be about.

"What is the most common failure of a first-time technical lead?"

Keeping the interesting work, with a plausible justification. It is the risky part, or you are fastest at it, or it touches the payment path. Every time, you take the most developmental piece away from someone who needed it and signal that the interesting work is not available to them. In one case the lead had kept two of the five most interesting items in a quarter, 40 percent, and only found out because a report said "you took the rate-limiter rewrite, that was the piece I wanted." The boundary that works is keeping work nobody's growth depends on.

"How do you avoid favouritism, and what is the trap in the other direction?"

Measure the assignments rather than trusting your read, because you cannot see your own pattern. In one first month, four of six interesting items went to the two former close colleagues, and the lead's contemporaneous read was that they were simply the right people. The trap in the other direction is overcorrection: being harder on your friend than the same behaviour would earn from anyone else, to prove impartiality to yourself. It is the more common error among conscientious people, it is unfair in a way that is harder to see, and you will not notice it, which is why naming it in week one and giving them permission to raise it is the only real mitigation.

"What is glue work and why does it matter to a lead?"

The coordination, communication and maintenance work that makes a team function and that no rubric rewards: onboarding, retros, the answer desk, runbooks, noticing the cross-team gap, chasing the dependency. It is high-value work with no attribution mechanism, and it accretes on whoever is most conscientious, which is not randomly distributed: the research on non-promotable tasks finds it falls disproportionately on women, and it persists in randomised settings. So it is simultaneously a team health issue, a career issue and a fairness issue, and the lead is the only person positioned to see the distribution.

"How do you fix it?"

Three things, all of them needed. Distribute it, with named rotations so the allocation mechanism stops being "whoever cares most," and delete the parts nobody can justify. Make it visible by converting it into artifacts, since a written onboarding path with measured outcomes is promotable where being helpful is not, and the written version is genuinely more valuable anyway. And protect the promotion path explicitly: tell the person you see the work, that it will not promote them on its own, that this is a failure of the system rather than of them, and that you are rotating half of it away and giving them named technical scope instead. Expect "but then who does it," and have a concrete answer with names and dates, because a vague one means nothing changes.

"How do you argue for glue work in a calibration room?"

Convert it into scope evidence with numbers. Not "they're the glue of the team," which is an adjective, but "they built the onboarding path that took time-to-first-commit from 19 days to 3, ran the retro programme whose action-item completion rate is 84 percent against an org average of 40, and caught two cross-team design mismatches before they shipped, one of which the platform team's own review missed." Same work, and the second version is evidence a room can act on.

Common misconceptions

"If I don't change anything, the friendship stays the same." It already changed on day one. Not naming it means it gets renegotiated by a series of small incidents instead.

"Being fair means treating my friend the same as everyone." It means treating them the same, which includes not being harder on them to prove something to yourself. That is the error conscientious people actually make.

"I should keep the risky work." The risky work is usually also the interesting work, and that is the developmental piece. Keep the tedious necessary things instead.

"Glue work is low-value work." It is high-value work with no attribution mechanism, which is a different problem with a different fix.

"The people doing glue work should just stop." They stop only when they can see who does it instead, by name and date. Telling them to stop without that changes nothing except how guilty they feel.

"Recognising glue work in a review is enough." Recognition without redistribution keeps the same person doing 60 percent of it next quarter, and recognition without an artifact does not survive calibration.

Interview delivery note

Say this verbatim: "Glue work is essential, invisible and non-promotable, and it accretes on whoever is most conscientious rather than being assigned. So the lead's job is three things: rotate it so the allocation stops being self-selection, convert it into artifacts so it can be credited, and tell the person explicitly that it will not promote them on its own, because they usually think it is just what a good colleague does." Naming glue work unprompted is a strong people-leadership signal, and the three responses show you have actually done something about it.

The senior-versus-staff separator is measuring the distribution rather than trusting your read. A senior lead notices that one person does a lot of the invisible work. A staff lead runs a half-hour quarterly audit listing everything that happened that was not on the roadmap, counts it per person, finds one person carrying 60 percent, and discovers that their own prior read of that person as "steady but not stretching" was a misreading of someone doing most of the team's uncredited work. The same discipline applied to assignment found four of six interesting items going to two former close colleagues in a month the lead thought was fine.

The second signal is naming the overcorrection risk out loud in week one. Saying "I'm going to be careful about fairness in a way that might feel like distance, and if you ever think I'm treating you harder than others to prove a point, tell me, because I might be and I won't notice" shows you know the more common failure among conscientious new leads is distance rather than favouritism, and that you cannot detect it yourself.

Further reading

• Tanya Reilly, "Being Glue," for the naming of the category and the argument for distributing and valuing it.
• Babcock, Recalde, Vesterlund and Weingart on non-promotable tasks, and The No Club, for the distributional evidence.
• Camille Fournier, The Manager's Path, on the peer-to-manager transition.
• The promotions and the calibration room page, for turning glue work into evidence a room can act on.
• The growing people page, for the assignment discipline that this page's distribution audit feeds.

Legacy modernisation as a narrative

What it is

Every senior loop eventually asks about an old system. The question is not really about the system, it is about whether you can work on something you did not build without contempt for the people who did.

The arc that reads as seasoned, and it is a genuine method rather than a rhetorical posture:

1. UNDERSTAND BEFORE JUDGING
   The code is the way it is for reasons that were once good.
   Find them before you change anything.

2. CHARACTERISATION TESTS
   Capture what the system actually does, including the parts
   that are wrong, before you touch it. You cannot refactor
   without a definition of "unchanged".

3. FIND THE SEAMS
   The places where you can insert new behaviour without
   modifying the old code. Seams are what make incremental
   change possible at all.

4. STRANGLER INCREMENTS, WITH VALUE AT EVERY STEP
   Route slices of traffic or functionality to the new
   implementation, one at a time, each independently valuable
   and independently revertible.

5. CELEBRATE DELETION
   The migration is not done when the new thing works. It is
   done when the old thing is gone, and if you do not make
   deletion a visible milestone it never happens.

What this is confused with: the rewrite. A rewrite is the intuitive answer, it is almost always wrong, and the reason is not sentiment: the old system contains years of accumulated corrections you cannot see and cannot enumerate, and a rewrite discards all of them at once and rediscovers them in production.

Also confused: modernisation and technology upgrade. Moving a system from one framework to another without changing its boundaries produces the same system with newer dependencies and a year of disruption. The value of modernisation is in the seams you create, not the framework you land on.

The problem it solves

Contempt for legacy code is a junior tell, and it produces a specific and predictable failure.

"This code is a mess, we should rewrite it."

Six months in:
  - 70% of the functionality is reimplemented
  - the remaining 30% is the part nobody understands, which is
    also the part that handles the exceptions that make the
    business work
  - the old system is still running, still being changed by
    people fixing bugs, so the target moved
  - the team has shipped no user-visible value in six months
  - the sponsor's patience has expired

Outcome: the rewrite is cancelled, or it ships and immediately
produces incidents in exactly the cases the old code handled
and nobody documented.

And the reason it fails is structural. The old system's ugliness is largely accumulated knowledge:

if (country == "BR" && orderType == "MARKETPLACE") {
    taxBase = subtotal;      // not subtotal + shipping
}

Reads as: an arbitrary special case, evidence of a mess.
Actually is: a tax rule, discovered in production in 2019 after
an audit, that cost the company a penalty. There is a Jira
ticket from six years ago and nobody currently employed
remembers.

A rewrite removes it. Production rediscovers it.

The honest framing: a legacy system is a specification that has been tested against reality for years, written in a language you find unpleasant.

Mechanics

1. Understand before judging

Before proposing anything, be able to answer:

  - what does this system do that nothing else does?
  - who depends on it, including the ones not in the
    architecture diagram (the batch job, the report, the
    partner's nightly pull, the spreadsheet someone maintains)
  - what are its actual traffic, data volume and error rates?
  - what changed most recently, and why? (git log is a
    reasonable proxy for where the pain is)
  - what are the five weirdest pieces of code in it, and what
    is the story behind each?

The last one is the highest-value exercise. For each oddity,
find the commit, the ticket, or the person. Some will be
genuine mistakes. Many will be a rule you did not know
existed.

Talk to whoever is left, early, and ask a specific question rather than a general one:

Not: "so how does this thing work?"
But: "what is the part of this system that you're most afraid
      of changing, and why?"

That question produces the risk map in about ten minutes, from
someone whose knowledge is otherwise unextractable.

And say out loud, to the people who built it, that the constraints were different. It costs nothing, it is usually true, and the alternative is that the people whose help you need spend the project defending themselves.

2. Characterisation tests

A characterisation test does not assert what the code should do. It records what it does.

# Not a correctness test. A description of current behaviour,
# including behaviour that is probably wrong, so that a
# refactor can be proven not to change anything.
@pytest.mark.parametrize("case", load_recorded_cases("prod_sample_2024_03.jsonl"))
def test_pricing_matches_recorded_behaviour(case):
    result = legacy_price(case["input"])
    assert result == case["recorded_output"], (
        f"behaviour changed for {case['id']}; if this is intentional, "
        f"update the fixture and say why in the commit message"
    )

Generating them from production is the technique that makes this practical:

1. Capture a sample of real inputs and outputs in production
   (log them, or mirror traffic). A few thousand cases covering
   the distribution beats a hundred hand-written ones.
2. Stratify the sample so rare paths are represented: sample by
   country, order type, currency, error class, not uniformly by
   volume. Uniform sampling gives you 5,000 copies of the
   common case.
3. Freeze them as fixtures.
4. Now refactor. Any behavioural change shows up as a diff.

The uncomfortable part, and it is the point: some of the recorded behaviour is wrong. Record it anyway. Fixing a bug and refactoring are two changes, and doing them together means you cannot tell which one broke production. Record the wrong behaviour, ship the refactor, then fix the bug as its own change with its own test.

Where behaviour cannot be captured offline, run a comparison in production:

Old path serves the response. New path computes in parallel.
A job diffs them and reports mismatches by category.

This is the same mechanism as shadow traffic and it is the
strongest available evidence, because it exercises the real
input distribution including the cases nobody thought to
sample.

3. Seams

A seam is a place where you can change behaviour without editing the code around it. Legacy code is hard to change mainly because it has none.

Common seams, easiest first:

ROUTING SEAM       a proxy, gateway or router in front. Send
                   some requests elsewhere. Requires no change
                   to the old code at all, which is why it is
                   first.
INTERFACE SEAM     extract an interface around a dependency,
                   inject an implementation. The classic
                   refactoring seam.
EVENT SEAM         the old system already emits something (a
                   database write, a log line, a message). Read
                   it and build alongside, without touching it.
                   CDC on the legacy database is the strongest
                   version and requires zero legacy changes.
DATA SEAM          dual-write or replicate the data so a new
                   system can be built on it before any traffic
                   moves.
FEATURE FLAG SEAM  a branch inside the old code. Requires
                   editing it, which is why it is last, and it
                   is the one people reach for first.

The ordering matters because each seam's cost is the amount of legacy code you must modify to create it, and modifying legacy code is the risky operation you are trying to minimise.

Michael Feathers's definition is the operative one: legacy code is code without tests, and the problem is that to add tests you must change the code, and to change the code safely you need tests. Seams are the way out of that loop.

4. Strangler increments

The pattern (Martin Fowler's Strangler Fig): grow the new
system around the old one, moving one capability at a time,
until the old one can be removed.

The discipline that makes it work:

EACH INCREMENT IS INDEPENDENTLY VALUABLE.
  Not "phase 1: build the framework". If the project is
  cancelled after increment 3, increments 1 to 3 must have
  been worth doing on their own.

EACH INCREMENT IS INDEPENDENTLY REVERTIBLE.
  A flag or a route weight, flipped back in seconds.

SLICE BY BUSINESS CAPABILITY, NOT BY LAYER.
  "Move the database first, then the service layer" leaves you
  with two half-systems and no working slice.
  "Move refunds end to end" gives you a complete, testable,
  revertible capability.

START WITH THE SLICE THAT IS HIGH VALUE AND LOW RISK, not the
  hardest one. You need a demonstrated success before you have
  the credibility to attempt the frightening part.

THE ORDER IS A JUDGEMENT AND SHOULD BE WRITTEN DOWN, with the
  reasoning, because it will be questioned by everyone who
  arrives later.

Sequencing by value delivered at every step is the difference between a migration that survives a reorganisation and one that does not, and reorganisations happen on an 18-month timescale while migrations take longer.

5. Celebrate deletion

The failure: the new system works, traffic has moved, and the
old system is still running because turning it off is nobody's
priority and slightly scary.

Two years later you are operating both, paying for both,
patching both, and every new engineer has to learn both.

The discipline:
  - the migration plan's LAST milestone is deletion, named,
    with a date, from the beginning
  - measure and publish residual traffic to the old path
    weekly, so "nearly zero" becomes visible as "0.4%, which is
    the reporting job and one partner"
  - track and chase the last callers by name. The tail is
    always a small number of identifiable dependents.
  - make deletion a visible celebration: the announcement, the
    lines-removed number, the retired dashboards, the
    infrastructure cost that stops.

The last one is not sentiment. It is how you make the NEXT
migration finishable, because the team learns that these
projects end.

"Lines deleted" and "systems retired" belong in the same status update as "features shipped", and a lead who never reports them is running an organisation where nothing is ever finished.

A worked example: an order-pricing engine nobody would touch

A 12-year-old pricing service. 41,000 lines, one language version behind support, three people who had ever changed it, two of whom had left. Every product change involving price took a quarter, and the standing proposal, made twice before and cancelled twice, was a rewrite.

Phase 0: understand, three weeks.

Findings:
  - 41,000 lines, of which git blame showed 68% unchanged in
    5 years, and 31 files accounting for 80% of all changes
  - 14 consumers, of which 5 were not in the architecture
    diagram: two batch reports, a partner's nightly pull, a
    finance spreadsheet, and an internal admin tool
  - the five weirdest code sections, investigated:
      2 were genuine mistakes nobody had cleaned up
      3 were rules with documented origins: a Brazilian tax
        base rule from a 2019 audit, a rounding rule for one
        currency required by a payment processor, and a
        grandfathered discount for 40 accounts on a contract
        signed in 2015

The Brazilian rule alone would have been rediscovered in
production by a rewrite, with a penalty attached.

The question that produced the risk map:

Asked of the one remaining original engineer: "what part of
this are you most afraid of changing?"

Answer, in about eight minutes: the promotional-stacking
logic, because the order of operations was determined
empirically over two years of finance complaints and there is
no specification. "If you change the order, the numbers move
by fractions of a cent and finance notices in the monthly
close, six weeks later."

That is a risk nobody would have found by reading the code,
and it set the migration order: promotional stacking went
LAST.

Phase 1: characterisation, four weeks.

Captured 90 days of production inputs and outputs, stratified:
  by country (18), order type (6), currency (11), and error
  class, rather than by volume.
  -> 22,000 cases, of which the top 3 countries would have
     supplied 94% under uniform sampling and did supply 31%
     under stratified sampling.

Test suite runtime: 40 seconds.

Immediate finding: 3 of the 22,000 cases produced
non-deterministic output, because a discount tiebreak used a
hash-map iteration order. That is a real bug, it had been
producing occasional penny differences for years, and it was
recorded as-is rather than fixed, then fixed separately two
weeks later with its own test.

Recording the bug rather than fixing it in the same change is the discipline, and it is what let the team later prove that the refactor changed nothing.

Phase 2: seams, three weeks.

ROUTING SEAM: the pricing service was already behind an
  internal gateway. A route rule keyed on (country, orderType)
  could send a slice to a new service. Zero legacy code
  changed.

EVENT SEAM: the legacy service wrote every priced order to a
  table. CDC on that table gave the new implementation a
  comparison stream without touching the legacy code at all.

Those two were sufficient. No feature flags were added inside
the legacy code base, which had been the previous attempts'
starting point and the reason both had stalled: editing the old
code required understanding it first, which was the thing they
did not have.

Phase 3: strangler increments, five quarters.

Order chosen, and written down with reasoning:

  1. SHIPPING COST calculation.       (Q1)
     High value: it changed 4x a year and each change took 6
     weeks. Low risk: self-contained, few interactions.
     Delivered on its own: shipping changes went from 6 weeks
     to 3 days. That number funded everything after it.

  2. TAX.                             (Q2)
     High value: a new market launch was blocked on it. Medium
     risk: the Brazilian rule, now understood and explicitly
     ported with a comment linking the 2019 ticket.

  3. BASE PRICE AND CURRENCY.         (Q3)

  4. VOLUME AND CONTRACT DISCOUNTS.   (Q4)
     Including the 40 grandfathered accounts, ported as data
     rather than as code.

  5. PROMOTIONAL STACKING.            (Q5)
     Last, deliberately. Ran in shadow for 8 weeks with a
     penny-level diff report to finance BEFORE any traffic
     moved, which was the condition finance asked for and
     which the team offered rather than waited for.

Each increment: route a slice, compare in shadow, ramp, keep
the old path revertible for 30 days, then remove the route.

Increment 1 delivering a six-weeks-to-three-days improvement in its own quarter is what made increments 2 to 5 possible, because the project stopped being a cost and started being a thing that had already paid for itself.

The shadow comparison, and what it caught:

Across the five increments, shadow comparison found 31
behavioural differences before any traffic moved.

  19 were bugs in the new implementation
   9 were bugs in the OLD implementation that the new one had
     accidentally fixed
   3 were genuine ambiguities requiring a product decision

The 9 are the interesting category: each one had to be a
deliberate decision, because "the new system is more correct"
still changes what a customer is charged. Two were fixed in
both systems first, so that the migration remained
behaviour-preserving; seven were shipped as intentional
changes with finance sign-off and a customer-communication
plan for one of them.

"The new system is more correct" is still a behaviour change, and treating it as a free improvement is how a migration produces an incident it did not need to.

Phase 4: deletion.

After increment 5, residual traffic to the legacy service:
  week 1   4.1%
  week 4   0.9%
  week 8   0.4%   <- and stuck there

Chased by name:
  0.3%  the finance spreadsheet, pulling a legacy endpoint
        nightly. Owner found, migrated in 2 days.
  0.1%  the partner nightly pull. 6 weeks of notice, then
        migrated.
  <0.01% an admin tool nobody had used in 14 months. Deleted.

Legacy service decommissioned 11 weeks after the last
increment, which was on the plan from the beginning as a named
milestone with a date.

Reported:
  41,000 lines deleted
  2 database instances and 6 EC2 instances retired
  $3,100/month of infrastructure stopped
  the on-call runbook shortened by 9 pages

The 0.4 percent that would not fall was three identifiable callers, which is the normal shape of a migration tail, and none of them would have been found without publishing the residual number weekly.

And the honest accounting:

Total elapsed: 6 quarters, roughly 2.5 engineers throughout.
The original rewrite proposal had estimated 2 quarters, which
is the usual ratio.

The team shipped user-visible value in 5 of the 6 quarters,
which is why it was never cancelled, and both previous
attempts had been cancelled in quarter 2 with nothing shipped.

Production evidence

Martin Fowler's Strangler Fig Application (2004) is the canonical description of incremental replacement around a legacy system, with the explicit argument that a big-bang rewrite carries risk that grows with the size of the system while incremental replacement delivers value continuously.

Michael Feathers's Working Effectively with Legacy Code defines legacy code as code without tests, names the change-to-test / test-to-change deadlock, and introduces seams as the mechanism for breaking it. Characterisation tests are his term and his method.

Joel Spolsky's "Things You Should Never Do, Part I" (2000), written about Netscape's decision to rewrite its browser, is the standard reference for the argument that the old code's ugliness encodes accumulated bug fixes that a rewrite discards, and Netscape's outcome is the canonical case study.

GitHub's Scientist library implements the run-both-and-compare pattern for exactly this situation, and its documented use for refactoring critical paths is the tooling form of the shadow comparison described above.

Change data capture as a seam (Debezium and equivalents) is widely used specifically to build new systems alongside legacy databases without modifying the legacy application, which is what makes it the lowest-legacy-change seam available.

Published incremental-migration accounts from Shopify, Etsy, Stripe and others consistently describe the same structure: slice by capability rather than by layer, ship value per increment, compare in production before moving traffic, and treat decommissioning as an explicit tracked milestone.

The debate

Is a rewrite ever right? Yes, in narrow conditions: the system is small enough to be fully understood, its behaviour is genuinely specified elsewhere, the platform is being discontinued, or the domain has changed so fundamentally that the old behaviour is not worth preserving. The test is whether you can enumerate what it does; if the answer requires archaeology, incremental replacement is the only approach whose risk you can bound.

Should you fix bugs found during characterisation? Not in the same change. Record the wrong behaviour, ship the refactor, then fix the bug separately with its own test, because combining them means a production problem cannot be attributed to one or the other. The counter-argument, that shipping known-wrong behaviour feels bad, is real and is answered by the separate fix arriving two weeks later.

Is "the new system is more correct" a good outcome? It is a behaviour change and must be treated as one. Nine of 31 differences found in shadow comparison in one migration were old-system bugs the new one had accidentally fixed, and each required a decision, because changing what a customer is charged is a product event regardless of which value is more defensible.

Slice by capability or by layer? By capability, always. Layer-first migrations produce two half-systems with no working slice, no independently deliverable value, and nothing to revert to. The pull toward layer-first is strong because it looks tidier on an architecture diagram.

Does the strangler approach take longer? In elapsed time, usually yes, and in delivered value it is ahead almost immediately. The relevant comparison is not against the rewrite's estimate but against the rewrite's outcome, and in the worked example both previous rewrite attempts were cancelled in their second quarter with nothing shipped.

Is celebrating deletion sentimental? It is a control. Without a named deletion milestone with a date and a weekly residual-traffic number, the old system runs indefinitely, and you pay for both, patch both, and onboard every new engineer onto both. Publishing lines deleted and systems retired alongside features shipped is how a team learns that these projects end.

Follow-up Q&A

"Why is a rewrite usually wrong?"

Because the old system's ugliness is largely accumulated knowledge you cannot enumerate. A special case that reads as evidence of a mess is often a tax rule discovered after an audit, a rounding requirement from a payment processor, or a grandfathered contract term, each with a ticket from years ago and nobody currently employed who remembers. A rewrite discards all of them simultaneously and rediscovers them in production. The structural failure is also predictable: the last 30 percent is the part nobody understands, the old system keeps changing so the target moves, and no user-visible value ships for months, which is why the sponsor cancels it.

"What is a characterisation test and why record known-wrong behaviour?"

It records what the code currently does rather than what it should do, so that a refactor can be proven not to change anything. You record the wrong behaviour because fixing a bug and refactoring are two changes, and doing them together means a production problem cannot be attributed to either. In one migration, three of 22,000 captured cases were non-deterministic because a discount tiebreak used hash-map iteration order; that was recorded as-is, the refactor shipped provably behaviour-preserving, and the bug was fixed two weeks later as its own change with its own test.

"How do you generate characterisation tests at scale?"

Capture real production inputs and outputs, and stratify the sample rather than sampling by volume. Sample by country, order type, currency and error class, because uniform sampling gives you thousands of copies of the common case: in one instance the top three countries would have been 94 percent of a uniform sample and were 31 percent of a stratified one. Where behaviour cannot be captured offline, run both implementations in production and diff the results, which is the strongest evidence available because it exercises the real input distribution including cases nobody thought to sample.

"What is a seam, and which ones do you prefer?"

A place where you can change behaviour without editing the code around it. Prefer them in order of how much legacy code they require you to modify, since modifying legacy code is the risky operation. A routing seam at a gateway requires zero legacy changes. An event seam, especially change data capture on the legacy database, also requires zero. An interface extraction requires some. A feature flag inside the old code requires the most, and it is what people reach for first, which is why previous attempts stall: editing the old code requires understanding it, which is the thing you do not yet have.

"How do you sequence a strangler migration?"

By business capability rather than by layer, so each increment is a complete, testable, revertible slice, and starting with something high value and low risk rather than the hardest part. In one case shipping-cost calculation went first: it changed four times a year and each change took six weeks, so moving it took that to three days and delivered a result in its own quarter. That number funded the remaining four increments. The frightening part, promotional stacking whose operation order had been determined empirically over two years of finance complaints, went last and ran in shadow for eight weeks with a penny-level diff report before any traffic moved.

"How do you make sure the old system actually gets deleted?"

Put deletion on the plan as the last named milestone with a date, from the beginning, and publish residual traffic to the old path weekly so "nearly zero" becomes "0.4 percent, which is the finance spreadsheet, one partner, and an admin tool nobody has used in 14 months." The tail is always a small number of identifiable callers, and chasing them by name is a two-week job once they are visible. Then report the deletion: lines removed, instances retired, monthly cost stopped, runbook pages deleted. That is not sentiment, it is how the team learns these projects end, which is what makes the next one finishable.

Common misconceptions

"This code is a mess, we should rewrite it." The mess is largely accumulated corrections you cannot enumerate, and a rewrite rediscovers them in production.

"Fix the bugs while you refactor." Then you cannot attribute a production problem to either change. Record the current behaviour, refactor, fix separately.

"The new system being more correct is a bonus." It is a behaviour change, and changing what a customer is charged is a product event regardless of which value is more defensible.

"Migrate the database first, then the services." Layer-first leaves two half-systems, no deliverable slice, and nothing to revert to. Slice by capability.

"Start with the hardest part while there is momentum." You need a demonstrated success before you have the credibility for the frightening part, and momentum is what an early delivered increment creates.

"The migration is done when the new system works." It is done when the old one is gone. Without a dated deletion milestone and a published residual-traffic number, you operate both indefinitely.

Interview delivery note

Say this verbatim: "The old code is the way it is for reasons that were once good, so I want to understand it before I judge it. A special case that reads as a mess is usually a tax rule from an audit or a contract term, and a rewrite discards years of accumulated corrections you cannot enumerate and rediscovers them in production." Contempt for legacy code is a junior tell; respect plus a method is the senior one, and this sentence carries both.

The senior-versus-staff separator is sequencing by value delivered per increment and saying why. A senior engineer describes the strangler pattern. A staff engineer says the first increment was shipping-cost calculation because it changed four times a year at six weeks a change, so moving it took that to three days and delivered a result in its own quarter, which funded the remaining four increments, and that both previous rewrite attempts had been cancelled in their second quarter with nothing shipped. Migrations outlive reorganisations only if each step is independently worth having done.

The second signal is treating an accidental correctness improvement as a behaviour change. Saying "shadow comparison found 31 differences, nine of which were old-system bugs the new implementation had accidentally fixed, and each of those needed a deliberate decision because changing what a customer is charged is a product event" shows you understand that behaviour preservation is the property you are buying, and that correctness improvements have to be shipped on purpose.

Further reading

• Martin Fowler, "Strangler Fig Application," for incremental replacement and its risk argument.
• Michael Feathers, Working Effectively with Legacy Code, for seams, characterisation tests and the test-change deadlock.
• Joel Spolsky, "Things You Should Never Do, Part I," for the Netscape rewrite as a case study in discarded accumulated knowledge.
• GitHub's Scientist library, for the run-both-and-compare pattern applied to refactoring critical paths.
• The shadow traffic and expand and contract pages, which are the deployment mechanics each strangler increment relies on.

The toxic code reviewer

"Your strongest engineer leaves code review comments that are technically correct and demoralising. Two juniors have told you privately that they dread putting up a PR. Handle it."

What the question is actually testing

Not conflict aversion. Interviewers already know you will say "I'd have a conversation with them". The three things being scored are:

1. Whether you protect the standard while changing the delivery. A weak answer either defends the engineer ("they're right about the code") or sacrifices the bar ("I'd ask them to be nicer"), and both are wrong. The standard is not the problem; the delivery is.
2. Whether you fix the system as well as the person. A team where one person's review style can demoralise two others has a review culture problem, not just a Dave problem. A lead who only has the individual conversation has solved this instance and none of the next ones.
3. Whether you can be specific. "I'd give them feedback" is a non-answer. "I'd pull three comments from last week's PRs and read the wording back to them" is an answer.

Structure every role-play like this one as first move, information I would gather, line I would not cross. That three-part shape is what turns a vague answer concrete, and it is worth saying explicitly as you begin.

The answer

First move: read the actual comments

Before any conversation, spend twenty minutes in the PR history. Pull five to ten real comments from the last two weeks. This is not optional and it changes the conversation completely, because you move from "some people feel bad" (which any engineer can dismiss as feelings) to "here are four comments, and here is what each one does to the author".

You are sorting them into three piles:

• Correct and well delivered. These are the ones you will praise, and you need them, because a conversation that contains only criticism gets heard as an attack on the standard.
• Correct and badly delivered. "This is wrong." "Did you even run this?" "We don't do it that way." These are the target.
• Not actually correct, or a matter of taste presented as a defect. These are the most damaging, because the author cannot tell them apart from the real findings, so they must treat every comment as blocking.

Also measure two things. Review latency: if their reviews arrive three days late, the harshness is landing on top of a delay, and the delay may be the larger problem. Rework: what fraction of their comments cause a change versus an argument. A reviewer whose comments cause change is effective; one whose comments cause debate is expensive.

Then: the private conversation, in SBI

Situation, Behaviour, Impact. Specific, timely, behavioural, and delivered as one conversation rather than dropped into a 1:1 alongside six other topics.

"On the payments PR on Tuesday, you commented 'this is obviously broken, did you test it at all'. You were right that the null case was unhandled. What happened next is that Priya spent two days rewriting a working implementation because she wasn't sure which parts of your review were blocking. That's the impact I want to change. Your technical judgment here is the best on the team and I am not asking you to lower the bar. I'm asking you to spend the extra ten seconds that makes the same finding actionable."

Then make the ask concrete rather than emotional, because "be kinder" is not something an engineer can act on:

• Say what is blocking and what is not, explicitly, on every comment.
• State the finding, not a judgment of the author. "This drops the null case at line 40, which will NPE for guest checkout" rather than "did you test this".
• Where you would reject, offer the shape of the fix. A review that only closes doors costs the author a full design cycle.
• Anything under two lines of disagreement: pick up the phone. Text is a bad medium for taste disputes, and a five-minute call resolves what a twelve-comment thread does not.

Then listen, because there is frequently a real grievance underneath. The two most common: "I am the only one who reviews carefully and I am tired" (a load problem you own), and "this code genuinely is not good enough and nobody backs me up" (a standards problem you own). If either is true, you have a second piece of work, and pretending otherwise makes the first conversation feel like a setup.

Then: change the system, without naming anyone

This is the part that separates a lead answer from an individual-contributor answer. Introduce these as team norms, in a team meeting, framed as improving review throughput. Nobody in the room needs to know they were prompted by one person.

A comment taxonomy. Prefix every comment with its severity:

blocking:   this must change before merge
suggestion: I would do it differently, your call
nit:        cosmetic, non-blocking, feel free to ignore
question:   I don't understand this, help me
praise:     this is good and I want to say so

This is cheap to adopt and disproportionately effective, because most of the harm comes from ambiguity rather than from tone. An author who cannot tell a nit from a blocker treats every comment as a blocker, which is exhausting. The convention is published as Conventional Comments if you want a spec to point at rather than inventing one.

Automate everything mechanical. Formatter, linter, import order, coverage threshold, all enforced in CI. Humans should never comment on style, because a style comment from a human reads as a judgment and the same rule from a linter reads as a rule. This single change removes a large fraction of the friction and nobody can object to it.

Publish a review order. Correctness, then design and boundaries, then tests, then readability, then nits. Stating the order in the team's review guide gives everyone permission to skip nits when the design is still wrong, and it gives you a shared language for "you are reviewing at the wrong level".

Rotate reviewers and pair-review. Nobody is the single gate for an area. Have the strong reviewer pair-review with a junior for two weeks: they narrate their reasoning, and the junior sees that the harsh comments come from a real model of the system rather than contempt. This converts a threat into a teacher, and it is the highest-leverage move available if the person is willing.

Instrument it. Time to first review, review queue depth and merge time, on a dashboard. Now the conversation is about numbers rather than feelings, and you will find out whether the problem got better.

Then: close the loop with the juniors

Go back to the two people who raised it. Tell them what changed (the taxonomy, the automation) without reporting on a private conversation. Tell them explicitly that a blocking: comment is a real requirement and everything else is genuinely optional, and that if they disagree with a blocking comment they should say so in the thread and you will back them. Then watch the next few PRs yourself, so you learn whether it worked rather than assuming.

Information I would gather

The actual comments, over at least two weeks. Review latency and queue depth per reviewer. Whether other people have the same experience or only these two, which distinguishes a pattern from a personality clash. Whether the strong reviewer is carrying a disproportionate review load. And whether the juniors' code is genuinely below the bar, because if it is, there is a coaching problem sitting underneath the review problem and fixing only the reviews leaves it in place.

The line I would not cross

I will not lower the technical bar to make the interaction pleasant. The bar is the reason the reviewer is valuable, and trading it away buys peace and costs the codebase.

I will not have this conversation in public, and I will not relay it to the juniors. Correction is private; that is not negotiable.

And I will not let it run indefinitely. If the behaviour has not changed after a direct conversation with a specific ask and a follow-up, it stops being feedback and becomes a performance conversation, documented, with my manager informed. Tolerating behaviour that drives people out is a decision to lose the people it drives out, and I would rather lose one strong engineer than three good ones.

Where this goes wrong

The lead softens it. "Some folks have mentioned the tone in reviews, maybe we could all be a bit more positive." The person does not recognise themselves in that sentence and nothing changes, and the juniors conclude you did not act.

The lead escalates too fast. Going straight to a performance conversation over review tone, with no direct feedback first, is unfair and gets you a justified complaint. The sequence matters: specific feedback, a concrete ask, a follow-up, and only then a formal process.

The lead solves it structurally and skips the person. Introducing the taxonomy without the conversation means the strong engineer keeps writing blocking: did you even test this, which is worse, because it now carries an official severity label.

The lead protects the juniors from the reviewer. Routing their PRs around the strong reviewer removes the friction and also removes the mentoring, and it tells everyone that the team has two tiers. Route around a person only as a last resort before a formal process, never as the fix.

Interviewer follow-ups

"What if the reviewer is right about the quality and the juniors really are shipping weak code?" Then I have two problems and I should say so. The review problem is about delivery and I handle it as above. The capability problem is mine: it means I have assigned work above someone's current level without support, or hired without a plan for ramping. The fix is pairing, a smaller scope with a clear stretch component, and design review before implementation rather than after, so the correction happens at the cheap stage. What I will not do is use "but the code is bad" as a reason to leave the review behaviour alone, because the two are independent.

"They say 'I'm just direct, this is a culture thing, I'm not changing'." I would separate directness from ambiguity and hold the line on the second. Directness is fine and I would defend it. What I am asking for is that a comment distinguishes a requirement from a preference and states the finding rather than a judgment of the author, and neither of those is about being soft. If they still refuse, the conversation changes: the team's ability to function is a job requirement, not a preference, and I would say that plainly, once, and then document it.

"They are your highest performer and they threaten to leave." I would take that seriously and not be held hostage by it. My honest read: an engineer who will quit over being asked to label their comments was likely to leave anyway, and the cost of two juniors leaving plus a team that avoids the codebase exceeds the cost of one departure. I would also check whether the threat points at a real grievance I have been ignoring, because it often does, and fixing that is the better outcome for everyone.

"How would you know it worked?" Time to first review and merge time, tracked before and after. The fraction of comments prefixed blocking: versus the rest, which tells you whether the ambiguity actually fell. Whether the two juniors are putting up PRs at their previous rate, since the tell for this problem is people batching work into fewer, larger PRs to reduce their exposure to review. And I would ask them directly in a 1:1 six weeks later, because the metric can improve while the experience does not.

"How does this change when a lot of the code is AI-generated?" It gets worse before it gets better, and this is worth raising unprompted. When generation speeds up, the bottleneck moves from writing to reviewing, and review queues back up within a couple of months of adoption. More volume through the same reviewer means more terse comments and more rubber-stamping at the same time. The counters are concrete: require the author to be able to explain generated code as their own, label AI-assisted PRs so reviewers calibrate, hold review queue depth and merge time as first-class metrics rather than anecdotes, and raise test requirements on generated code, because that is the check that scales when volume rises.

Production evidence

Google's publicly published engineering practices documentation includes a section on how to write code review comments, and its core guidance matches the advice above: be kind, comment on the code rather than the person, explain the reasoning, and balance giving explicit directions with pointing out problems and letting the author decide. It also publishes an explicit standard for what a reviewer should approve, which is the artifact that lets a team argue about the bar in the abstract rather than in a PR thread.

Conventional Comments (conventionalcomments.org) is the published specification for the blocking: / suggestion: / nit: labelling convention, which means you can adopt it by linking to a spec rather than by asking one person to change.

The 400-line threshold that shows up in review guidance across the industry traces to SmartBear's study of a Cisco code review programme, which reported that review effectiveness drops sharply beyond a few hundred lines. It is worth citing as a reason to cap PR size, because "review quality collapses past 400 lines" is a much stronger argument for small PRs than "small PRs are nicer".

Interview delivery note

Open with the structure and it will carry the whole answer: "First move, information I'd gather, line I wouldn't cross."

Then say this: "My first move is to read the actual comments, because 'people feel bad' is not actionable and 'here are four comments and what each one costs the author' is. Then a private SBI conversation with a specific behavioural ask, not 'be nicer'. Then I change the system, framed for the whole team rather than aimed at one person: a comment taxonomy so blocking and nit are distinguishable, automation of everything mechanical so humans never comment on style, and reviewer rotation so nobody is a single gate. The line I won't cross is lowering the bar. Their standard is why they're valuable; it's the delivery I'm changing."

The depth signal is the system change plus the measurement. Most candidates produce the conversation. Fewer produce the taxonomy and the automation. Almost nobody says how they would know whether it worked, and adding review latency and queue depth as the check is what makes it sound like something you have actually run.

Further reading

• Google's engineering practices documentation, "How to write code review comments" and "The standard of code review" (google.github.io/eng-practices).
• Conventional Comments (conventionalcomments.org), for the labelling specification.
• Tanya Reilly, The Staff Engineer's Path, on the difference between holding a standard and being the gate.
• Camille Fournier, The Manager's Path, the tech lead chapter, on giving feedback to someone more technically senior than you in their area.

Making the reliability investment case

"Make the case for spending 25 percent of your team's capacity on reliability to a product-focused VP."

What the question is testing

Not whether you value reliability. Everyone does, and saying so persuades nobody. Three things:

1. Can you speak the other person's language? A VP whose objectives are growth and roadmap does not have a slot for "technical debt". They have slots for revenue, cost, risk and speed. If your argument does not land in one of those, it does not land.
2. Do you have numbers or a feeling? "Things are fragile" is a feeling. "We spent 340 engineer-hours on incidents last quarter, which is 18 percent of capacity, and here are the three causes" is an argument.
3. Are you asking or negotiating? A request for 25 percent with no stated return, no duration and no exit condition sounds like a tax. A proposal with a number attached, a review date and a reversal condition sounds like an investment.

The failure mode is moral framing: quality matters, we should do it properly, we're accumulating debt. All true, all unpersuasive to someone whose quarter is measured in shipped features.

The core reframe

You are not asking for capacity. You are pointing out that you are already spending it, invisibly and at a worse exchange rate.

Unplanned work is capacity. Incident response is capacity. Rollbacks are capacity. The difference between planned reliability work and unplanned incident work is not whether you spend it, it is whether you chose to, whether it happens at 2pm or 2am, and whether it compounds.

That reframe is the whole argument and it should be the first thing you say, because it converts "give me 25 percent" into "here is where 18 percent is already going, and I can convert it into 8 percent".

The evidence to bring

Do this before the meeting. An hour of data collection is worth more than any amount of rhetoric.

1. The current unplanned-work rate. From the incident tracker and the sprint board: how many engineer-hours went to unplanned work last quarter, as a percentage of capacity. This is the single most powerful number and almost nobody brings it.

Q3: 340 engineer-hours on incidents and unplanned fixes
    = 18% of team capacity (8 engineers x 65 working days x 6h)
    Of which: 60% deploy-related, 25% capacity/scaling, 15% dependency failures

2. The trend. One quarter is an anecdote. Three quarters showing 11 percent, 14 percent, 18 percent is a trajectory, and a trajectory forecasts.

3. The delivery cost. Interruptions do not cost only their own hours. A paged engineer loses the rest of the day, and a team with unpredictable interrupts cannot commit reliably. If your on-time delivery rate has fallen alongside the incident rate, that correlation is the VP's problem, not yours.

4. The revenue or cost number, if you can get it. Ask finance or the product analytics team: what is an hour of degraded checkout worth? You often do not need precision. "Our checkout does roughly £180k an hour at peak, and we had 4.2 hours of degradation last quarter" is enough.

5. The comparison, carefully. DORA's research links change failure rate and recovery time to organisational performance, and the 2024 and later reports flag that AI-assisted development is raising throughput while degrading stability. Use it as context, not as proof: "the industry pattern is that throughput gains without a quality guardrail show up as change failure rate, which is what we are seeing" is defensible. "DORA says we need this" is not.

The pitch

Six sentences. Written down, rehearsed, under two minutes.

"We're spending 18 percent of the team's capacity on unplanned work right now, and it's been climbing for three quarters: 11, 14, 18. Sixty percent of it traces to deploy failures, which we don't catch because we have no automated rollback. I want to spend 25 percent for one quarter on three specific things: automated canary analysis with rollback, load-test gates in CI, and fixing the two dependency timeouts that caused four incidents. My expectation is that unplanned work drops below 8 percent, which gives us back roughly 10 percent of capacity permanently, and we'd review at the end of the quarter. If the number hasn't moved, I'd want us to stop and rethink rather than keep spending."

Every element is doing work:

• Opens with a number, not a concern.
• Shows a trend, so it forecasts rather than describes.
• Attributes the cause, so it is not a vague plea for time.
• Names three specific things, so it is a plan not a budget line.
• States the expected return, so it is an investment with a hypothesis.
• Bounds it to a quarter with a review, so it is reversible.
• Offers to stop, which is the sentence that makes it credible.

That last one is counter-intuitive and it is the most important. A leader who says "and if it does not work we should stop" is a leader who will be believed the next time, because they have shown they are running an experiment rather than defending a position.

Translating into their language

The right-hand column is not spin. It is the same fact stated in the unit the listener manages.

Handling the pushback

"Can we do it after the launch?" Sometimes yes, and saying so builds credit. When no: "Two of the three items are launch prerequisites. The launch roughly triples traffic on the checkout path, and that path is where our capacity incidents already come from. I'd rather do the load-test gate before the launch than discover the limit during it." Tie the work to their goal rather than opposing it.

"25 percent is too much. Can you do it with 10?" Never refuse a smaller number outright; scope it and price it. "Yes, with 10 percent I'd do the canary and rollback work, which is the biggest single cause. That should take unplanned work from 18 to about 12. The load-test gate and the dependency timeouts would wait, and I'd expect the capacity incidents to continue at their current rate. If that's the trade you want, I'm fine with it, and I'd want to revisit after the launch." This is the strongest move in the conversation: you have accepted their constraint, priced it honestly, and put the consequence on the record without being obstructive.

"Why did this happen? Shouldn't it have been built properly?" Do not get defensive and do not blame predecessors. "Some of it was the right call at the time; we optimised for shipping and that was correct at the scale we had. What has changed is traffic and team size, and the practices that worked at 200 requests per second do not at 2,000. This is the cost of having been right earlier."

"How do I know this won't be a permanent 25 percent?" "Because I'm proposing a specific list, a number to hit, and a date to review. And separately I'd propose a standing split (say 60 percent features, 25 percent reliability and debt, 15 percent keep-the-lights-on) so this stops being a negotiation every quarter and becomes a budget we can both plan against." Offering the standing split is the move that turns a one-off ask into a durable operating agreement.

"The team should just be more careful." "Care doesn't scale and it isn't measurable. Sixty percent of our incidents are deploy failures we catch by hand after users notice. Automated canary analysis catches them in five minutes without anyone being careful, and it works at 3am." Systems over exhortation, stated plainly.

The strongest single tool: the error budget policy

If you can get this agreed, you never have this argument again.

An error budget policy is a pre-agreed rule: when the service is meeting its SLO, the team ships features at full speed; when the budget is exhausted, feature work pauses and the team works reliability until it recovers.

The property that makes it powerful is that it is negotiated in advance, in the calm, and then applied automatically. You are not asking for reliability capacity during an incident when the VP is annoyed; you agreed months earlier what would happen, and now you are both following a rule.

"I'd rather not have this conversation every quarter. Can we agree an error budget policy? We set an availability target together, say 99.9 percent, which is 43 minutes a month, and while we're inside it, the team ships at full speed and you never hear from me about reliability. When we blow through it, feature work pauses until we're back inside. That way the tradeoff is a rule we both signed rather than an argument we have when something is on fire."

The thing to say next, because it is the part that fails: the policy only works if leadership signs it before the budget runs out. Everyone agrees in principle and defects in practice, and the moment of truth is the first time the budget is exhausted during a launch quarter. Naming that up front, and asking for the commitment explicitly, is what separates a real policy from a slide.

What you must not do

Do not catastrophise. "We're going to have a major outage" is unfalsifiable and reads as manipulation. If you say it and no outage comes, you have spent your credibility; if it comes, you look like you knew and did not act.

Do not present it as a moral issue. "We should do this properly" invites the response "we should also ship", and neither side has an argument.

Do not hide the cost. If 25 percent means two features slip, say which two. Being the person who names the cost of their own proposal is worth more than the proposal.

Do not ask without a return. Any capacity request without a hypothesis about what improves is a tax, and taxes get cut.

A worked example: what happened next

A team ran this pitch and got 15 percent rather than 25, plus agreement to revisit.

They spent it on the single largest cause: automated canary analysis with rollback on the deploy pipeline. Six weeks of work for two engineers.

Result at the quarter review: unplanned work fell from 18 percent to 11 percent. Change failure rate fell from 22 percent to 9 percent. Mean time to recovery fell from 55 minutes to 8, because rollback became automatic rather than a human noticing.

The conversation at the review changed completely. They were no longer asking for capacity; they were reporting a return and proposing the next investment with a track record behind it. The VP approved the remaining items without much discussion, because the first tranche had produced a number.

The lesson worth generalising: take the smaller number, pick the highest-return item, deliver a measurable result, and come back. Insisting on the full 25 percent up front risks getting zero and having no evidence. Fifteen percent with a result beats 25 percent with an argument.

Production evidence

Google's SRE practice is the origin of the error budget policy, and the SRE book's framing is the one to borrow: the budget makes the reliability-versus-velocity tradeoff explicit and removes the need to argue it case by case. The workbook is blunt that the policy must be agreed by leadership in advance, and that a policy without that agreement is theatre.

DORA's research programme, published annually, links change failure rate and failed-deployment recovery time to organisational performance, which is the closest thing to industry-wide evidence that reliability and delivery speed are complements rather than opposites. Recent reports flag that AI-assisted development is raising throughput while degrading stability, which is directly usable context for this argument.

Nicole Forsgren, Jez Humble and Gene Kim's Accelerate is the book form of that research and the one a VP is most likely to have read, which makes it a useful shared reference rather than an appeal to authority.

The three-bucket budget (features, reliability and debt, keep-the-lights-on) with a published split is common practice across engineering organisations. The value is not the specific ratio, it is that publishing a split converts a recurring negotiation into a standing agreement.

The debate

The credible counter-argument, and you should be able to make it: a company that over-invests in reliability before finding product-market fit dies of irrelevance. For an early-stage product, an hour of downtime costs almost nothing and a missed market window costs everything. Reliability investment has a correct level and it is not "maximum".

The honest position is that the right level depends on what failure costs, and that varies by orders of magnitude across products and across the same product over time. A payments ledger and an internal dashboard should not have the same posture.

My position: make the argument in the unit the listener manages, price it, bound it, and offer to stop if it does not work. Take a smaller number and deliver a result rather than winning the full ask and having nothing to show. And push for an error budget policy, because the durable win is not this quarter's capacity, it is never having to make this argument again.

Making this case is the wrong move when the team's reliability problems are actually a scope or estimation problem in disguise, when the organisation is in a genuine survival moment where the roadmap is existential, or when you have made the same ask twice and not delivered on either. In the last case, deliver something small with your existing capacity first and come back with evidence.

Follow-up Q&A

"Make the case for 25 percent reliability investment to a product-focused VP." Open with the number, not the concern: we are already spending 18 percent on unplanned work and it has climbed for three quarters. Attribute it: 60 percent is deploy failures. Propose three specific items, state the expected return (unplanned work below 8 percent, so a net gain of about 10 percent capacity), bound it to a quarter with a review, and say explicitly that if the number does not move we should stop. The reframe underneath is that this is not new capacity, it is converting invisible expensive capacity into visible cheap capacity.

"They cut you to 10 percent. What do you do?" Accept it, scope it honestly, and put the consequence on the record without being obstructive: "with 10 percent I'd do the canary and rollback work, which should take unplanned work from 18 to about 12; the capacity incidents would continue and I'd want to revisit after the launch." Then deliver a measurable result, because 10 percent with a number beats 25 percent with an argument, and the second conversation is far easier when you have a track record.

"How do you avoid having this argument every quarter?" An error budget policy agreed in advance, plus a published three-bucket split. The policy turns the tradeoff into a rule both parties signed rather than a negotiation during an incident. The critical detail is that it must be agreed before the budget is exhausted, and the first time it binds during a launch quarter is when you find out whether it was real. Ask for that commitment explicitly rather than assuming it.

"What if the VP is right and the roadmap genuinely can't slip?" Then they are right, and saying so is worth more than the argument. Agree the roadmap, name which reliability risks we are accepting and what they would cost if they land, and put a date on revisiting. What I would push for is the smallest item with the highest return, usually automated rollback, because it converts long incidents into short ones for a few weeks of work, and I would ask for it on the grounds that it protects the launch rather than competing with it.

"How do you measure whether it worked?" The same numbers I opened with, so the comparison is like for like: unplanned work as a percentage of capacity, change failure rate, mean time to recovery, and pages per person per week. I would set the baseline before starting and report at the review whether or not it is flattering, because reporting a disappointing number honestly is what makes the next ask credible.

Common misconceptions

The biggest is that this is a persuasion problem. It is a measurement problem: the team that can state its unplanned-work percentage and its trend rarely has to persuade anyone, and the team that cannot will not win the argument however well they make it.

The second is that you should ask for what you need. Ask for what you can justify with evidence and deliver against, then come back. Credibility compounds; a large unfunded ask does not.

The third is that reliability and velocity are opposites. The DORA research is fairly consistent that high performers are better at both, because the practices that make deployment safe (automated testing, small changes, fast rollback) also make it fast. Framing it as a tradeoff concedes ground you do not need to concede.

Interview delivery note

Say this, and say the reframe first: "I wouldn't open by asking for capacity. I'd open by showing that we're already spending it: 18 percent of the team's time went to unplanned work last quarter, up from 11 two quarters ago, and 60 percent of it is deploy failures. Then I'd propose three specific fixes, state the return I expect (unplanned work under 8 percent, so a net gain of about 10 percent), bound it to one quarter with a review, and say that if the number hasn't moved we should stop rather than keep spending."

Then the two moves that make it a lead-level answer. Offering to stop, because it converts a request into an experiment and makes you credible. And the error budget policy: "and separately I'd push for an error budget policy, so this stops being a quarterly negotiation. The catch is that leadership has to sign it before the budget runs out, not during the incident, and I'd ask for that explicitly."

The depth signal is accepting the smaller number gracefully and pricing the consequence. Candidates who argue harder for the full ask sound like advocates; candidates who say "yes, and here is what we would not get" sound like people who have run a team.

Further reading

• Google, The Site Reliability Workbook, chapter 4, on error budget policies and the requirement that leadership pre-commit.
• Forsgren, Humble and Kim, Accelerate, and the annual DORA State of DevOps reports, for the delivery-and-stability relationship and the recent AI-era caveat.
• Google, Site Reliability Engineering, chapter 3, on the reliability-velocity tradeoff as an explicit budget rather than an argument.
• Will Larson, An Elegant Puzzle, on capacity allocation and making organisational investments legible to leadership.

The engineer who has missed three commitments

"An engineer has missed three commitments in a row. Run the conversation."

What the question is actually testing

Three things, and none of them is whether you are willing to have a hard conversation.

1. Whether you diagnose before you correct. "Missed three commitments" is a symptom with at least six causes, and the right response differs completely between them. A candidate who goes straight to a performance conversation has skipped the only step that matters.
2. Whether you have been the cause. Unclear requirements, shifting priorities, an unrealistic estimate you accepted, or an interrupt load you allowed are all management failures presenting as an individual one.
3. Whether you can be specific and kind at the same time. Vagueness here is the cruellest thing a lead does, because it denies someone the information they need to fix it.

The structure to announce, as with every role-play: first move, information I would gather, line I would not cross.

The answer

First move: gather before you talk

Do not open the conversation until you can describe the three misses concretely. Spend an hour on:

• The three commitments. What was promised, by when, what was delivered, and how late. If you cannot state this precisely, you are about to have a conversation about a feeling.
• The estimates. Who produced them? If you or a PM set the date and they accepted it, this is a different conversation entirely.
• Interrupt load. What fraction of those sprints went to on-call, support, reviews, or helping others? Look at the actual data, not the impression.
• Dependencies. Were they blocked, and for how long, and did anyone unblock them?
• The pattern. All three the same kind of work? All three involving the same unfamiliar system? Estimation error, or execution?
• Anything else in the picture. Recent role change, a reorg, a new manager, something visible going on in their life.

Then check your own contribution honestly, because in my experience it is present more often than not: did priorities change mid-sprint, was the scope stable, did they have what they needed, and did they raise a risk that I did not act on?

The conversation

Private, scheduled with enough time, not tacked onto a 1:1 agenda alongside six other items. Open with observation rather than judgement, and then stop talking.

"I want to talk about the last three sprints. The payment retry work was committed for the 8th and landed on the 22nd; the webhook migration was committed for the 19th and is still open; the search fix slipped two sprints. I'm not here to tell you off. I want to understand what's happening, because from where I sit I can't tell whether this is estimation, blockers, priorities, or something else, and the answer changes what I do."

Three properties of that opening are deliberate. It is specific (dates and items, not "you've been missing things"). It is non-accusatory but not soft (the facts are stated plainly). And it ends with a question, which is what makes the next five minutes theirs.

Then listen properly. The answer usually falls into one of six buckets, and the response is different for each:

Note that two of the six are your failures, and in practice they are two of the most common. That is the point of diagnosing first.

Closing the conversation

Whatever the cause, end with the same four things, and put them in writing the same day:

1. A shared statement of what is happening, in their words as much as yours.
2. One specific change from them, small enough to be achievable: "flag anything at risk by Wednesday, not at sprint end."
3. One specific change from you, because there almost always is one: "I'll keep you off the support rotation for the next two sprints."
4. A check-in date, close enough to be real. Two weeks, not "let's see how the quarter goes."

"So: you'll raise anything at risk by Wednesday midweek rather than waiting for the review, and we'll estimate the next two pieces together so I can see where the gap is. I'll take you off support for two sprints and I'll go to the platform team myself about the queue dependency. Let's look at it again in two weeks. Does that match what you heard?"

That last question is not politeness. Misremembered agreements are how these conversations fail, and the written follow-up is what makes "no surprises" possible later.

If it is a performance problem

If the diagnosis is capability or effort rather than circumstance, the sequence is:

Name the gap early and explicitly. Not "we'd like to see more ownership" but "the last three pieces of work needed the design reworked in review; at your level I need designs that hold up."

Put expectations in writing, with what good looks like and by when.

Provide support, so that the plan is a plan rather than a countdown: pairing, a mentor, scoped work that builds the missing skill, more frequent check-ins.

Review on the stated date, and decide. Extending indefinitely is a failure of nerve that helps nobody, least of all the person, who is spending their career on a role that is not working.

The rule that governs all of it: no surprises at review time. If someone is surprised by their performance rating, that is a management failure, not theirs. The formal process should be a summary of conversations already had, never the first one.

And involve HR early rather than late, both because the documentation matters and because a performance conversation that becomes a legal one without warning is bad for everybody.

Where this goes wrong

Skipping the diagnosis. Going straight to a performance conversation when the cause was interrupt load damages a good engineer and leaves the actual problem in place. It is the most common failure in this scenario.

Softening it into nothing. "How's it going? Anything I can do?" is not a conversation about missed commitments. They will leave not knowing there was a problem, and the next conversation will be a much worse surprise.

Making it about the dates. The three misses are evidence, not the subject. The subject is what is causing them, and a conversation that stays on the dates produces better date-hitting behaviour like padded estimates rather than better outcomes.

Not naming your own contribution. If priorities shifted three times and you say nothing about it, you have taught them that the story is one-sided, and you will not get honest information from them again.

Waiting. Three misses is already late. The conversation belonged after the first, as a small, low-stakes check rather than a serious one.

Letting it be verbal only. Without a written summary, six weeks later you and they remember different agreements, and there is no basis for the next conversation.

Interviewer follow-ups

"They say the estimates were never realistic and they told you so." Then I check, because they may well be right, and if they are I say so plainly: "you did flag it and I didn't adjust, that's on me." Then we separate the two problems. Mine is that I accepted a date I had been told was unrealistic. Theirs, if it exists, is whether they raised it once in passing or escalated it clearly enough that it could not be missed. Both can be true, and conceding my half is what makes it possible to talk about theirs.

"They get defensive and say everyone else misses commitments too." I decline the comparison and stay on specifics: "I'm not comparing you to anyone. I'm talking about these three pieces of work and what would help." If the underlying claim is that the team's commitments are generally unrealistic, that is worth investigating separately and I would say so, and then look at it, because if they are right it is a planning problem and I should fix it rather than have six versions of this conversation.

"It turns out something personal is going on." Stop the performance conversation. Switch to support: what do they need, what can be reduced, does HR or an employee assistance programme have something useful, do they need leave. Adjust expectations explicitly and temporarily, with a date to revisit rather than an open-ended suspension. Keep it confidential from the team while being clear with the team that priorities have shifted. Restart the performance conversation only if the pattern persists after the circumstance resolves.

"What if they're a strong engineer whose estimates are just optimistic?" Then it is a calibration problem and it is very fixable. Break work into pieces small enough that a bad estimate costs days rather than sprints, estimate together for a few cycles so I can see where the gap opens, and shift from single-point estimates to ranges or confidence levels. Optimistic estimation is extremely common in good engineers, because they estimate the happy path, and it responds well to structure rather than to exhortation.

"How do you avoid this happening in the first place?" Shorten the feedback loop so a miss is visible in days rather than at sprint end: work broken down so nothing is larger than a week, a mid-sprint check that asks explicitly what is at risk, and a norm that raising a slip early is rewarded rather than punished. That last one is mine to establish, and it is the highest-leverage of the three, because the expensive version of this problem is the one where someone knew two weeks ago and did not feel able to say.

Production evidence

Camille Fournier's The Manager's Path treats the diagnose-before-you-correct sequence and the no-surprises rule as core practice, and is the most likely shared reference with an interviewer for this scenario.

The SBI model (Situation, Behaviour, Impact), from the Center for Creative Leadership, is the standard structure for the feedback itself: describe the specific situation, the observable behaviour, and its effect, rather than characterising the person.

Google's re:Work research on psychological safety is the evidence base for the fifth row of that diagnosis table: on teams where people do not feel safe raising bad news, slips are hidden until they are unrecoverable, and that is a property of the team's environment rather than of the individual.

Andy Grove's High Output Management supplies the underlying distinction that makes the diagnosis table work: underperformance is either a matter of capability or of motivation, and the interventions are entirely different, so guessing wrong wastes the intervention.

Interview delivery note

Open with the structure and then, critically, with the diagnosis: "First move, information I'd gather, line I wouldn't cross. And my first move isn't the conversation, it's an hour of preparation, because 'missed three commitments' is a symptom with about six causes and at least two of them are mine."

Then the conversation itself: "I'd open with the specifics, dates and items rather than 'you've been missing things', say plainly that I'm trying to understand rather than to tell them off, and then stop talking. The answer usually tells me whether it's interrupt load, estimation, blockers, a capability gap, or that they didn't feel able to say it was slipping. The last one is about me, not them."

Close with the line and the rule: "The line I wouldn't cross is vagueness. Being unspecific here is the cruellest thing a lead does, because it denies someone the information they need to fix it. And whatever the cause, it ends with one change from them, one change from me, a check-in date, and a written summary the same day, because no surprises at review time is the rule and that only works if the conversations happened."

The depth signal is naming that two of the six causes are management failures and volunteering to check your own contribution first. Most candidates run this as a conversation about the engineer.

Further reading

• Camille Fournier, The Manager's Path, on feedback, performance conversations and the no-surprises principle.
• Andy Grove, High Output Management, on the capability-versus-motivation diagnosis and task-relevant maturity.
• The Center for Creative Leadership's SBI feedback model.
• Google re:Work's material on psychological safety, for why hidden slips are an environment property.

The director who wants a date you cannot commit to

"Your director wants a date you can't commit to. Respond."

What the question is actually testing

Not whether you will push back. Three things:

1. Whether you treat a date as a negotiation about scope and confidence, rather than a yes or no. "No" and "yes" are both bad answers; the good answer changes the shape of the question.
2. Whether you can quantify uncertainty. "It might take longer" is a feeling. "Historically work like this has taken 6 to 11 weeks, so I'd give you 60 percent confidence on the 15th and 90 percent on the 29th" is an engineering statement.
3. Whether you understand what the director is actually solving for. A date is almost never the goal; it is a proxy for a customer commitment, a board meeting, a contract, or a dependency. Find the real constraint and you often find a better answer than the one being demanded.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: find out what the date is for

Do not answer the date question until you know what it is serving. The question is not confrontational if you ask it with genuine curiosity:

"Before I answer, help me understand what the 15th is anchored to. Is that a customer commitment, a contract date, a conference, or is it a stretch target? It changes what I'd propose."

The answers lead to completely different responses:

That last row matters more than people expect. A director who states a date and gets immediate agreement learns nothing about the team's capacity, and a lead who agrees to dates they cannot hit becomes someone whose estimates are worthless within two quarters.

Then: supply options with costs, never a refusal

The move that changes the conversation is replacing a yes-or-no with a menu.

"I can't commit to the full scope on the 15th, and I don't want to give you a date I don't believe, because then you'd plan on it. Here are three things I can commit to.

One: the full scope, and my honest forecast is 60 percent confidence on the 29th, 90 percent on the 12th of next month.

Two: the 15th, with the bulk import and the admin UI cut. That's the core flow working end to end for a single user. I'd want to check with you whether that's enough for what the date is serving.

Three: the 15th with full scope, if I get two engineers from platform for three weeks. I'd put that at 70 percent, because onboarding cost eats some of the gain, and I'd want to be honest that it slows platform's roadmap.

My recommendation is two, because the pieces I'd cut are the ones our first customers use least, and we can ship them a fortnight later without anyone noticing."

Four properties of that answer, and each is being scored:

• It never says no. It says "here is what is achievable, at what cost".
• It quantifies confidence rather than asserting a single date.
• It names what gets cut, specifically, so the director can evaluate.
• It ends with a recommendation. Presenting three options with no recommendation pushes the decision back to someone with less information, which is an abdication rather than a consultation.

The forecasting that makes it credible

The reason the confidence numbers are not made up:

Historical cycle time for work of this shape (last 18 comparable items):
  p50   6.5 weeks
  p75   8   weeks
  p90  11   weeks

We are 1 week in. Remaining scope is comparable to those 18 items.
  60% confidence -> ~the 29th
  90% confidence -> ~the 12th

Capacity check:
  6 engineers x 25 working days = 150 person-days
  minus on-call (15), interviews (8), support rotation (12), meetings (20)
  = 95 effective person-days, and I commit to 65-70% of that = ~65

Two habits here are what make a lead sound senior. Forecast with percentiles from historical cycle time rather than with story points, because points measure imagined effort and cycle time measures reality. And commit to 60 to 70 percent of theoretical capacity, because teams that commit to 100 percent miss every single time, and the gap is on-call, interviews, support and meetings that were always going to happen.

If the director pushes anyway

"I hear you, and I want to be clear about what I'm agreeing to. If we commit to the 15th with full scope, my honest estimate is that we hit it about one time in four. If we're going to take that bet, I'd want to plan for the other three outcomes now rather than in week three: what we tell the customer if we slip, and which pieces we drop first. I'd rather agree that today than improvise it under pressure."

That is the disagree-and-commit move done properly. You have not refused; you have made the risk explicit, put it on the record, and pre-agreed the contingency. If it slips, nobody is surprised and there is already a plan.

And then, importantly, commit genuinely. Dissent recorded, decision made, full effort behind it. A lead who visibly executes half-heartedly on a decision they lost is worse than one who never objected.

Then: write it down

Same day, short, to the director and anyone downstream:

"Confirming: we're targeting the 15th with the bulk import and admin UI out of scope, shipping those by the 29th. My confidence on the 15th for the reduced scope is about 85 percent. Risks: the payments integration is the long pole and depends on their sandbox being available by the 8th. I'll flag by the 8th if that slips."

Verbal commitments become different memories within two weeks. The written version is also what makes a later slip a known risk materialising rather than a surprise.

Where this goes wrong

Saying no. "We can't do that" is accurate and useless. It gives the director nothing to work with and positions engineering as an obstacle rather than a partner.

Saying yes and hoping. The worst option, and the most common. It buys three weeks of calm and spends all your credibility, because a lead whose dates are unreliable stops being consulted about dates at all.

Padding silently. Quoting the 90th percentile as if it were the estimate. Directors work out that your dates are padded and start discounting them, so you pad more, and now nobody knows anything.

Options without a recommendation. Handing over three choices and no opinion looks like collaboration and is abdication. You have the most information; use it.

Making it about the team's feelings. "The team will burn out" may be true and it is the weakest available argument, because it is unfalsifiable and it sounds like special pleading. "We hit this date one time in four" is the same concern expressed as a fact.

Not asking what the date is for. The single most common miss, and the one that most often unlocks a better answer than either party started with.

Interviewer follow-ups

"The director says the date is non-negotiable and so is the scope." Then I say plainly what that means and what I need. "Then we're committing to something I estimate at 25 percent. I'll run it that way, and here's what I need: a decision now on what we drop if we're behind at the halfway point, and the two platform engineers, because that's the only lever left. If neither is available, I want it on record that we're taking a bet, and I'd like us to agree today what we tell the customer if it doesn't land." Then I execute properly, because a recorded objection followed by half-hearted delivery is the worst of both.

"How do you know your estimate is right?" I do not, which is why I give a distribution rather than a date. The distribution comes from the last 18 comparable items' actual cycle time, so it already includes the interruptions, the unknowns and the estimation optimism that individual estimates always omit. It will still be wrong sometimes, which is what the 60 and 90 percent numbers are honestly saying, and I would rather be transparently uncertain than confidently wrong.

"Your team says the reduced scope is still not achievable." Then I have a problem I created by committing without checking, and I fix it immediately rather than defending the commitment. I go back with the same structure one level down: what is the largest thing we can commit to, what confidence, what would change it. Then I go back to the director the same day, because a correction on day three costs a conversation and a correction on day twenty costs the relationship.

"What if you're wrong and the team could have hit it?" Then I have been too conservative, and that is a real cost: it makes the team look slower than it is and it costs the business optionality. The fix is to track forecast accuracy over time, so I find out whether I am systematically pessimistic. If my 60 percent forecasts hit 90 percent of the time, my model is wrong and I should say so and recalibrate rather than enjoying the easy wins.

"How do you avoid being in this position?" Forecast continuously rather than at commitment time. If the director sees a burn-up chart with a confidence band every week, the date conversation happens early and gradually rather than as a single confrontation. Also: never let a date be set without engineering in the room, and if that is happening, that is the actual problem and it is worth raising directly with the director as a process issue rather than fighting it one date at a time.

Production evidence

Troy Magennis's and Daniel Vacanti's work on probabilistic forecasting is the basis for forecasting from historical cycle-time distributions rather than from estimates, and for expressing commitments as confidence levels. Vacanti's Actionable Agile Metrics for Predictability is the practical reference.

Amazon's "disagree and commit" leadership principle is the canonical framing for the escalation path: dissent is expressed clearly and recorded, the decision is made, and commitment afterwards is genuine rather than performative.

The DORA research on batch size and lead time supports the scope-reduction option structurally: smaller scope ships sooner and more predictably, so cutting scope is not merely a concession, it improves the forecast.

Will Larson's An Elegant Puzzle covers the capacity-commitment arithmetic and the practice of publishing a percentage of theoretical capacity, which is what makes the 60 to 70 percent figure defensible rather than arbitrary.

Interview delivery note

Open with the structure, then with the question nobody asks: "First move, information I'd gather, line I wouldn't cross. And my first move isn't to answer the date question, it's to ask what the date is anchored to. A contractual deadline and a stretch target need completely different responses, and quite often the real constraint has a better answer than either of us started with."

Then the menu: "Then I'd give options with costs rather than a yes or no. Full scope at 60 percent confidence on the 29th and 90 percent on the 12th. Or the 15th with the bulk import and admin UI cut. Or the 15th with two borrowed engineers, at 70 percent. And I'd recommend one, because handing over three options with no opinion is abdication, not collaboration."

The depth signal is where the numbers come from: "the confidence levels come from the actual cycle time of the last eighteen comparable items, not from story points, because points measure imagined effort and cycle time measures what happened. And I'd commit to about 65 percent of theoretical capacity, because the rest is on-call, interviews and support that were always going to happen."

Close with the line: "The line I wouldn't cross is giving a date I don't believe. Not because it's dishonest, though it is, but because they'd plan on it, and the cost lands on people downstream who had no way to know."

Further reading

• Daniel Vacanti, Actionable Agile Metrics for Predictability, and Troy Magennis's forecasting material, for cycle-time distributions and probabilistic commitments.
• Will Larson, An Elegant Puzzle, on capacity, commitment ratios and making engineering constraints legible to leadership.
• The DORA State of DevOps reports on batch size, for why cutting scope improves predictability rather than merely reducing content.
• Amazon's leadership principles on disagree and commit, for the escalation and commitment pattern.

Two teams building the same service

"Two teams are building the same thing. Neither wants to stop. You have no authority over either."

What the question is actually testing

This is the canonical staff-level influence question, and it is testing whether you can operate without positional power. Specifically:

1. Whether you check the premise. "The same thing" is usually an oversimplification. Two services that look identical from outside often solve genuinely different problems, and a staff engineer who forces a merge without checking has destroyed value.
2. Whether you make the cost visible rather than arguing about correctness. Nobody changes course because you were right. They change course when the cost of not changing becomes legible to the person who pays it.
3. Whether you find the decision-maker. With no authority, your job is not to decide, it is to get the decision made by someone who can, with good information.
4. Whether you can lose gracefully. If the decision goes against your recommendation, what you do next is being scored more than your argument was.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: verify the duplication is real

Before proposing anything, read both. Two hours, not two weeks:

• What does each actually do? Not the README, the code and the API surface.
• Who consumes each, and how much traffic?
• What was each built for? There is usually a reason, and it is usually a real constraint that one team had and the other did not.
• Where do they genuinely differ? Latency profile, consistency guarantees, deployment model, data residency, tenancy.
• What would it cost to consolidate, honestly, including migration and the features one has that the other does not?

The outcome is one of three, and they need completely different responses:

The third outcome happens more often than the framing of the question suggests, and being the person who says "actually these are different, here is why" is worth more to your reputation than winning a consolidation.

Then: make the cost visible, in the currency that matters

Arguing "duplication is bad" is arguing about aesthetics, and aesthetics do not move roadmaps. Quantify:

Direct cost
  2 teams x 1.5 engineers of ongoing maintenance = 3 engineers/year
  Infrastructure: two clusters, two pipelines, two on-call rotations

Consumer cost (the one nobody counts, and the one that lands)
  7 downstream teams currently integrate with one or the other
  4 of them have integrated with BOTH, because different features
  Every new consumer must ask which to use; nobody has a good answer

Divergence cost
  Two implementations of the same business rule. They already disagree
  on how partial refunds are handled, which is a live correctness bug
  nobody owns.

Opportunity cost
  The 3 engineers/year is the whole cost of the thing the director said
  last quarter we did not have capacity for.

That last line is the move. Translate the duplication into something the decision-maker already said they wanted, so consolidating becomes the way to get the thing they care about rather than a tidiness project.

The divergence bug is the second-strongest item, because it converts an abstract inefficiency into a specific correctness problem with a customer impact.

Then: find the person who can decide, and give them a decision

With no authority, your leverage is framing the decision for someone who has it. That is usually the lowest common manager of both teams.

Do not walk in with "team A should stop". Walk in with a written document:

The situation. Teams A and B both operate a notifications service. Seven downstream teams consume one or both; four consume both.

The cost. Roughly 3 engineer-years annually in duplicated maintenance, plus a live correctness divergence on partial refunds, plus every new consumer paying an integration decision tax.

The options.

1. Consolidate on A. A has the better delivery guarantees; B has templating that A lacks. Roughly 6 weeks to port templating, 2 quarters to migrate B's 3 consumers.
2. Consolidate on B. B has better ergonomics; A has the throughput. Porting throughput work is roughly a quarter and carries more risk.
3. Extract the common core as a shared library, keep both services. Cheapest, and it does not fix the consumer confusion or the on-call duplication.
4. Do nothing. Costs stated above, ongoing and rising.

Recommendation. Option 1, with A's team owning templating delivery and B's team owning migration of its consumers, so both teams have work rather than one being told to stop.

What I need from you. A decision by the 20th, and a statement to both teams that it is decided, so this stops being a debate.

Four properties. It is written, so it can be circulated and cannot be misremembered. It gives real options rather than one dressed as four. It names what each team keeps, because "your work is being deleted" is why people fight. And it asks for one specific thing: a decision and an announcement.

DACI is the vocabulary to offer if asked how to run it: one Driver (me), one Approver (the shared manager), Contributors (both tech leads), Informed (the seven consumers). The value is the single named approver, because decisions requiring committee agreement do not get made.

Talk to both teams before the decision, not after

Take both tech leads for a coffee separately, before writing the document, and be straight about what you are doing:

"I think we're paying for two of these and I'm going to write it up for [manager]. Before I do, I want to make sure I've got your side right, and I want to know what you'd need for a consolidation to be acceptable to you. I'd rather your position was in the document accurately than have you read it and disagree with my summary."

Two effects. The document becomes accurate, which makes it more persuasive. And neither team is ambushed, which is what turns a technical disagreement into a political one. A staff engineer who surprises people with documents stops being included in things.

Give the losing team something

The single most useful move in the whole scenario. The team whose service is retired has spent a year on it and is being told it was wasted. Fix that explicitly:

• They own the migration, so they are doing work rather than being done to.
• Their distinctive features get ported, and they specify them.
• Their tech lead is named in the decision as a contributor, and the announcement says so.
• The retirement is framed as a consolidation both teams achieved, not as one team winning.

None of this is manipulation; it is accurate. Their work informed the outcome, and saying so is both true and what makes the consolidation actually happen rather than being nominally agreed and quietly ignored.

Where this goes wrong

Skipping the verification. Forcing a merge of two things that only look similar destroys value, and your credibility with it.

Arguing correctness instead of cost. "This is duplicated" is a statement nobody disputes and nobody acts on. Three engineer-years, a live correctness bug, and seven confused consumers is a statement people act on.

Trying to decide it yourself. With no authority, attempting to adjudicate makes you a participant in the conflict rather than the person resolving it. Your job is to make the decision easy for someone who can make it.

Going to the manager first. Both teams hear about it second-hand, conclude you went over their heads, and now it is political. Talk to the leads first, always.

Winning and then leaving. A decision without a migration plan, an owner and a deadline decays. Six months later both services are still running and the decision is folklore.

Not letting it go. If the decision goes the other way, the correct response is to support it visibly. Re-litigating a decided question is the fastest way to stop being consulted, and you will need the credibility for the next one.

Interviewer follow-ups

"The manager says 'you two figure it out'." That is a refusal to decide dressed as delegation, and it will not resolve, because neither team can concede without looking like they lost. I would go back once, in writing, with the cost quantified and a specific ask: "Both leads have made their case and neither can unilaterally concede. I need a decision from you by the 20th; here's my recommendation and here's what happens if we don't decide." Naming the cost of indecision is the lever. If they still will not decide, I would take option 3, extract the shared core as a library, because it captures some of the value without requiring authority nobody is willing to exercise, and I would document that we chose the second-best option because the decision was not made.

"One team has a director who will fight for them." Then it is a political problem and the technical argument alone will not win it. Two moves. Make the cost visible to the director's peer, so the conversation happens between people who can actually trade. And find the option where their team wins something real: they own the consolidated service, or their features are the ones that survive. Most of these fights are about status rather than technology, and an outcome where nobody is publicly diminished is achievable much more often than it looks.

"You're wrong and consolidation is a bad idea." Then I want to find that out in the verification step rather than after the migration starts, which is why it comes first. If I find it during, I say so publicly and quickly: "I pushed for this and I was wrong about X; here's what I missed." Being the person who reverses their own recommendation with evidence is worth more than being right the first time, and it is the behaviour that makes people trust your next recommendation.

"How do you influence with no authority in general?" Three things, in order. Information: be the person who has actually read both systems and can quantify the cost, because the person with the best data usually gets their way regardless of title. Framing: convert the technical issue into the currency the decision-maker manages, usually capacity, risk or customer impact. And relationships built before you needed them, because influence is mostly the accumulated willingness of people to take your call. None of that works if you have spent your credit on being right about small things.

"What if both teams agree but nothing happens?" That is the most common outcome and it is a planning failure rather than an agreement failure. Consolidation loses to whatever is on the roadmap every sprint, because it has no customer asking for it. The fix is that it needs an owner, a date and a place on someone's roadmap, plus a visible metric: number of consumers migrated, published monthly. Without that, "we agreed to consolidate" is a sentence people say for two years.

Production evidence

Tanya Reilly's The Staff Engineer's Path treats influence without authority as the defining staff-level skill, and specifically the practice of writing things down so a decision can be made by someone else with good information.

The DACI and RAPID decision frameworks exist precisely for this shape of problem: the value is a single named approver, because decisions requiring consensus among peers with equal standing do not converge.

Amazon's two-way door framing helps size the argument: consolidating two services is closer to a one-way door (the retired service's team disperses, its knowledge decays), so it warrants the written document and an explicit approver rather than an informal agreement.

Conway's law explains why the duplication exists in the first place: two teams with a communication boundary between them will build two systems, and the consolidation is as much an organisational change as a technical one. Which is why the answer involves a manager rather than an architecture review.

Interview delivery note

Open with the structure and with the premise check, because that is the part most candidates skip: "First move, information I'd gather, line I wouldn't cross. And my first move is to verify they're actually the same thing, because 'two teams building the same service' is often two teams solving different problems that look alike from outside. If that's what I find, saying so is the most valuable thing I can do."

Then the influence mechanics: "Assuming it's real, I don't argue that duplication is bad, because nobody disputes that and nobody acts on it. I quantify: three engineer- years of maintenance, seven downstream consumers and four of them integrating with both, and a live correctness divergence on refunds that nobody owns. Then I translate it into whatever the decision-maker already said they wanted capacity for, so consolidating becomes the way to get that."

Then the part that shows you have done it: "I'd talk to both tech leads before writing anything, so neither is ambushed and so the document is accurate. And I'd make sure the team whose service is retired owns the migration and gets its distinctive features ported, because 'your year of work is deleted' is why these things get agreed and then quietly not done."

Close with the line: "The line I wouldn't cross is trying to decide it myself. I have no authority, so my job is to make the decision easy for someone who does, and then support whichever way it goes, including if it goes against me."

Further reading

• Tanya Reilly, The Staff Engineer's Path, on influence without authority and on writing to make decisions possible.
• Will Larson, Staff Engineer, on the archetypes and on operating across organisational boundaries.
• The Atlassian DACI documentation and the RAPID framework, for the single-approver mechanics.
• Melvin Conway, "How Do Committees Invent?" (1968), for why the duplication is an organisational artifact rather than an engineering mistake.

Promotion when they are one level of scope short

"An engineer wants a promotion. They're one level of scope short. Run the conversation."

What the question is actually testing

1. Whether you are specific. Vagueness here is the cruellest thing a lead does, because it leaves someone working hard on the wrong things for another year while believing they are close.
2. Whether you understand that promotion is your job, not theirs. At senior and above, the evidence a packet needs comes from the work someone is assigned. If they have never been given work that generates staff-level evidence, the gap is mine.
3. Whether you can say no without demotivating. The failure modes are symmetric: soft-no that reads as yes, and honest-no delivered as a verdict rather than a plan.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: check whether the gap is real, and whose it is

Before the conversation, an hour with the rubric and their last two years of work:

• Read the next level's rubric line by line and mark where they are: met, partially met, not demonstrated. Not "roughly there"; per line.
• Look for evidence, not impressions. Design documents, incidents led, migrations driven, people mentored with a visible outcome, decisions they made that others followed. Artifacts a calibration room can read.
• Ask whether they have had the opportunity. This is the question that decides whose problem it is. If the gap is cross-team influence and every project they have been given was inside one team, they cannot have demonstrated it, and that is on me.
• Check the calibration bar, not just the rubric. What did the last two people promoted to that level actually do? Rubrics are aspirational; calibration rooms are comparative.
• Talk to their peers and partners before the conversation, so the feedback is the organisation's view rather than only mine.

The outcome is one of three:

The third case is more common than people expect. Someone can be operating at the level and have no artifacts a calibration room can point to, which is a documentation problem rather than a performance one.

The conversation

Private, unhurried, and open with the answer so they are not spending the whole conversation trying to work out what you are about to say.

"I want to be direct, because I don't think being vague about this would be kind. I'm not going to put you up this cycle, and I want to tell you exactly why and exactly what would change it.

Looking at the staff rubric: your technical depth is there, your code and design quality are there, and your mentoring of Priya and Sam is genuinely the evidence that section asks for. What's missing is scope. Everything you've driven in the last eighteen months has been inside our team. Staff needs evidence that you moved something across teams: a decision that other teams adopted, a standard you got three groups to follow, a migration you led that wasn't yours to mandate.

And I want to be honest that some of that is on me. I haven't put you on work that would generate that evidence, because you're the person I rely on for our highest-risk delivery, and that's been convenient for me. So the plan isn't 'go and be more strategic'. The plan is that I give you work where cross-team influence is the job."

Four properties, and each is being scored. It leads with the answer. It is specific against the rubric, naming what is met as well as what is not. It names my contribution, which is almost always present and almost never volunteered. And it converts the gap into an assignment, so they leave with work rather than with an instruction to be different.

Then: the plan, with artifacts and a date

Vague plans are broken promises with extra steps. Write it down:

"Three things over the next two quarters.

One: you lead the authentication migration. It touches four teams, none of which report to us, and the hard part is getting them to agree a sequence. That's exactly the evidence the rubric wants, and I'll back you in the rooms where I need to.

Two: you write and drive the API standards RFC. Not because we need the document, but because getting three teams to adopt it is the thing that's missing.

Three: you present the ranking redesign at the architecture review. Visibility to the people in the calibration room is part of this, and it's the part engineers most often think is unfair. It's not a popularity contest; it's that a room can only promote someone whose work they've seen.

We'll review in March. I'm not promising a promotion in March; I'm promising that if those land, I'll have a packet I can argue for, and I'll tell you honestly in January if I think it isn't tracking."

Three properties. Named work, not qualities. A date. And an explicit statement of what is and is not being promised, because "do these things and you'll be promoted" is a commitment you do not control, and making it is how you lose someone's trust permanently when the calibration room disagrees.

Then: build the packet continuously

Promotions are won two quarters early, by assigning work that generates evidence. The packet should be a file you add to as things happen, not a document you write in March:

• The design doc, linked.
• The migration outcome with numbers.
• Quotes from the partner teams, collected at the time, when people remember.
• The incident they led and the postmortem they wrote.

Writing a packet from memory at the deadline is how good engineers get stuck: the evidence existed and nobody wrote it down.

And be honest with yourself about the retention risk

If this person is genuinely close, they may leave. That is a legitimate outcome and pretending otherwise helps nobody. What reduces it is that the conversation gave them a real path with real work, rather than a deferral. What increases it is a vague no, or a promise you cannot keep.

If they do start looking, I would rather they leave having been told the truth than stay for another year on the strength of an implication I never intended.

Where this goes wrong

Being vague to be kind. "You're really close, keep doing what you're doing" is the worst possible answer. It is heard as a yes, it produces another year of the same work, and the next conversation is much worse because now they have evidence you misled them.

Making it about them when it is about me. If they have never been assigned cross-team work, "you need to show more scope" is unfair and they know it, even if they cannot articulate why.

Promising a promotion. You do not control the calibration room. Promise the packet and your advocacy; never promise the outcome.

Confusing tenure with scope. "You've been at this level three years" is not an argument, in either direction. Time served is not evidence.

Listing only what is missing. The conversation must include what is met, both because it is true and because a list of only deficits is not actionable, it is demoralising.

Leaving it until packet season. If the first time someone hears they are a level short is when the cycle opens, that is a management failure. No surprises applies to promotion exactly as it does to performance.

Interviewer follow-ups

"They say the rubric is subjective and everyone else got promoted with less." Take it seriously rather than defending the process, because sometimes they are right. I would go and look at what the last two people promoted actually did, and if their case is comparable I would say so and change my position. If it is not, I show the specific difference: "here's what X drove across three teams; here's the equivalent I don't have for you yet." Concrete comparison beats appeal to process, and being willing to be wrong about this is what makes the rest of my feedback credible.

"They ask 'if I do these three things, will I be promoted?'" I answer honestly and precisely: "If those three land the way I expect, I'll have a packet I can argue for, and I'll argue for it. I can't promise the outcome because I don't control the room. What I can promise is that I'll tell you in January if I think it isn't tracking, so you're not finding out in March." The interim checkpoint is what makes the honest answer acceptable rather than evasive.

"They're a flight risk and you need them on the current delivery." That conflict is exactly why they are one level short, and it is worth naming out loud to myself. Keeping the strongest person on the most critical delivery is locally rational and it is precisely what starves them of the evidence they need. The resolution is that someone else takes the critical delivery and I accept the delivery risk, because the alternative is losing them. If I genuinely cannot, then I should be honest that the promotion is a year away for structural reasons, and let them make an informed choice.

"They disagree and escalate to your manager." Good, and I would say so. I would brief my manager beforehand with the same rubric analysis I gave the engineer, so there is no daylight between the two accounts. If my manager sees it differently I want to know that, because it means my calibration is off and that affects everyone on the team, not just this person.

"What if the gap is capability rather than opportunity?" Then the plan is different and I should say so plainly rather than dressing it up as an opportunity problem. Scoped stretch work with support, pairing with someone already at the level, and a specific skill named rather than a general aspiration. And a realistic timeline, which for a genuine capability gap is longer than two quarters. What I would not do is offer an opportunity plan for a capability gap, because they will execute it, still not be promoted, and be entitled to be furious.

Production evidence

Will Larson's Staff Engineer documents the pattern directly: promotion to staff requires evidence of scope beyond a single team, that evidence comes from the work someone is assigned, and the manager's job is to create the opportunity rather than to wait for it. His writing on promotion packets is the practical reference.

Camille Fournier's The Manager's Path supplies the no-surprises principle and the argument that specificity is a form of respect in career conversations.

Google's and Meta's published promotion processes both work through a committee reading a packet of evidence, which is why "visibility to the room" is a real mechanism rather than politics: a committee can only promote on the basis of artifacts it can read.

Tanya Reilly's writing on glue work is directly relevant to the failure mode: the work that makes teams function is often invisible in a packet, and a lead's job includes making sure that work is either visible or redistributed, so the person doing it is not systematically disadvantaged at promotion time.

Interview delivery note

Open with the structure, and then with the diagnosis that most candidates skip: "First move, information I'd gather, line I wouldn't cross. And before the conversation I'd go through the next level's rubric line by line and ask one question that decides everything: have they had the opportunity to demonstrate what's missing? If the gap is cross-team influence and every project I've given them was inside the team, the gap is mine."

Then the conversation itself: "I'd lead with the answer so they're not spending it guessing, be specific against the rubric including what's met, name my own contribution, and convert the gap into named work rather than an instruction to be more strategic. Then a plan with three specific pieces of work, artifacts, and a review date."

The two lines that make it a lead-level answer: "I'd promise the packet and my advocacy, never the outcome, because I don't control the calibration room. And I'd commit to telling them in January if it isn't tracking, so they're not finding out in March."

Close: "The line I wouldn't cross is being vague to be kind. It's heard as a yes, it costs them a year, and the next conversation is far worse."

Further reading

• Will Larson, Staff Engineer, on scope as the promotion criterion and on building a packet continuously.
• Camille Fournier, The Manager's Path, on career conversations and the no-surprises principle.
• Tanya Reilly, "Being Glue", on invisible work and its effect on promotion evidence.
• Your own organisation's rubric and the last two promotion packets at that level, which are more useful than any book because calibration is comparative.

Building a story portfolio, not answers to questions

What it is

A set of 12 to 16 rehearsed stories from your own work, each with numbers and a stated decision, that you map onto whatever question you are asked, rather than a list of answers to anticipated questions.

THE WRONG MODEL
  "Tell me about a conflict"       -> the conflict answer
  "Tell me about a failure"        -> the failure answer
  "Tell me about influence"        -> the influence answer

  Requires anticipating the questions, which is impossible,
  and produces obviously-rehearsed answers to the ones you
  guessed and nothing for the ones you did not.

THE PORTFOLIO MODEL
  16 stories, each tagged with 3 to 5 themes it can serve.

  "Tell me about a conflict"    -> the auth migration story,
                                   told through the
                                   disagreement with the
                                   platform lead
  "Tell me about influence"     -> the SAME story, told
                                   through how the three EMs
                                   were brought along
  "Tell me about a failure"     -> the SAME story, told
                                   through the six weeks lost
                                   to the wrong sequencing

One story serves several questions because the same events contain conflict, influence, failure and technical judgement. The skill is knowing which thread to pull.

Commonly confused with having good answers. The portfolio is inventory; the skill is retrieval and framing. A candidate with twenty excellent stories and no index will search for one under pressure and tell it badly.

The problem it solves

Behavioural interviews sample from a large question space and you cannot cover it by anticipation.

Questions a staff loop might ask:
  disagreement with a peer / with your manager / with a
  senior leader / that you lost
  a failure / a mistake you caused / one you caught
  influence without authority / across teams / upward
  a technical decision you regret / one you were right
  about / one you changed your mind on
  mentoring / underperformance / hiring / firing
  ambiguity / conflicting priorities / a bad deadline
  the hardest thing you have built / the thing you are
  proudest of / the thing you would redo

That is thirty-plus questions. Nobody has thirty stories.

With sixteen well-chosen stories, each serving three to five themes, the space is covered, and the alternative is being caught without material for something you did not predict, which is where candidates freeze.

The second problem it solves is repetition. A candidate who tells the same story to four interviewers looks like they have one experience. The portfolio makes it deliberate: you know which stories you have used and can choose differently.

Mechanics

Choosing the sixteen

Not your sixteen favourite projects. Sixteen that cover the themes and demonstrate the level.

COVERAGE REQUIREMENTS (aim for at least one strong story in
each; several stories will cover several)

  TECHNICAL DEPTH        a decision only you could have made
  TECHNICAL BREADTH      a system you designed end to end
  SCALE                  something large, with numbers
  AMBIGUITY              a problem with no clear right answer
  FAILURE                one that was your fault
  RECOVERY               an incident you led
  CONFLICT (peer)        a disagreement you resolved
  CONFLICT (upward)      a disagreement with a manager or
                         senior leader
  INFLUENCE              cross-team, without authority
  MENTORING              someone who grew, with the mechanism
  UNDERPERFORMANCE       a hard people conversation
  HIRING                 a decision you made and why
  PRIORITISATION         something you chose not to do
  CHANGED YOUR MIND      with the evidence that changed it
  LONG-HORIZON           something that took quarters
  ORGANISATIONAL         a change to how the team worked

The three that candidates are most often missing:

Underperformance. Most senior engineers have never had the conversation, and staff loops ask about it because staff engineers influence people they do not manage. If you genuinely have no story, the closest legitimate substitute is a peer whose work you had to address, and being honest that you have not managed someone is better than inventing it.

Changed your mind. It is asked constantly and it needs a specific piece of evidence that changed your view. "I became more open to X over time" is not a story; "I ran the benchmark and it was 3x slower than I claimed, so I withdrew the proposal in the design review" is.

Something you chose not to do. Prioritisation stories are almost always told as "we shipped a lot", and the interesting version is what you killed and how you defended the decision.

The format: prepare in SCOR, deliver in STAR

PREPARE IN SCOR         because it forces the two things that
                        make a story land:
  Situation             context, compressed
  Complication          what made it hard
  Options               what you considered and rejected,
                        with costs
  Resolution            what you chose and what happened

DELIVER IN STAR         because that is the scoring rubric
  Situation + Task      including one explicit sentence about
                        what was YOURS to decide
  Action                the options compressed to one sentence
                        each, then what you did, in first
                        person singular
  Result                the number, and the lesson

The Options section is the staff signal and it is the one that disappears in a STAR telling. Compress each alternative to one sentence with its cost and keep all of them: "I evaluated scaling the cluster, which would have masked a cause I didn't understand; caching, which has near-zero hit rate for personalised results; and another day of root-causing with the regression visible." Twelve seconds, and it is the highest-density evidence of judgement in the whole story.

See SCOR, STAR and the scar-tissue story for the conversion mechanics.

The index: what makes it a portfolio rather than a pile

STORY                     THEMES                        NUMBERS
------------------------------------------------------------------
Auth migration across     influence, conflict-peer,     4 teams,
4 teams                   long-horizon, ambiguity       2 quarters,
                                                        3 EMs

Search p99 regression     technical depth, recovery,    4k QPS,
after personalisation     changed-my-mind               180->1400
                                                        ->210 ms

Killed the graph          prioritisation, conflict-     6 months
database project          upward, changed-my-mind       saved, 1
                                                        VP annoyed

Priya to senior           mentoring, organisational     18 months,
                                                        2 promoted

The reindex outage        failure, recovery,            40 min,
                          organisational                97% cache
                                                        miss
...

Building this table is the actual preparation, and it takes an evening. Once it exists, the interview becomes a lookup: hear the question, identify the theme, pick a story you have not used, and tell the version that emphasises that theme.

Track which stories you have used with which interviewer, because a loop is four to six conversations and interviewers compare notes.

Rehearsing the numbers, not the sentences

For each story, memorise 4 to 5 figures:
  the SCALE          "4,000 queries per second across nine
                     locales"
  the BEFORE         "p99 was 180 ms"
  the AFTER          "210 ms, better than before the
                     regression"
  one DETAIL only a  "six shards for 80,000 documents"
  participant knows
  the DURATION       "two days to find it"

The prose should vary between tellings and SHOULD. The
numbers must not, because inconsistency across a loop is
noticed and it is the fastest way to lose credibility.

The detail only a participant would know is the highest-value one. "Six shards for 80,000 documents" is not a fact anyone would recall unless they were there, and it does more for credibility than any adjective.

Timing, and the three lengths

Every story needs three versions and rehearsing only one is a common mistake.

30 SECONDS   the scar-tissue version, dropped inside a
             technical answer. Three sentences: what we did,
             what went wrong with a number, what we do now.

90 SECONDS   the standard behavioural answer. Full STAR,
             one number per section, stop.

3 MINUTES    the deep-dive version, when an interviewer says
             "tell me more about that". Adds the options in
             detail, the technical mechanics, and the
             follow-on consequences.

The failure mode is telling the three-minute version when ninety seconds was asked for, and it is extremely common. An interviewer who wants more will ask; one who is waiting for you to stop will not interrupt, and the impression is that you cannot calibrate.

What makes a story fail

NO NUMBER              nothing is verifiable, and it sounds
                       like a description of a category of
                       event rather than a memory.

NO "I"                 STAR scores individual contribution.
                       Say what the team did, then what you
                       did. This is rubric compliance, not
                       credit-taking.

NO DECISION            a narration of events you were present
                       for. The Options section is what makes
                       it a decision.

NO RETROSPECT          "what I'd do differently" is the
                       cheapest credibility available and
                       most candidates omit it.

TOO OLD                a story from six years ago suggests
                       nothing has happened since. Prefer the
                       last two to three years.

TOO SMALL              a story whose scope is one sprint does
                       not demonstrate staff level, however
                       well told.

A worked example: one story, four questions

THE EVENTS
  A search personalisation launch caused a p99 regression
  from 180 ms to 1.4 s, but only in small locales. Took two
  days to find because the team looked at aggregate latency.
  Cause: one query per shard per user segment, against
  locales over-sharded at six shards for 80,000 documents.
  Fixed by resharding and batching. p99 went to 210 ms.
  Added per-locale alerting, which caught an unrelated
  regression six weeks later.

"TELL ME ABOUT A TECHNICAL PROBLEM YOU SOLVED"
  Lead with the inversion: the smallest indices were the
  slowest, which ruled out capacity. Emphasise the diagnosis
  and the options considered.

"TELL ME ABOUT A TIME YOU CHANGED YOUR MIND"
  Lead with: I was convinced it was a capacity problem and
  argued for scaling the cluster. Segmenting by locale
  proved me wrong within an hour, and I withdrew the
  proposal in front of the team that had been about to
  approve the spend.

"TELL ME ABOUT PRESSURE FROM LEADERSHIP"
  Lead with: the business asked daily whether to roll
  personalisation back, and I asked for one more day with
  the regression visible. Emphasise the negotiation, the
  fallback plan I offered, and that I'd have rolled back if
  the day produced nothing.

"TELL ME ABOUT A FAILURE"
  Lead with: it took us two days to find, and it shouldn't
  have. We were alerting on aggregate p99, which hid an
  inversion that would have been obvious per locale on day
  one. That's the failure, and the alerting change is what
  came out of it.

Same events, four openings, four emphases, and the numbers are identical in all four. That is what a portfolio buys, and it is why sixteen stories cover thirty questions.

Production evidence

Amazon's Leadership Principles loop trains interviewers to collect STAR-structured evidence and to probe specifically for individual contribution, which is why the "we" to "I" conversion is mechanical rather than stylistic, and Amazon's own candidate guidance names STAR explicitly.

Google's published interview guidance tells candidates to use STAR and states that the interviewer is assessing what you did, which is the same rubric field.

Structured behavioural interviewing research consistently finds that structured questions predict job performance better than unstructured ones, which is why interviewers hold to the format: the structure is what makes candidates comparable, and a story that will not fit it is genuinely harder to score.

Barbara Minto's The Pyramid Principle is the source of the situation-complication-resolution structure, developed for consulting communication, and the reason leading with the complication works is that it makes the audience want the answer.

Will Larson's Staff Engineer contains interview accounts from staff engineers at many companies, and the recurring theme is that the stories that landed were about influence and judgement rather than about technical difficulty.

The debate

The case for a prepared portfolio: the question space is too large to anticipate, and under pressure people become vague. Preparation is what prevents that, and it is the single highest-return activity in behavioural preparation.

The case against over-preparing: rehearsed answers sound rehearsed, interviewers notice, and it reads as inauthentic. Some interviewers deliberately ask unusual questions to get past prepared material.

The case for preparing themes rather than stories: know what you want to convey and let the specifics come naturally. More flexible, and it fails under pressure precisely because specifics are what disappears when you are nervous.

My position: prepare sixteen stories in SCOR, index them by theme, rehearse the numbers rather than the sentences, and vary the prose deliberately between tellings.

The distinction between rehearsing numbers and rehearsing sentences is what resolves the over-preparation objection. A story told with identical wording sounds recited; a story told with identical figures and different wording sounds like a memory. So I would fix the four or five numbers per story and let everything else vary, which also means the story adapts to the question rather than being delivered regardless of it.

The three coverage gaps I would specifically hunt for are underperformance, changed my mind, and something you chose not to do, because they are asked constantly and most candidates have no material. For "changed my mind" the requirement is a specific piece of evidence, and "I became more open to X" is not a story. For underperformance, if you genuinely have not managed anyone, saying so and offering the closest real thing is better than constructing something, because an interviewer probing a fabricated people story finds the bottom of it in two questions.

The mechanical thing I would not skip is the index table, because it converts the interview from recall to lookup. Hearing a question and searching your memory for a relevant story is where candidates freeze; hearing a question, identifying the theme, and picking from a pre-tagged set is not. That table is an evening of work and it is worth more than rehearsing any individual answer.

And three lengths per story, because telling the three-minute version when ninety seconds was asked for is extremely common and reads as an inability to calibrate. An interviewer who wants more will ask.

Where I would push back on the framing: the portfolio is inventory, and the skill is retrieval. Twenty excellent stories with no index is worse than twelve indexed ones, because the failure under pressure is not lacking material, it is not finding it.

Follow-up Q&A

"Why a portfolio rather than answers to expected questions?" Because the question space is thirty-plus questions and nobody has thirty stories. Sixteen stories, each tagged with three to five themes it can serve, covers it, because the same events contain conflict, influence, failure and technical judgement, and the skill is knowing which thread to pull. Preparing answers requires anticipating the questions, which produces obviously-rehearsed answers to the ones you guessed and nothing for the ones you did not.

"How do you choose the sixteen?" By coverage, not by favourite. At least one strong story for each of: technical depth, breadth, scale, ambiguity, failure that was your fault, incident recovery, peer conflict, upward conflict, influence without authority, mentoring, underperformance, hiring, prioritisation, changing your mind, something long-horizon, and an organisational change. Several stories will cover several themes, which is the point.

"Which coverage gaps do candidates usually have?" Three. Underperformance, because most senior engineers have never had that conversation and staff loops ask because staff engineers influence people they do not manage. Changed your mind, which needs a specific piece of evidence, since "I became more open to X" is not a story. And something you chose not to do, because prioritisation stories are almost always told as "we shipped a lot" and the interesting version is what you killed.

"Doesn't this sound rehearsed?" Only if you rehearse the sentences. I fix four or five numbers per story, the scale, the before, the after, one detail only a participant would know, and the duration, and let the prose vary between tellings. Identical wording sounds recited; identical figures with different wording sounds like a memory. And it means the story adapts to the question rather than being delivered regardless of it.

"Show me how one story serves several questions." Take a search latency regression: p99 went from 180 milliseconds to 1.4 seconds, only in small locales, took two days to find. For "a technical problem you solved", lead with the inversion, that the smallest indices were slowest, which ruled out capacity. For "a time you changed your mind", lead with having argued for scaling the cluster and being proven wrong within an hour. For "pressure from leadership", lead with the business asking daily whether to roll back and me asking for one more day. For "a failure", lead with the two days, which was our alerting hiding an inversion that would have been obvious per locale. Same events, four openings, identical numbers.

"How long should a story be?" Three lengths, all rehearsed. Thirty seconds for the scar-tissue version dropped inside a technical answer. Ninety seconds for the standard behavioural answer. Three minutes for when someone says "tell me more". The common failure is giving the three-minute version when ninety seconds was asked for, which reads as an inability to calibrate, and an interviewer who wants more will ask.

"What makes a story fail?" Four things in order. No number, so nothing is verifiable and it sounds like a description of a category of event rather than a memory. No "I", because the rubric has a field for individual contribution and saying what the team did without saying what you did leaves it empty. No decision, so it is a narration of events you were present for, which is why the Options section matters. And no retrospect, which is the cheapest credibility available and most people omit it.

"What's the actual preparation work?" The index table: story, the three to five themes it serves, and its numbers. An evening. Once it exists the interview is a lookup rather than a recall problem, and recall is what fails under pressure. I would also track which stories I have used with which interviewer, because a loop is four to six conversations and interviewers compare notes, so telling the same story twice makes it look like you have one experience.

"What if you genuinely lack a story for a theme?" Say so and offer the closest real thing. For underperformance, if you have never managed anyone, "I haven't managed, but here's a peer whose work I had to address and how I handled it" is a good answer. Constructing something is much worse, because an interviewer probing a fabricated people story finds the bottom of it in two questions, and at that point the rest of the interview is spent recovering credibility.

Common misconceptions

"Prepare an answer for each likely question." The space is too large. Prepare stories and index them by theme.

"Rehearsing makes you sound fake." Rehearsing sentences does. Rehearsing numbers and varying the prose does the opposite.

"The best stories are the most technically impressive." At staff level the stories that land are about influence, judgement and decisions, and technical difficulty is the setting rather than the point.

"One great story is enough." A loop is four to six conversations and interviewers compare notes. Repeating a story makes it look like you have one experience.

"More detail is better." Beyond about a hundred seconds the interviewer stops tracking and starts waiting. Compress the Situation ruthlessly; it is the part everyone over-tells.

Interview delivery note

This topic is usually assessed indirectly, through whether your stories are good, but it does come up as "how do you prepare" and as advice-giving in a leadership conversation.

Frame it as inventory plus retrieval: "I'd build a portfolio rather than answers, because the question space is thirty-plus questions and nobody has thirty stories. Sixteen stories, each tagged with three to five themes, covers it, because the same events contain conflict, influence, failure and technical judgement. The skill is knowing which thread to pull."

Name the mechanism that makes it work under pressure: "And the actual artifact is an index table: story, themes it serves, and its numbers. That converts the interview from a recall problem to a lookup, and recall is what fails when you're nervous."

Give the over-preparation answer, because it is the obvious objection: "I'd rehearse the numbers, not the sentences. Four or five figures per story, fixed, and the prose varies every telling. Identical wording sounds recited; identical numbers with different wording sounds like a memory. And inconsistent numbers across a loop are noticed immediately."

The coverage point worth volunteering: "and I'd hunt specifically for the three gaps most people have: underperformance, changed-my-mind with a specific piece of evidence, and something you chose not to do. Those are asked constantly and most candidates have nothing."

Further reading

• Barbara Minto, The Pyramid Principle, for the situation-complication-resolution structure.
• Amazon's and Google's published interview preparation guidance, for how the STAR rubric is actually applied.
• Will Larson, Staff Engineer, for the interview accounts and what distinguished the stories that landed.
• SCOR, STAR and the scar-tissue story, for the format conversion mechanics.

The underperformance sequence and the no-surprises rule

"An engineer on your team is underperforming. Walk me through what you do."

What the question is actually testing

1. Whether you diagnose before you act. "Underperforming" is a symptom with at least six distinct causes, and the response differs completely by cause. A candidate who goes straight to a performance plan has skipped the only part that matters.
2. Whether you own your contribution. In a large share of cases the manager's expectations were never made explicit, and the person is failing to meet a standard nobody stated.
3. Whether you can be direct without being cruel. The failure modes are symmetric: vague feedback that leaves someone working hard on the wrong thing, and blunt feedback delivered as a verdict.
4. Whether you understand the no-surprises rule. If a formal process is the first time the person hears there is a problem, that is a management failure regardless of their performance.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: diagnose, because "underperforming" is six different problems

Before any conversation, work out which of these it is:

CAUSE                          WHAT IT LOOKS LIKE
-------------------------------------------------------------
UNCLEAR EXPECTATIONS           They think they are doing well.
                               Their work is good by a standard
                               nobody told them was wrong.
                               -> MY failure. Fix by stating
                                  the expectation.

MISSING SKILL                  Consistently struggles with one
                               category of work.
                               -> Training, pairing, or a
                                  different assignment.

WRONG ROLE FIT                 Strong at things the role does
                               not need, weak at what it does.
                               -> Often an internal move, and
                                  the best outcome available.

MOTIVATION                     Capable, disengaged. Something
                               changed.
                               -> A conversation, not a plan.

PERSONAL CIRCUMSTANCES         A sudden change in someone
                               previously reliable.
                               -> Support first. Almost
                                  everything else is wrong here.

ENVIRONMENT                    Blocked by dependencies, buried
                               in interrupts, poorly onboarded,
                               or set up to fail.
                               -> MY failure again.

Three of the six are the manager's failure, and that ratio is not an accident. In my experience the single most common cause is unclear expectations, and the person is genuinely surprised that anyone is unhappy.

The evidence to gather before deciding:

SPECIFIC EXAMPLES        Three to five concrete instances with
                         dates. "Quality is inconsistent" is not
                         actionable; "these three PRs needed
                         four review rounds each for the same
                         class of issue" is.

THE COMPARISON           Against the role's expectations, not
                         against the best person on the team.
                         A perfectly adequate engineer next to
                         an exceptional one is not
                         underperforming.

WHAT CHANGED             Was this always the case, or did it
                         start? A change has a cause.

MY OWN RECORD            Have I stated the expectation? In
                         writing? Have I given feedback that
                         was clear enough to act on? If not,
                         the sequence starts there, not with a
                         plan.

Then: the conversation, well before anything formal

This is the step that determines whether the rest is necessary. Private, direct, and it opens with the specific rather than the general.

"I want to talk about the last few weeks, and I want to be direct because I don't think being vague would be fair to you.

Three examples: the payments PR needed four rounds because of the same null-handling issue each time. The migration ran two weeks past the date without a heads-up until the day it was due. And in the design review last Thursday you presented an approach that hadn't accounted for the constraint we discussed the week before.

What I'm seeing is a pattern of work going out before it's ready. And before we go further, I want to check something: is that consistent with how you think it's going? Because if it isn't, then I haven't been clear enough about what I'm expecting, and that's on me."

Four properties, each doing work:

It leads with specifics, dated. Not a characterisation. Three instances they can verify.

It names the pattern, because three examples without a pattern is a list of complaints and three examples with one is a diagnosis.

It asks whether they agree, genuinely. If they are surprised, the cause is unclear expectations and the rest of the conversation changes.

It offers the manager's contribution as a real possibility, which is disarming, usually accurate, and the thing that makes the person engage rather than defend.

Then: the plan, informal and written

Before any formal process, an informal plan with a date.

WRITTEN DOWN, because a verbal plan is remembered differently
by each party within two weeks.

  What specifically needs to change, with observable
  criteria. Not "improve quality": "PRs go out with tests
  covering the null and error paths, and the design is
  agreed before implementation on anything over two days."

  What support I am providing. Pairing, a reduced load, a
  clearer spec, removing an interrupt source. If I am asking
  for change and providing nothing, the plan is a
  documentation exercise.

  A check-in cadence. Weekly, short.

  A review date. Six to eight weeks is typical: long enough
  to demonstrate change, short enough to be a real deadline.

  What happens if it does not change. Stated plainly and
  early, not saved as a threat.

That last item is the no-surprises rule in practice. The person should know, at the informal stage, that the next step is formal. Discovering that only when the formal process starts is the failure.

Then, only if needed: the formal process

By this point the person should be able to predict it
exactly. If a formal PIP is a surprise, I have failed at
the previous steps.

The formal process is HR's shape, and my job is:
  - the criteria are objective and achievable
  - the timeline is realistic for the change requested
  - I do not stop supporting them because it is formal
  - I have documented the informal stage, because HR will
    ask and because it protects both of us

And the honest statement about what a PIP usually is: in most organisations the majority of people on a formal plan leave, either by failing it or by choosing to go. That does not make it a formality, and treating it as one is a mistake in both directions: some people genuinely turn it around, and running a process you have already decided the outcome of is dishonest.

The exit, when it comes

Two paths, and offering both is right:

  RESIGN WITH DIGNITY   A conversation offering a transition
                        with a reference and time to find
                        something. Frequently the better
                        outcome for everyone, and it should
                        be offered honestly rather than as a
                        threat.

  COMPLETE THE PROCESS  If they want to try, they get a real
                        chance and my genuine support.

Either way: no surprises, and the team is told something
truthful and respectful. "X has decided to move on" when
everyone knows otherwise damages your credibility with the
people who remain, who are watching how you treat someone on
the way out and calibrating how you would treat them.

Where this goes wrong

Skipping the diagnosis. Going straight to a plan when the cause is unclear expectations means running a formal process against someone who was never told the standard.

Vague feedback. "You need to step up" is not actionable and is the single cruellest thing a manager does, because the person works hard on the wrong things and the next conversation is much worse.

Waiting too long. The most common failure. Three months of hoping it resolves, then a sudden formal process. The person is entitled to be furious about the three months.

Comparing to the strongest person on the team rather than to the role's expectations. That produces "underperformance" findings against people who are entirely adequate.

Not documenting. A verbal conversation is remembered differently by each party within two weeks, and by the formal stage the discrepancy is a problem for both of you.

Treating a PIP as a formality. If the decision is already made, say so and offer a transition. Running a process whose outcome you have decided is dishonest and the person can usually tell.

Not telling the team anything. The team knows. Silence reads as either indecision or as something worse, and the people staying are calibrating how you would treat them.

Interviewer follow-ups

"How quickly should you have the first conversation?" Within about two weeks of noticing a pattern, and the emphasis is on pattern rather than incident. One missed deadline is an event; three in six weeks is a pattern. Waiting three months is the most common failure and it is unfair in a specific way: every week you do not say anything is a week they spend not knowing they need to change, and they are entitled to be angry about that later.

"What if they disagree with your assessment?" Take it seriously rather than restating, because sometimes they are right. I would ask what they see, and specifically whether they were blocked by something I did not know about, and whether the expectation was ever stated. If their account holds up, my assessment changes. If it does not, I show the specific gap: "here's what the role needs, here are three instances where the work didn't meet it, help me understand the difference." Being willing to be wrong is what makes the rest credible.

"What if the cause is personal circumstances?" Then almost everything above is the wrong sequence. Support first: leave, reduced scope, a temporary reassignment, whatever the organisation can offer. A performance process against someone dealing with a serious personal situation is both wrong and, in many jurisdictions, legally risky. I would loop in HR early precisely because they know what support exists and what the obligations are. Performance management resumes when circumstances allow, and I would say that explicitly so it is not ambiguous.

"How do you handle it if they were fine and something changed?" Ask, directly and early, because a change has a cause and the cause is often something I can address: a reorg that removed their favourite work, a new manager relationship, a project they think is pointless, or something outside work. The mistake is treating a sudden decline the same as a persistent inability, because they need completely different responses and the sudden one is frequently the more fixable.

"What do you tell the rest of the team?" Truthful and minimal. During: nothing about the individual's performance, because that is theirs. After: something honest that does not pretend. "X is moving on, here's how we're covering their work" is fine; "X decided to pursue other opportunities" when everyone knows otherwise costs you credibility with the people staying. And I would be aware that the team is watching how someone is treated on the way out and inferring how they would be treated.

"What if you inherited this person mid-process?" Restart the diagnosis rather than continuing someone else's conclusion. I would read the documentation, talk to the person, and form my own view, because the previous manager's assessment may have been correct or may have been a personality mismatch, and inheriting a conclusion without testing it is unfair. I would also tell the person I am doing that, because being re-evaluated by a new manager is frightening and being explicit that I am forming my own view is worth a lot.

"What if they're a strong individual contributor with bad collaboration?" That is a performance problem, and I would name it as one rather than tolerating it because the output is good. The concrete version is to make the collaboration expectation explicit and observable, the same way I would for code quality, and then to treat it identically. What I would not do is have a vague conversation about "being a better teammate", because that is unactionable. See the toxic code reviewer, which is the same problem in a specific form.

Production evidence

Camille Fournier's The Manager's Path supplies the no-surprises principle and the argument that specificity is a form of respect, and it is direct that a formal process arriving as a surprise is a management failure.

Kim Scott's Radical Candor frames the two symmetric failure modes precisely: ruinous empathy, being kind at the expense of clarity, and obnoxious aggression, being clear without care. The underperformance conversation is where both are most costly.

Google's re:Work manager research documents that the highest-rated managers give clear, specific, timely feedback, and that unclear expectations is among the most common causes of poor performance, which is the empirical basis for diagnosing before acting.

The widely-reported statistic that a large majority of employees on formal performance plans leave is why the informal stage matters: by the time it is formal, the outcome is largely determined, so the effort belongs earlier.

SBI (Situation-Behaviour-Impact), from the Center for Creative Leadership, is the standard feedback structure and is what the "three dated examples plus the pattern" formulation implements.

Interview delivery note

Open with the diagnosis, because it is the step candidates skip and it is where the judgement is: "My first move isn't a conversation, it's working out which problem this is. Underperformance has about six causes: unclear expectations, a missing skill, wrong role fit, motivation, personal circumstances, and environment. Three of those six are my failure, and in my experience unclear expectations is the most common, where the person is genuinely surprised anyone is unhappy."

Then the conversation, with the specific mechanics: "Then a private conversation, well before anything formal, that opens with three dated examples rather than a characterisation, names the pattern, and then asks whether they agree. And I'd explicitly offer that if they're surprised, I haven't been clear enough, and that's on me. That last part is disarming, usually accurate, and it's what makes them engage rather than defend."

Name the no-surprises rule as a rule: "And the person should be able to predict the formal process before it starts. If a PIP is the first time they hear there's a problem, I've failed at every step before it, regardless of their performance."

The line about the plan that shows you have run one: "The informal plan is written down, with observable criteria rather than 'improve quality', with what support I'm providing, and with what happens if it doesn't change stated plainly and early rather than saved as a threat. If I'm asking for change and providing nothing, the plan is a documentation exercise."

Close on the line you would not cross: "The line I wouldn't cross is being vague to be kind. It's the cruellest thing a manager does, because they work hard on the wrong things for months and the next conversation is far worse. And the second is waiting: three months of hoping is the most common failure, and they're entitled to be furious about it later."

Further reading

• Camille Fournier, The Manager's Path, on the no-surprises principle and career conversations.
• Kim Scott, Radical Candor, particularly the ruinous-empathy failure mode.
• Google re:Work's manager research, on feedback specificity and unclear expectations as a cause.
• The Center for Creative Leadership's SBI feedback model.

The AI-era review queue problem

"Since the AI tooling rollout, your review queue depth has doubled. What do you do?"

What the question is actually testing

1. Whether you recognise it as expected rather than surprising. When generation gets faster, the bottleneck moves from writing to reviewing. Teams hit this in month two of adoption almost universally, and a lead who treats it as an anomaly has not thought about where the constraint was.
2. Whether you measure before acting. The obvious response is "add reviewers", which is a staffing answer to a systems problem.
3. Whether you know the throughput-versus-stability data. This is the specific case where celebrating a delivery metric hides a quality regression.
4. Whether your interventions scale. Human review does not scale with generation speed. Only automation does.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: say that this is expected, and why

"I'd start by saying this is the predicted outcome rather than a surprise. The constraint on shipping was never typing speed; it was review, testing and deployment. Making generation faster doesn't remove the constraint, it moves load onto it. So the queue doubling is the system telling us where the bottleneck actually is, which is useful information."

Framing it as a bottleneck shift rather than a problem does real work in the conversation, because the alternative framing ("the AI tooling caused a problem") produces a conversation about whether to roll it back, and that is the wrong conversation.

Then: the measurement, split by whether the PR was AI-assisted

Without the split I am guessing, and the split is the whole diagnosis.

MEASURE, split AI-assisted vs not:

  review queue depth          how many PRs waiting
  time to first review        how long before anyone looks
  total merge time            open to merged
  PR size distribution        lines changed, files touched
  review rounds per PR        how many back-and-forths
  reviewer concentration      is one person doing 60% of it?

AND the quality side, over the same period:
  change failure rate
  escaped defect rate
  revert rate
  incident count attributable to recent deploys

The pattern I would expect, and the thing to name:

AI-assisted PRs are typically LARGER and arrive FASTER.
  -> queue depth rises from arrival rate, not from reviewers
     getting slower
  -> and review effectiveness collapses past roughly 400
     lines changed, which is a well-established finding, so
     larger PRs are reviewed WORSE at the same time as there
     are more of them

Reviewer concentration is the metric most likely to reveal the real problem. If one senior engineer is doing most of the review, the queue is a single-person bottleneck and no amount of process change fixes it without redistributing.

Then: four counters, in order of leverage

Human review does not scale with generation speed. Only automation does, so the interventions have to shift load off humans rather than asking humans to do more.

1. CAP PR SIZE.
   Review effectiveness collapses past roughly 400 lines, and
   generated PRs are often large. A CI check that flags PRs
   over the threshold, with an override that requires a
   reason, is the highest-leverage single change because it
   attacks both the queue depth and the review quality at
   once.

2. RAISE TEST REQUIREMENTS ON GENERATED CODE.
   Tests are the check that scales when volume rises and
   human review does not. Coverage on the changed lines,
   plus explicit tests for the error and null paths, which
   is where generated code most often falls short.

3. REQUIRE AUTHORS TO EXPLAIN GENERATED CODE AS THEIR OWN.
   Stated as a policy: if you cannot explain why it works and
   what it does at the boundaries, it does not go up for
   review. This is both a quality gate and a learning one,
   and it addresses the failure mode where an author submits
   code they have not read.

4. LABEL AI-ASSISTED PRs.
   Not to stigmatise, but so reviewers calibrate their
   attention and so the measurement above is possible at all.
   The label is what makes everything else measurable.

Ordering matters: PR size first, because it is a mechanical change, it needs no behaviour change from reviewers, and it improves review quality and queue depth simultaneously. Adding reviewers is nowhere on the list, and saying so explicitly is part of the answer.

Then: the thing to raise unprompted with leadership

"The thing I'd bring to leadership without being asked is the two-sided data. AI adoption correlates with higher throughput and also with higher change failure rate and slower recovery. That's DORA's recent reporting, and it's correlational rather than causal, and the useful framing is that AI amplifies whatever the team already is: strong testing and fast rollback get faster, weak ones get faster at shipping defects.

So I'd pair every speed metric with a quality guardrail and report them together. Because if we report deployment frequency alone we'll celebrate a number that's getting worse underneath, and by the time change failure rate is visible we'll have shipped a quarter of defects."

Volunteering the risk before it is asked about is the move, and it is what converts the conversation from "the tooling caused a queue problem" to "here is how we get the throughput without the instability".

The line I would not cross

"I wouldn't lower the review bar to clear the queue. That's the tempting move because the queue is visible and the defects are not yet, and it converts a throughput problem into a quality problem that surfaces six weeks later as incidents. If the queue cannot be cleared at the current bar, the answer is fewer or smaller PRs, not looser review."

Where this goes wrong

Adding reviewers. A staffing answer to a systems problem. It works briefly, it consumes the capacity that was supposed to be freed by the tooling, and it does nothing about PR size or review quality.

Rolling back the tooling. Throws away a real throughput gain to fix a bottleneck that was always there and was previously hidden by the slower arrival rate.

Celebrating deployment frequency. The specific failure this question exists to test. Reporting the throughput metric alone during a tooling rollout means celebrating a number that is degrading underneath.

Treating it as a quality problem with the individuals. The people writing the PRs are using the tool they were given. The system produced this, and the interventions are systemic.