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.

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.

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.