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.