Elite AI-Lab SWE Interview Program

← All Roles

An executable training program for elite AI-lab software-engineering loops — OpenAI, Anthropic, DeepMind, Scale, Cursor, xAI, Databricks, Netflix, Stripe. Not a reading list: source code, gated drills, scored rubrics, and a progress ledger you run day by day.

Target: senior / staff, IC track. Budget: 22 h/week × 26 weeks ≈ 570 hours.

Table of Contents

• Current Phase
• Start Here
• What This Is
• The Loop This Is Built Against
• Repository Layout
• The Runnable Tools
• The Seven Tracks
• Beyond the Ask
• Operating Rules
• Honest Status
• References

Current Phase

Phase 1 — Calibrate. Week 0.

Phase 0 research is complete. The diagnostic battery is built and runnable. PLAN.md is deliberately locked until you report diagnostic scores — writing it now would mean guessing your level, and a plan optimized for a person who does not exist is worse than no plan.

Your next action: take the 3-hour baseline diagnostic.

Live status in STATE.md.

Start Here

Do not read diagnostics/ANSWER-KEY.md or any solution.py before step 3. A contaminated baseline produces a plan for the wrong person.

The study guides

The actual teaching material. Each is self-contained — every concept from first principles, full implementations, worked scenarios, and the follow-up questions with answers. You should not need to leave these files to understand them.

The two reference documents

Not teaching material — retrieval material. Read the guides once; read these the morning of.

What This Is

Most interview prep is a list of things to read. Reading does not make you faster under a timer, does not teach you to defend a design under attack, and does not produce a story bank.

So this is built as an engineering project instead:

• A stage-gated coding harness that refuses to show you the next requirement until your code passes the current one — reproducing the reported onsite format's actual constraint.
• A diagnostic battery with a scoring rubric that maps to a starting level per track, so the plan is built from measurement rather than assumption.
• Runnable experiments for every claim about the Python runtime. No prose assertions.
• Back-of-envelope calculators so the arithmetic you do out loud in a design round is reflex.
• GPU memory and roofline math you can derive on a whiteboard.
• A spaced-repetition queue that resurfaces everything you got wrong at 1, 3, 7, 21 days.
• Weekly scored mocks on a hire-bar scale, with the level stated plainly.

Nothing is marked complete because you read it. Completion requires a passed drill, a working artifact, or a scored mock.

The Loop This Is Built Against

Reconstructed from one candidate's account, then corroborated where possible. Full epistemic labelling in research/findings.md; the 41-row fidelity checklist in research/source-report.md.

A caution that shapes the whole program. The originating source is a single unverified candidate account. The loop varies by team, level, and quarter. So roughly a quarter of the material is deliberately off-report, the onsite is prepared as six components rather than four, and nothing here is asserted to an interviewer as fact about their process. See the anti-narrowing clause.

Repository Layout

README.md              this file — entry point and current phase
PLAN.md                the 26-week program (locked pending diagnostic)
STATE.md               progress ledger; updated every session
research/              findings, fidelity checklist, company brief
diagnostics/           baseline battery, answer key, rubric, scores
tracks/
  coding/              Track A + the progressive harness (15 problems)
  python-internals/    Track B + 5 runnable experiment scripts
  systems-design/      Track C + envelope calculators + 12 designs
  ml-infra/            Track D + gpu_math.py
  behavioral/          Track F — story bank, probes, forward-looking
  agentic/             Track G — agent-driving method and tasks
projects/              the real builds — take-homes, portfolio, essay
mocks/                 weekly scored mocks, transcripts, hire-bar scale
review/                spaced repetition queue + failure log

The Runnable Tools

Everything here works today.

# Track A — the stage-gated harness
cd tracks/coding/harness
./progressive.py list
./progressive.py start token-stream-differ     # prints gate 1 only
./progressive.py test  token-stream-differ     # unlocks gate 2 on pass
./progressive.py chart                          # time-to-first-gate trend

# Track B — proof, not prose
cd tracks/python-internals/experiments
python3 exp01_generators.py exp02_async.py     # (run individually)
python3 exp03_gil.py                            # measures a real lost-update race
python3 exp04_memory.py                         # __slots__, memoryview, tracemalloc
python3 exp05_datamodel.py                      # descriptors, MRO, __getattr__

# Track C — the arithmetic you say out loud
cd tracks/systems-design/calculators
python3 envelope.py qps --rps 50000 --ms 8
python3 envelope.py retry --rps 10000 --fail 0.3
python3 envelope.py latencies

# Track D — the memory and roofline math
cd tracks/ml-infra
python3 gpu_math.py --model llama-70b --gpu h100 --gpus 4

# review — spaced repetition
cd review
python3 review.py add "..." --confident-wrong
python3 review.py drill

# the diagnostic
cd diagnostics/d1-coding
cp starter.py attempt.py && python3 test_diagnostic.py attempt.py

The Seven Tracks

Shares are the baseline. They are re-derived from your diagnostic levels and rebalanced at each of the six monthly re-tests.

Beyond the Ask

The differentiators, built into the schedule rather than left as good intentions:

Operating Rules

Applied without exception:

• Reading never completes anything. Passed drill, working artifact, or scored mock.
• STATE.md updated every session. The next session starts cold and reads only that file.
• Weekly scored mock, on the hire-bar scale, with the level stated plainly — including no hire.
• Score down when unsure. A generous rubric is the one thing that guarantees failure.
• Spaced repetition at 1, 3, 7, 21 days. Wrong at any interval resets to 1.
• Every performance claim has a script that demonstrates it.
• Inference is labelled as inference. Nothing speculative about anyone's process is presented as fact, and none of it is ever said to an interviewer.
• Commit at every milestone, with a real message.

Honest Status

What exists today versus what is scheduled — so nothing here overstates itself.

Every runnable artifact is verified: python3 tracks/coding/harness/runtests.py runs all 60 gates in about six seconds. Remaining scheduled work is tracked in STATE.md.

References

• research/findings.md — Phase 0, with confirmed / reported / inference labels and full sources
• research/source-report.md — the 41-row fidelity checklist and coverage audit
• research/company-brief.md — charter digest, talking points, the three questions you ask
• diagnostics/README.md — the battery and how to take it
• PLAN.md — the 26-week program
• STATE.md — where you are right now
• Related tracks in this hub: llm-inference-engineer · Senior AI Engineer · agentic-engineer · pretraining-lead

Cheat Sheet — Everything, Dense

This is the reference. One page per domain, nothing you cannot use in a room. Every formula, every number, every decision rule, every complexity, every failure mode, and the sentences to actually say out loud.

Read it end to end once. After that, open it the morning of a round and read only the section for that round. Everything here is taught from first principles in the WARMUP guides — the links are per section.

Table of Contents

• 1. The Loop, Round by Round
• 2. Coding — Representation First
  • 2.1 The query-shape table
  • 2.2 The three questions
  • 2.3 The ten patterns, one line each
  • 2.4 Complexity table
  • 2.5 The narration script
  • 2.6 Coding failure modes
• 3. Python Internals
  • 3.1 Version-dependent facts
  • 3.2 Generators
  • 3.3 Async
  • 3.4 Concurrency decision table
  • 3.5 Memory
  • 3.6 Data model
  • 3.7 The traps
• 4. Distributed Systems
  • 4.1 The arithmetic
  • 4.2 Latency numbers
  • 4.3 Leases and fencing
  • 4.4 Replication and quorums
  • 4.5 Consensus
  • 4.6 Consistency models
  • 4.7 Time
  • 4.8 Partitioning
  • 4.9 Delivery semantics
  • 4.10 Load control
  • 4.11 The failure catalog
  • 4.12 The design template and clock
• 5. Inference Infrastructure
  • 5.1 The one derivation
  • 5.2 Memory formulas
  • 5.3 Hardware numbers
  • 5.4 Llama-70B anchors
  • 5.5 Technique tradeoffs
  • 5.6 Autoscaling signals
  • 5.7 The two altitudes
• 6. Take-Home and Deep Dive
• 7. Behavioral
• 8. Agentic Coding
• 9. The Scripts
• 10. Pre-Round Checklist

1. The Loop, Round by Round

Calibrate to Staff, not Senior — AI-lab levelling is compressed; the "Senior" title reportedly carries Staff scope. Ask the AI-tool policy per company, per round — policies are opposite at labs you may interview at in the same month.

2. Coding — Representation First

Taught in: tracks/coding/WARMUP.md

2.1 The query-shape table

The single most useful table in the whole document. Hear the query shape, not the noun.

A hash map answers exactly, never nearest. The moment a requirement says before, after, as of, range, nearest, at most — you need an ordered structure.

2.2 The three questions

Ask out loud in the first 90 seconds. Each has historically decided whether gate 3 was additive or a rewrite.

1. "Is the input replayable / immutable?" → if yes, store positions into it, not copies. O(1) checkpoints instead of O(n).
2. "Is this identifier global or per-entity?" → global makes a snapshot one integer. Per-entity forces a vector and every later gate is harder.
3. "Will I ever need to undo this?" → if maybe, store deltas, not states. Deltas compose; snapshots do not.

2.3 The ten patterns, one line each

2.4 Complexity table

Four sentences worth memorizing: hash maps answer exactly, never nearest · heaps keep only the partial order you need · O(1) removal needs the node and double links · append-only data is sorted for free when the key is monotonic.

2.5 The narration script

1. Restate the problem in your own words.
2. Clarify — ≥2 questions, ≥1 that could change your representation.
3. State the approach in two sentences + name the data structure.
4. State the complexity before implementing.
5. Write the test for the tricky invariant first.
6. Code, narrating decisions — not keystrokes. "I'm recording the event count per feed so I can unwind it later" is a decision. "Now a for loop" is not.
7. When stuck, keep talking. Silence is the costliest narration failure.

2.6 Coding failure modes

3. Python Internals

Taught in: tracks/python-internals/WARMUP.md · QUIZBANK.md

3.1 Version-dependent facts

Say the shape, then check — never recite a constant.

3.2 Generators

3.3 Async

3.4 Concurrency decision table

async for waiting, processes for computing, threads for when the library gives you no choice.

The GIL: guarantees one thread runs bytecode at a time, so single bytecodes and non-releasing C calls are atomic. Does not make your sequences atomic. list.append atomic; counter += 1 not.

The nuance that separates you: since 3.10 the eval breaker is checked only at specific instructions (backward jumps, calls). So a bare counter += 1 loop often loses zero updates — the check lands after the STORE. Put a call between load and store and it loses 3%; make __add__ a Python method and it loses 61%. "I ran it and it didn't lose anything" is not evidence of atomicity.

3.5 Memory

3.6 Data model

Attribute lookup order: data descriptor on type → instance __dict__ → non-data descriptor → class attrs up the MRO → __getattr__.

3.7 The traps

4. Distributed Systems

Taught in: tracks/systems-design/WARMUP.md

4.1 The arithmetic

Little's law \( L = \lambda W \) — items in system = arrival rate × time in system.

• Sizing: 50k rps × 8 ms = 400 concurrent.
• Latency from depth: 10,000 queued ÷ 100/s = 100 s wait.
• Pool: 500 qps × 20 ms = 10 connections busy.

The utilization knee — M/M/1: \( W = W_s / (1-\rho) \)

Latency is hyperbolic in utilization, not linear. Real traffic is burstier than Poisson, so the knee arrives earlier. This is the whole quantitative argument for admission control.

Retry amplification = \( \sum_{i=0}^{k-1} f^i \)

Storage: 1M × 1 KB = 1 GB · 1B × 1 KB = 1 TB · day ≈ 10⁵ s · month ≈ 2.5×10⁶ s.

4.2 Latency numbers

Two derived rules: memory ~100× SSD, SSD ~100× disk seek · any cross-service hop ≥ 0.5 ms, so five sequential hops have a 2.5 ms floor → fan out, don't chain.

4.3 Leases and fencing

The highest-value 200 words in the track.

A lock held by a dead holder is held forever. A lease expires → liveness. But:

t=0   A takes a 30 s lease on J. Starts work.
t=10  A GC-pauses / partitions / is descheduled.
t=30  Lease expires. A hasn't renewed.
t=31  B takes the lease. Runs J.
t=45  B finishes, writes.
t=50  A wakes. From A's view NOTHING HAPPENED. Finishes J and writes.
      A's stale write lands AFTER B's correct one.

You cannot detect this. Unreachable and dead are indistinguishable from outside — that is a theorem. And "check your lease before writing" fails too: the pause can land between the check and the write.

Fencing token — a monotonically increasing number issued with every lease grant. The resource rejects any write with a token below the highest it has seen.

UPDATE results SET value=%s, fence=%s
 WHERE job_id=%s AND fence < %s;   -- 0 rows = superseded. Do not retry.

Where it's checked matters more than the token. The resource must enforce it — not the lock service, not the client. A zombie client believes its token is current. If the resource can't participate (a third-party API with no conditional write), say so and mitigate with idempotency or accept at-most-once.

Lease sizing: renew at lease/3 so two missed heartbeats are tolerable. Too short → GC pauses cause spurious expiry and routine double execution. Too long → a dead holder blocks work. 60 s / 20 s is a reasonable default.

Redlock: relies on bounded clock drift and bounded pauses for correctness; neither is guaranteed. The safety argument lives in fencing, not the lock protocol.

4.4 Replication and quorums

Quorum: \( W + R > N \) forces overlap (pigeonhole) → a read sees the latest write.

What a quorum does NOT give you (name three): sloppy quorums break the overlap · concurrent writes still need conflict resolution · a write that fails after reaching some replicas isn't rolled back · read-your-writes isn't guaranteed across sessions · quorum reads aren't linearizable without read-repair-then-commit.

Convergence: read repair (cheap, on the read path, misses cold data) + anti-entropy (Merkle trees — compare root hashes, descend only into differences, O(log n) in the difference).

4.5 Consensus

What it buys: agreement on an ordered log → replicated state machine → anything.

FLP: in a fully asynchronous system with one faulty process, no deterministic algorithm guarantees consensus. Practical systems add timeouts → safety always, liveness under assumptions.

Raft:

• Terms are a logical clock. Higher term seen → step down. That one rule kills most split-brain.
• Randomized election timeouts (150–300 ms) break split votes without coordination.
• An entry is committed once on a majority.
• Log matching: same index + same term ⇒ identical logs up to that point (by induction).
• Safety rule 1 — election restriction: a voter refuses a candidate whose log is less up-to-date. Two majorities must intersect ⇒ any winner has every committed entry.
• Safety rule 2 — never commit a previous term's entry by counting replicas. A leader commits only its own term's entries by counting; older ones commit indirectly. In practice a leader appends a no-op to trigger it. (This is the part people skip.)

Costs — say these: every write is ≥1 RT to a majority (~1 ms same-DC, 50–150 ms cross-region) · the leader is a throughput ceiling → shard into many Raft groups · failover is a latency spike · odd numbers only (3→4 doesn't improve tolerance) · membership change is the hard part.

Use consensus for metadata, not data.

4.6 Consistency models

Strict serializability = both. That's Spanner, and why it needs TrueTime.

Snapshot isolation permits write skew — two txns read overlapping data, write disjoint keys, both commit, jointly break an invariant. Canonical: on-call doctors. Fixes: SELECT ... FOR UPDATE · materialize the conflict · SSI (Postgres SERIALIZABLE).

Session guarantees (cheap, and what users notice): read-your-writes · monotonic reads · consistent prefix · causal · bounded staleness.

CAP, precisely: when a partition occurs, choose consistency or availability. Only during a partition. "Available" means every non-failing node responds. Say PACELC: if P then A or C, Else Latency or Consistency.

4.7 Time

NTP holds a few ms on a good LAN — a statistical claim, not a bound. A node cannot know its own skew.

Last-write-wins by wall clock is a documented data-loss mode when a node's clock is skewed.

4.8 Partitioning

hash(key) % N → changing N moves ~80% of keys. Consistent hashing → only K/N move, and only from one neighbour. Virtual nodes (100–256/node) fix two things: load variance (drops as 1/√v) and — more important — a node's failure spreads across many successors instead of dumping its whole range on one and cascading.

Hot partitions: cache it (usually the whole answer) → split the key (id:0..99) → dedicated partition → rate-limit it. Per-key metrics come first — you can't fix what you can't see, and aggregates hide it completely.

Rebalancing: snapshot → stream delta → briefly block + flip ownership. Fence the flip. Never auto-rebalance on failure (a blip triggers a storm). Rate-limit the copy.

4.9 Delivery semantics

Exactly-once delivery is impossible — sender can't distinguish "never arrived" from "arrived, ack lost"; more round trips just move it to the ack of the ack (Two Generals).

Exactly-once processing = at-least-once + idempotent consumer. Requires a stable idempotency key generated by the PRODUCER, unchanged across retries. Generate it at send time and dedupe silently does nothing.

Dual write — db.save(x); queue.publish(x) — has no safe ordering. Fix: outbox — insert into an outbox table in the same transaction, a relay publishes with FOR UPDATE SKIP LOCKED. Or CDC (tail the WAL/binlog).

DLQ needs four things, and most designs mention only the first: the reason (error, stack, attempt count) · a replay path · poison detection (permanent vs transient — don't retry 4xx) · alert on arrival rate, not depth. And state the ordering consequence: if message 5 dead-letters, 6 either blocks (order preserved) or proceeds (order broken). No third option.

4.10 Load control

Fix order — most people get this backwards:

1. Retry budget — cap retries at ~10% of base traffic. Bounds amplification at 1.1× no matter how bad it gets. (gRPC retry throttling, Envoy retry budgets.)
2. Circuit breaker — stop trying entirely.
3. Jitter — desynchronize what you do send.

Jitter alone still delivers 2.85× at a 95% failure rate. And don't retry at every layer — 3 layers × 3 retries = 27 attempts.

Backoff variants: full uniform(0, min(cap, base·2^n)) — AWS's simulation found it minimized both total work and completion time · equal temp/2 + uniform(0, temp/2) — keeps a floor · decorrelated uniform(base, prev·3) — smoothest, hardest to bound.

Circuit breaker: closed → open (fail immediately) → half-open (one probe, not a flood). Threshold must be a rate over a minimum volume ("50% over ≥20 requests in 10 s") — an absolute count breaks on low-traffic endpoints. Scope per endpoint, often per instance.

Shedding: rejecting 10% in 1 ms beats accepting 100% and timing all out at 30 s. Shed by priority, not at random. Shed the OLDEST queued item — under sustained overload FIFO serves only requests whose clients have given up. Deadline propagation: pass the remaining budget downstream; fail fast if there isn't enough left.

Bulkheads: separate pools per dependency. Honest counter-argument: by M/M/c, one pool of 50 has better tails than five of 10 — you trade efficiency for isolation. Cellular architecture is the strongest blast-radius answer: 1/N by construction.

4.11 The failure catalog

Fail-slow is worse than fail-stop and it's the common case — the node answers your health check in 2 ms while serving real requests in 40 s. If your only health signal is "does it respond", you haven't handled the common case.

Say one deliberately accepted failure mode with its cost. That's a staff move; claiming to have handled everything is falsifiable in one question.

4.12 The design template and clock

1 Requirements & scope   (incl. explicitly out of scope)
2 Scale numbers          (and the arithmetic you did)
3 API surface            (3-5 calls that matter)
4 Data model             (keys and indexes, and WHY)
5 High-level arch        (the diagram)
6 DEEP DIVE: the two hardest components
7 Failure & recovery     (detection · containment · recovery, each)
8 Bottlenecks & evolution
9 Tradeoffs explicitly rejected

Finding the two hard parts: where must ≥2 machines agree? · where can data be lost? · what's highest-rate/cardinality? · where does one tenant affect another?

Say at minute 10: "I think the two places this can actually fail are X and Y, so that's where I want to spend the time — does that match what you care about?"

5. Inference Infrastructure

Taught in: tracks/ml-infra/WARMUP.md · runnable: gpu_math.py

5.1 The one derivation

Arithmetic intensity \( I = \text{FLOPs} / \text{bytes moved} \). Machine balance = peak dense FLOP/s ÷ bandwidth. H100: \( 989.5 \times 10^{12} / 3.35 \times 10^{12} \approx \mathbf{295}\) FLOP per byte.

Decode: every weight is read once per step regardless of batch; each sequence does ~2N FLOPs.

\[ I_{\text{decode}} \approx \frac{2Nb}{2N} = b \qquad\text{(the batch size)} \]

At batch 1 you use ~1/295 of the GPU's compute. Say "dense". The datasheet's 1,979 TFLOP/s is with 2:4 sparsity; LLM weights are dense, so the real number is 989.5 and the balance is 295, not 590. Quoting the sparse figure for a dense workload is a cheap way to look like you read a spec sheet instead of a benchmark.

70B FP16 on H100:
  weights 140 GB / 3.35 TB/s   = 41.8 ms   (memory)
  2 x 70e9 / 989.5e12          =  0.14 ms  (compute, dense BF16)
  ratio 295x  → MEMORY-BOUND   (exactly the machine balance — a good self-check)

Prefill: all s prompt tokens at once → \( I \approx s \). A 2,000-token prompt = 280 TFLOP = 141 ms of solid compute → compute-bound, and it blocks everyone's decode.

Prefill is compute-bound, decode is memory-bound. Two workloads on one accelerator. That sentence is most of this round.

The proof: H200 has identical compute to H100 (989.5 TFLOP/s BF16 dense) and +43% bandwidth (4.8 vs 3.35 TB/s), and is materially faster at decode. If decode were compute-bound it would be exactly as fast.

5.2 Memory formulas

5.3 Hardware numbers

Cloud $/hr, 2026-reported, order of magnitude: H100 ~$1.50–3.00 · H200 ~$3.80 · B200 ~$6.50. Always attach a date to a price.

5.4 Llama-70B anchors

At batch 130 the KV cache (164 GB) exceeds the weights (140 GB). Doubling context halves concurrency, one for one.

5.5 Technique tradeoffs

Parallelism: TP splits each layer — all-reduce every layer, needs NVLink, within a node, improves latency. PP splits layers — one transfer per boundary, across nodes, bubbles, does not improve latency. EP for MoE — all-to-all per layer, expert load imbalance is the hot-partition problem again.

The framing that scores: these aren't a stack of free wins, they're points on a throughput-vs-tail-latency curve — and it isn't one curve. Interactive chat, agentic loops, and batch want different scheduler policies → separate pools or one priority-aware scheduler with preemption. (Recompute is usually cheaper than swapping KV over PCIe.)

5.6 Autoscaling signals

Request cost varies ~10,000× ("hi" ≈ 1 unit; a 100k-token agent step ≈ 50,000).

Composite: max(kv_occupancy/0.85, queue_wait_p95/target).

Scale-up is minutes (instance acquisition + pulling + loading 140 GB of weights + CUDA graph capture) → reactive is always late. Forecast from the diurnal curve · warm pools sized by forecast error, not average load · admission control as the fast path.

Fairness on TOKENS, not requests — ten 100k-token requests is 1,000× ten small ones.

5.7 The two altitudes

Default (abstracted) — say this verbatim:

"I'll treat the inference engine as a service with three properties: it exposes capacity in tokens per second rather than requests per second, it has an admission interface I can apply backpressure to, and it streams. I'll spend my time on traffic, coordination and failure — tell me if you want me to open it up."

When they say "open it up", lead with the constraint, not a build-up:

"The binding constraint is memory bandwidth, and the binding capacity is the KV cache."

Then: memory budget → why decode is bandwidth-bound (+ H100/H200 proof) → therefore batching → continuous batching + PagedAttention → the prefill/decode conflict → chunked prefill → prefix caching → the curve framing.

Never claim knowledge of their internal stack. Say: "I don't know how you do this internally, so I'll reason from the public systems — PagedAttention, Orca's continuous batching, Sarathi's chunked prefill — and you can tell me where that diverges."

6. Take-Home and Deep Dive

Taught in: tracks/take-home/WARMUP.md

The take-home and the deep dive are ONE round. The take-home generates a personalized interrogation surface. Every decision in the 48 hours is a question in week three. So the target isn't "best code" — it's code every line of which I can defend, plus a written record of the alternatives I rejected.

Never cut: tests + a one-command runner · README that works on a clean machine · design doc with tradeoffs · ambiguities section · decisions.md · error handling on external boundaries · clean commit history · one benchmark · "what I'd do with two more days".

"Beyond the ask" = ONE of: a measured benchmark with honest methodology (including the disappointing number) · a failure-injection test that proves a recovery path · an operational concern nobody asked for (structured logs + correlation ID, real health check, DLQ runbook). Not more features — extra features read as poor judgement.

Cut order: extra features → configuration breadth → non-benchmark optimization → admin/UI → persistence sophistication. Write down what you cut and why — a documented cut is a decision.

Decision log entry — five fields:

Decision · Alternatives (with numeric reasons) · Assumes · Would revisit if · Not tested

The last two are what make it interview-grade. Write one for every constant.

The seven interrogation classes: Choice ("why X not Y") · Magic number ("why 30 s") · Scale ("at 100×") · Data loss ("where can this lose a message") · Omission ("what didn't you test") · Regret ("what would you change") · Hostile ("this function does four things").

The closing move — unprompted: name the riskiest line in your own diff and the next thing you'd build. Volunteering your design's weakest point before it's found is the single most credibility-generating move in the round.

7. Behavioral

Taught in: tracks/behavioral/WARMUP.md

DTAO, not STAR — STAR buries the decision.

Context goes in a clause: "On the multilingual ranking pipeline, we decided X."

Four sentences that make it Staff:

1. "The decision was ___." (first)
2. "I rejected ___ because ___." (with a number)
3. "___ disagreed, and their argument was ___." (stated fairly)
4. "I got ___ wrong." (specific, generalizable lesson)

The test: if nobody disagreed, it isn't a Staff story.

Twelve required categories: cross-team architecture · a disagreement you lost · one you won · an outage you owned · a project you killed · raising a team's bar · a bet that failed · consensus without authority · deadline vs quality · changed your mind from data · non-engineers · what you'd build differently.

The disagreement-you-lost failure modes: humble-brag ("six months later they did it my way") · victim ("political reasons") · trivial · revisionist ("they were right about everything").

The seven probes — and the first is the discriminating one:

1. "What was their strongest argument?" ← if you can't produce one, the story is suspect
2. "What would have made the other option win?"
3. "Who else was affected that you didn't mention?"
4. "What did that cost the other team?"
5. "How much of the timeline was the disagreement?"
6. "How do you know it wasn't a coincidence?"
7. "What would you do differently?" ← never answer "communicate more"

Never: lead with situation · a story with no disagreement · strawman the opposition · say "we" throughout · present single-team as cross-team · perform humility or enthusiasm · over-rehearse (recited is audible).

8. Agentic Coding

Taught in: tracks/agentic/WARMUP.md

The eight steps: baseline first (pytest, record count + runtime) → read ≤10 min → write the plan (end state, 3–5 verifiable checkpoints, the invariant, what you'll do manually) → delegate in checkpoint units → verify every checkpoint, read the diff even when green → reject specifically → take over after two failed attempts on the same checkpoint → narrate continuously.

Prompt properties: scope ("do not modify other files") · contract (exact signatures + validation) · invariant ("all N existing tests pass; behaviour with X=None byte-identical") · verification ("add tests/test_x.py covering…") · domain knowledge it lacks ("close the response body before retrying or we leak connections") · negative space ("do not catch CancelledError — it's a BaseException").

Never re-prompt with "that didn't work." Say what failed, why it's wrong at a domain level, and what to do instead.

Take over when: two failures on one checkpoint · the invariant isn't expressible as a test · you need to understand it to defend it later · a plausible-looking wrong answer is worse than slow progress. Don't take over the 30-file rename — that's the inverse error.

A smaller verified diff beats a larger unverified one. One specific rejection is worth more than three accepted diffs.

9. The Scripts

Verbatim sentences worth having ready.

Coding — clarifying (pick the one that changes your representation):

"Are versions global or per key?" · "Is the source replayable and deterministic?" · "Will I need to undo this?" · "Do you want events returned per call or accumulated?"

Design — scoping, at minute 10:

"I think the two places this can actually fail are X and Y, so that's where I want to spend the time — does that match what you care about?"

Design — at-least-once, obligated follow-through:

"That selects at-least-once — which means job handlers must be idempotent, and I'll give each execution a stable idempotency key so they can be. Exactly-once execution of a side-effecting job isn't achievable without cooperation from the job itself, so I won't claim it."

Design — the zombie:

"I can't distinguish a dead worker from an unreachable one — that's a theorem, not a gap in my design. So I'm choosing at-least-once and making the duplicate safe with a fencing token checked at the storage layer."

Design — accepting a failure mode:

"If we lose a region mid-write, in-flight requests are lost. I'm accepting that: synchronous cross-region replication adds 80 ms to every write, which blows the 200 ms p99 for the 99.99% of the time there's no regional failure. I replicate async and expose an RPO of ~5 seconds. If the business needs RPO zero, that's a different design and a different latency budget."

Inference — the abstraction:

"I'll treat the inference engine as a service with three properties: capacity in tokens per second, an admission interface I can apply backpressure to, and streaming. I'll spend my time on traffic, coordination and failure — tell me if you want me to open it up."

Inference — the boundary of your knowledge:

"I don't know how you do this internally, so I'll reason from the public systems — PagedAttention, Orca's continuous batching, Sarathi's chunked prefill — and you can tell me where that diverges."

Deep dive — the closing move:

"Two things you haven't asked about. The riskiest thing in here is ___ — it's correct but it's where a future change silently breaks ___, and it's the least-covered path. And the thing I'd build next isn't a feature, it's ___."

Behavioral — a number you can't defend:

"I'll be honest that it's a judgement call rather than a measurement — if I had production data I'd set it from the observed distribution."

Any round — being wrong:

"You're right. (pause) The reason I did it that way was ___, which is a weak reason. What I'd do instead is ___."

Any round — a performance claim:

Either "I measured 2.8× on my harness at batch 32 with a 512-token prompt" or "vLLM's published benchmarks report 3–5×". Never assert an unattributed number.

10. Pre-Round Checklist

The week before

• ☐ Ask the recruiter the AI-tool policy, per round — policies are opposite at different labs
• ☐ Confirm the tooling (CoderPad? Excalidraw? their environment?) and practise in it
• ☐ Read the charter/core-views in a browser; fill the [VERIFY] slots
• ☐ Read their two most recent engineering posts; write one specific question about each
• ☐ Two consecutive full-loop sims at hire (staff) or better
• ☐ review/ queue clear, no leeches
• ☐ All six forward-looking answers rehearsed within 7 days

The morning of

• ☐ Read only this file's section for that round
• ☐ Timer visible · recorder on for practice, off for the real thing
• ☐ Water. Eat. The screen is two 60-minute rounds back to back and fatigue is measurable

In the first two minutes of any technical round

• ☐ Restate the problem
• ☐ Ask the question that could change your approach
• ☐ State scale assumptions out loud, with numbers
• ☐ Name what's out of scope

In the last two minutes

• ☐ State what you'd do next and why you didn't
• ☐ Name the weakest part of what you built
• ☐ Ask one of your three prepared questions

Every claim here is taught from first principles in the WARMUP guides, and every number is verified — see STATE.md for what was measured and when.

Glossary

Every term used anywhere in this program, defined in one or two lines, with a pointer to where it is taught properly. Alphabetical within sections.

If a term appears in a guide and is not here, that is a bug — log it in STATE.md.

Table of Contents

• Coding and Data Structures
• Python Runtime
• Distributed Systems
• Inference and GPU
• Process and Interviewing

Coding and Data Structures

Taught in tracks/coding/WARMUP.md

Amortized complexity — the average cost per operation over a long sequence, where an occasional expensive operation is paid for by many cheap ones. Lazy deletion plus a periodic rebuild is amortized O(1). §5.3

Arithmetic intensity — see Inference. Also the general idea: FLOPs per byte moved.

Backpressure — making a producer feel a consumer's slowness, so the signal propagates upstream to someone who can act. A bounded queue is the mechanism. §10.1

Bloom filter — a bit array plus k hashes. "Definitely absent" is exact; "possibly present" can be wrong. m = -n·ln(p)/(ln 2)² bits, k = (m/n)·ln 2 hashes. ~1.25 bytes/item at 1%. No false negatives, ever. §9.2

Carry buffer — the unconsumed tail of a chunk, prepended to the next one, so a token split across a boundary comes out whole. §6.1

Checkpoint (in a delta log) — a remembered position in the log, not a copy of state. Three integers. §2.2

Compaction — dropping versions no live reader can reach. Reachability from a pin set, exactly like a garbage collector's root set. §1.6

Consistent hashing — see Distributed.

Cuckoo filter — a Bloom-like filter that supports deletion, with better cache locality, at the cost of an insert path that can fail. §9.2

Delta log — recording what each operation changed rather than the resulting state. Deltas compose; snapshots do not. The representation that survives undo/redo/checkpoint requirements. §2.1

Eval breaker — see Python.

Fixed-delay vs fixed-rate — fixed-delay re-arms after a run finishes (never overlaps, schedule drifts). Fixed-rate fires on the original grid (can overlap; needs a catch-up policy). §5.4

Full / equal / decorrelated jitter — uniform(0, min(cap, base·2ⁿ)) · temp/2 + uniform(0, temp/2) · uniform(base, prev·3). AWS's simulation found full minimized both total work and completion time. §5.5

Head-of-line blocking — one slow item at the front stalling everything behind it, even when capacity is free. §4.1 (static batching), §10.2

Idempotency key — a stable identifier generated by the producer, unchanged across retries, that lets a consumer discard duplicates. Generate it at send time and dedupe silently does nothing. §9.1

Intrusive list — a linked list whose nodes are the payload objects, so a hash map can point directly at a node and unlinking is O(1). Requires double links. §3.1

Invariant-first — writing the assertion that pins the tricky property before implementing. The drill that stops you finding edge cases only when something breaks. §0.3

Lazy deletion — marking an element removed and skipping it when it surfaces, instead of finding and removing it. O(1) delete, with a rebuild threshold to bound the tombstone waste. §5.3

Leaky bucket — a queue drained at a constant rate; output is perfectly smooth, requests wait. Contrast token bucket, whose output is bursty and which rejects rather than queues. §4.5

Little's law — see Distributed.

LRU / LFU / TinyLFU — evict least-recently-used · least-frequently-used · admission control using a compact frequency sketch, which resists the scan-pollution that defeats LRU. §3.7

Lookahead window — a bounded forward search that makes a streaming diff O(1) amortized instead of needing the whole input. The price is that a skip longer than the window is misreported. §2.4

MVCC — Multi-Version Concurrency Control. Keep multiple versions per key; readers never block writers because writes only append. §1.7

Myers diff — the O(ND) shortest-edit-script algorithm git diff uses. Needs the whole input, which is why it cannot be used online. §2.4

Negative caching — caching the absence of a key for a short TTL. A DoS mitigation, not a performance optimization. §3.5

Postings list — for a term, the set of documents containing it. Intersect the smallest first. Text-index gate 1

Predecessor query — "the largest key ≤ X". Also called floor or as of. The tell that you need an ordered structure. §1.1

Sampled expiry — checking a small random sample for expiry on each write, instead of a full sweep. Redis's design. Lazy alone leaks; sampled bounds it in O(1) amortized. §3.3

Segment (index) — an immutable slice of an index. Writes accumulate in a mutable buffer; flush seals it; merge reclaims tombstoned space. Lucene's design. Text-index gate 4

Sentinel node — a permanent, dataless head/tail node that makes every real node have non-None neighbours, removing every linked-list edge case. §3.2

Single-flight — on a miss, exactly one caller runs the loader and the rest wait for that result. Prevents a cache stampede. §3.5

Sliding window counter — two fixed-window counts interpolated by how far into the current window you are. O(1), no boundary burst, ~1% error on real traffic. §4.3

Sliding window log — every request's timestamp, trimmed to the window. Exactly correct, O(limit) memory per key. The correctness baseline. §4.2

Stampede (cache / dogpile / thundering herd) — N concurrent misses on one key hitting the backing store simultaneously, at the moment the cache was supposed to protect it. §3.5

Three-colour DFS — WHITE unvisited / GREY on the current stack / BLACK done. Reaching GREY is a back edge, i.e. a cycle. Two states conflate "on my path" with "finished". §7.2

Time-to-first-passing-gate — the metric that predicts a gated coding round, because an unopened gate scores zero. §2.5 of the Track A README

Token bucket — tokens accrue at rate and cap at capacity; a request spends one. Separates sustained throughput from burst tolerance — the thing no window can express. §4.4

Tombstone — a marker recording that something was deleted, rather than removing it. Required whenever history or immutability matters. §1.4

Torn write — a partial record at the tail of a log after a crash. The expected post-crash state, not an error. §8.2

Walking skeleton — an end-to-end path working with the simplest possible everything, early. The take-home's hour-8 milestone. Track E §1.1

Write-ahead log (WAL) — append the intent durably before mutating the main structure, so recovery replays. [len][payload][CRC]. §8.1

Write skew — see Distributed.

Python Runtime

Taught in tracks/python-internals/WARMUP.md · QUIZBANK.md

aclosing — contextlib.aclosing, which guarantees an async generator's finally runs at scope exit. Without it, cleanup waits for loop.shutdown_asyncgens(), which under load is a connection leak. §3.6

Arena / pool / block — CPython's allocator hierarchy: 256 KB arenas → 4 KB pools (one size class each) → fixed blocks. An arena returns to the OS only when every pool in it is empty, which is why freeing does not lower RSS. §5.1

BaseException vs Exception — CancelledError, KeyboardInterrupt and SystemExit derive from BaseException, so except Exception deliberately misses them. §3.3

Bound method — what a function's __get__ returns: the function partially applied to the instance. self is the descriptor protocol, not magic. §6.2

Buffer protocol — the C-level interface for sharing memory without copying. What memoryview, socket.recv_into, struct.unpack_from and numpy use. §5.4

Cooperative cancellation — CancelledError is delivered at a suspension point, so a task with no await cannot be cancelled. §3.3

Coroutine / Task / Future — inert object from async def · a coroutine wrapped so the loop steps it concurrently · a placeholder for a later result (Task subclasses Future). §3.2

Cycle collector — generational mark-and-sweep over container objects, needed because refcounting cannot free mutual references. §1.4

Data vs non-data descriptor — defines __set__/__delete__ (outranks the instance dict) vs only __get__ (the instance dict outranks it). Explains why @property can't be shadowed and a method can. §6.2

Eval breaker — the flag that hands the GIL to another thread. Since CPython 3.10 it is checked only at specific instructions (backward jumps, calls), which is why the textbook lost-update demo often loses nothing. §4.3

ExceptionGroup / except* — how TaskGroup reports multiple simultaneous child failures. 3.11+. §3.4

Free-threaded build — CPython without the GIL. PEP 703 designed it, PEP 779 defined "supported", Phase II in 3.14: officially supported, not default. §4.4

Generational hypothesis — most objects die young, so collect the youngest generation most often. §1.4

GeneratorExit — thrown at a suspended yield by close(), which is how a generator's finally runs. Catching it and yielding again is a RuntimeError. §2.4

GIL — a mutex letting one thread execute CPython bytecode at a time. Protects interpreter internals, not your invariants. §4.1

Key-sharing dictionary (PEP 412) — instances of a class share the key layout, which already narrowed the __slots__ saving. Hence: measure. §5.2

Managed dict — since 3.11 the instance __dict__ is created lazily, so a class that could have one costs nothing until something is stored in it. §5.2

memoryview — a zero-copy view over a buffer. Slicing it allocates nothing; slicing bytes copies. A live view pins the underlying bytearray. §5.4

MRO / C3 linearization — the method resolution order, computed so a class precedes its bases, declaration order is preserved, and the result is monotonic. §6.4

Orphaned task — a task left running after gather propagated a sibling's exception. A resource leak, not a style difference. §3.4

Priming (a generator) — advancing to the first yield with next() so send() has an expression to deliver into. §2.4

pymalloc — CPython's small-object allocator, used for allocations ≤512 bytes. §5.1

Refcounting — freeing an object the instant its count hits zero. Prompt and deterministic; cannot collect cycles. §1.3

Resurrection — a __del__ storing self somewhere and reviving an object mid-finalization. One of several reasons to prefer weakref.finalize. §1.5

__slots__ — replaces the per-instance __dict__ with fixed offsets. Removes weakref support too unless you add '__weakref__'. A subclass omitting it regains a __dict__. §5.2

Structured concurrency — no task outlives its scope. TaskGroup's guarantee, and why it is a bug fix rather than a style preference. §3.4

Suspended frame — what a generator object holds: locals, instruction pointer, evaluation stack. Why a generator is a state machine. §2.3

tee — itertools.tee, which buffers everything one branch has read that the other has not. Draining one branch materializes the whole stream. §2.6

tracemalloc — attributes real allocations to source lines. The right tool, since sys.getsizeof measures only an object's own footprint. §5.3

weakref.finalize — cleanup tied to an object's lifetime that does not keep it alive. Beats __del__: defined ordering, exceptions not swallowed, no resurrection. §1.5

yield from — delegates iteration, forwards send/throw/close, and makes the sub-generator's return value the value of the expression (PEP 380). §2.5

Distributed Systems

Taught in tracks/systems-design/WARMUP.md

Admission control — deciding at the edge what not to serve, cheaply, before it consumes a resource. §10.3

AIMD — additive increase, multiplicative decrease. TCP's congestion law, applied to application concurrency limits: +1 when healthy, ×0.8 on failure. Track A §10.4

Anti-entropy — a background process reconciling divergent replicas, usually with a Merkle tree so the comparison is O(log n) in the difference. §5.4

At-most-once / at-least-once / exactly-once — no retries (can lose) · retry until acked (can duplicate) · impossible for delivery; achievable for processing via an idempotent consumer. §9.1

Back edge — an edge to a node on the current DFS stack, i.e. a cycle. Coding §7.2

Blast radius — how much of the system a failure can affect. Bulkheads and cells shrink it by construction. §10.4

Bulkhead — separate resource pools per dependency, so exhaustion in one cannot starve others. Costs pooling efficiency (M/M/c). §10.4

CAP — when a partition occurs, choose consistency or availability. Only during a partition, and "available" means every non-failing node responds. See PACELC. §7.5

Cellular architecture — partitioning the whole stack into independent cells each serving a slice of users, so blast radius is 1/N. §10.4

Circuit breaker — closed → open (fail immediately) → half-open (a small number of probes). Threshold must be a rate over a minimum volume. §10.2

Clock skew — the difference between two machines' wall clocks. NTP holds a few ms on a good LAN — statistical, not a bound, and a node cannot know its own skew. §3.2

Commit-wait — Spanner deliberately waiting out the TrueTime uncertainty window before releasing locks, which is how timestamps become globally meaningful. §3.6

Consistent hashing — mapping keys and nodes onto a ring so adding or removing a node moves only K/N keys instead of ~80%. §8.2

CRDT — a data type whose merge is commutative, associative and idempotent, so replicas converge with no coordination. Convergence is not correctness: a CRDT counter for inventory can go negative. Ch. 11

Deadline propagation — passing the remaining time budget downstream so any hop with insufficient time fails immediately instead of starting work it cannot finish. §10.3

Dead-letter queue (DLQ) — where a message goes after N failures. Needs four things: the reason, a replay path, poison detection, and an alert on arrival rate. §9.4

Dual write — writing to two systems that fail independently (db.save then queue.publish). No ordering is safe. Fix with the outbox. §9.2

Fail-stop vs fail-slow — the node stops (easy) vs it keeps answering, slowly or wrongly (harder, and the common case). Detect fail-slow with latency percentiles vs peers. §2.2

Fencing token — a monotonically increasing number issued with each lease, checked by the resource, that makes a zombie's stale write rejected without anyone detecting the zombie. The highest-value item in the track. §4.3

FLP impossibility — in a fully asynchronous system with one faulty process, no deterministic algorithm guarantees consensus. Practical systems buy liveness with timeouts and keep safety unconditional. §6.1

Gray failure — see fail-slow.

Happens-before (→) — Lamport's causal ordering. If neither a→b nor b→a, the events are concurrent, which is a real relationship, not an unknown. §3.3

HLC (hybrid logical clock) — a physical component tracking wall clock plus a logical counter. Close to real time, respects causality, O(1) size. Cannot detect concurrency. §3.5

Idempotent — an operation whose repetition has no additional effect. What makes at-least-once tolerable. §9.1

Lamport timestamp — one counter per node, max(local, received)+1 on receive. Gives a total order consistent with causality; cannot detect concurrency. §3.3

Lease — a lock with a timeout, so a dead holder does not block forever. Renew at lease/3. §4.1

Linearizability — the system behaves as if there were one copy and each operation took effect atomically at some instant between invocation and response. A recency guarantee about single objects. §7.1

Little's law — L = λW. Concurrency = arrival rate × time in system. Needs almost no assumptions, which is why it applies everywhere. §1.1

Load shedding — rejecting work to protect the rest. Shed by priority, and shed the oldest queued item. §10.3

Log matching — Raft's invariant: two logs with the same index+term are identical up to that point. What makes recovery simple. §6.3

Merkle tree — a hash tree over a key range; equal roots mean identical data, so comparison costs one hash in the common case. §5.4

Outbox pattern — insert the event into an outbox table in the same transaction as the state change; a relay publishes it with FOR UPDATE SKIP LOCKED. Solves the dual write. §9.3

PACELC — if Partition then A or C, Else Latency or Consistency. The more useful framing, because it names the tradeoff you make every day. §7.5

Quorum — W + R > N forces the read set and write set to overlap. §5.2

Raft term — a logical clock; at most one leader per term; seeing a higher term makes you step down. §6.2

Read repair — writing the newest value back to stale replicas discovered during a read. Cheap, but never repairs cold data. §5.4

Retry budget — capping retries at a fraction of base traffic, so amplification is bounded no matter how bad things get. The primary fix, before circuit breakers and before jitter. §10.1

Retry storm — retries multiplying offered load onto a dependency that is already failing. ~2.85× at a 95% failure rate with 3 attempts. §10.1

Serializability — the outcome equals some serial order of the transactions. An isolation guarantee about transactions, saying nothing about real time. §7.2

Sloppy quorum — accepting writes at any W reachable nodes during a partition, which breaks the overlap guarantee. Dynamo does this deliberately. §5.3

Snapshot isolation — every transaction reads a consistent snapshot; commits validate. Permits write skew. §7.4 and Coding §1.7

Split brain — two nodes both believing they hold authority. Prevented by fencing, not by detection. §4.2

SSI (serializable snapshot isolation) — tracks read-write dependencies and aborts dangerous structures. Postgres's SERIALIZABLE. §7.3

Strict serializability — serializable and respecting real time. The most expensive guarantee; Spanner. §7.3

Timer wheel — O(1) insert and O(1) tick scheduling, used by the Linux kernel and Kafka's purgatory. The 100× answer for a polling scheduler. d01 §9

TrueTime — Spanner's clock API returning an interval guaranteed to contain the true time, narrowed by GPS and atomic clocks. §3.6

Two Generals — the impossibility argument behind exactly-once delivery. §9.1

Vector clock — one counter per node, compared element-wise. Detects concurrency, at O(nodes) size and with subtle pruning. §3.4

Virtual node — many ring positions per physical node. Evens load and, more importantly, spreads a failed node's range across many successors instead of dumping it on one. §8.3

Write skew — two transactions read overlapping data, write disjoint keys, both commit, and jointly violate an invariant neither violated alone. The anomaly snapshot isolation permits. §7.3

Zombie (lease holder) — a process that paused past its lease, woke, and writes as if no time passed. Undetectable — fencing is the answer. §4.2

Inference and GPU

Taught in tracks/ml-infra/WARMUP.md

Activations — transient per-forward-pass memory. Reserve a few GB per GPU; a real number comes from profiling. §3.4

Arithmetic intensity — FLOPs per byte moved. Below machine balance (P/B) you are memory-bound; above it, compute-bound. §2.1

Chunked prefill — splitting a long prefill across scheduler steps so decode never stalls for a whole prefill. Trades a little prefill throughput for much better TTFT/TPOT tails. Sarathi-Serve. §4.4

Continuous / in-flight batching — scheduling at iteration granularity, so a finished sequence's slot refills on the next forward pass. Orca. The single biggest throughput lever. §4.2

Decode — generating tokens one at a time, each depending on the last. Memory-bandwidth-bound. Determines TPOT. §1.3

Disaggregated prefill/decode — running the two phases on different machines with different hardware, transferring the KV cache. DistServe. §5.5

Expert parallelism (EP) — placing MoE experts on different GPUs. Needs an all-to-all per MoE layer; expert load imbalance is the hot-partition problem again. §5.4

GQA / MQA — Grouped- / Multi-Query Attention: several query heads share one KV head. 8× smaller KV cache for Llama-70B. The architectural decision that makes long context affordable. §3.3

KV cache — cached K and V per token per layer, so generating token n is O(1) new work instead of O(n). The object in LLM serving, and the binding capacity constraint. §1.2

Machine balance — peak dense FLOP/s ÷ bandwidth. ~295 FLOP/byte on an H100 (989.5 TFLOP/s ÷ 3.35 TB/s). The datasheet's 1,979 TFLOP/s is the with-2:4-sparsity figure and does not apply to dense LLM weights. §2.1

Model parallelism — see TP / PP / EP. §5.4

PagedAttention — KV cache in fixed-size non-contiguous blocks with a per-sequence block table. Virtual-memory paging applied to the cache; removes internal and external fragmentation and enables copy-on-write prefix sharing. vLLM. §4.3

Pipeline parallelism (PP) — splitting layers across GPUs. Tolerates slower interconnect, works across nodes, introduces bubbles, does not improve single-request latency. §5.4

Prefill — processing the prompt, all tokens in parallel. Compute-bound. Determines TTFT. §1.3

Prefix caching — reusing KV blocks for shared prompt prefixes. Turns a 20-turn conversation's O(n²) prefill into O(n). Must be tenant-scoped or it is a cross-tenant leak. §5.1

Quantization — fewer bits per weight (or per KV entry). Helps decode twice: fewer bytes to read and more room for batch. Degradation is workload-specific — evaluate, don't assume. §5.3

RadixAttention — SGLang's radix-tree organization of the prefix cache, so partial matches are found efficiently. §5.1

Roofline — the model that says performance is bounded by min(compute, bandwidth × intensity). Williams et al., 2009. Ch. 2

Speculative decoding — a draft model proposes k tokens, the target verifies all k in one pass, and the output distribution is provably identical. Wins at low batch; loses at high batch because there is no spare compute. §5.2

Tensor parallelism (TP) — splitting each layer's matrices across GPUs. All-reduce every layer → needs NVLink → within a node. Improves latency. §5.4

TTFT / TPOT — time to first token (set by prefill and queueing) / time per output token (set by decode). They trade against each other, which is the whole scheduling problem. §1.3

Process and Interviewing

Anti-narrowing clause — the rule that one candidate account must not narrow preparation into a blind spot: ~25% off-report material, a six-component onsite, company-agnostic core. source-report.md

Confident-wrong — an answer you were sure of and got wrong. Scored separately because it is a landmine, not a study item: you will assert it and be corrected. RUBRIC.md

Decision log — a running decisions.md written while building: decision, alternatives with numeric reasons, assumptions, would-revisit-if, and not-tested. Track E §2

DTAO — Decision, Tradeoff, Alignment, Outcome. Replaces STAR, which buries the decision. Track F

Epistemic ladder — confirmed (primary/verifiable) · reported (candidate accounts, prep vendors) · inference (mine, labelled). Only the first is safe to assert. findings.md

Gate — one stage of a progressive coding problem. Gate N+1 stays closed until gate N passes. Track A

Hire-bar scale — no hire / hire (senior) / strong hire (senior) / hire (staff) / strong hire (staff). Every mock is scored on this, calibrated to Staff. mocks/

L0–L3 — the per-track level from the diagnostic: foundations missing · correct but slow · interview-passable at senior · staff-altitude. Drives hour allocation. RUBRIC.md

Leech — a review item that has reset to the 1-day interval three or more times. A comprehension problem, not a memory one — stop drilling and re-learn the mechanism. review/

Progressive format — the reported onsite coding round: ~4 gates, each gated on the previous working, reported pass bar 2 (assume 3). findings.md

Spaced repetition — resurfacing at 1, 3, 7, 21 days. Wrong at any interval resets to 1. review/

Time-to-first-passing-gate — the metric that predicts a gated round, because an unopened gate scores zero. Track A

References

• CHEATSHEET.md — the same material, dense, organized for the morning of a round
• README.md — the program entry point
• research/findings.md — what is confirmed vs reported vs inferred

Hands-On Miniatures

Five designs from this program, built as running code and measured. Each page is a sequence of blocks — a block builds one mechanism, proves it works in isolation, and hands what it made to the next — followed by an assembly that wires them into one working thing.

Every number on every page came from executing the code. The generator runs each script and splices its stdout; nothing is transcribed. Regenerate and any number that drifted changes on the page.

And every claim is checkable. --verify re-derives each headline number from a second, independent implementation and asserts it — 58 claims across the five pages, all run in CI. A page cannot quietly stop being true.

Every block is also triggerable. Each carries a Try it yourself snippet that the generator executes at build time — importable, copy-pasteable, and impossible to leave broken, because a snippet that raises fails the build.

Table of Contents

• Why These Exist
• The Five Pages
• Where the Measurement Refuted the Prose
• Running Them
  • Inline examples that cannot rot
  • What --verify is for
• How a Page Is Built
• References

Why These Exist

The design pages in Track C and Track D are prose: nine sections, a hostile critique, a revision. They are the right shape for rehearsing an interview, and they have one gap — you can read a design doc and retain nothing you could defend under a follow-up.

A hands-on page closes that gap by making the mechanism run. When an interviewer asks "how much does the fixed window actually let through at the boundary" or "what does a lease cost you when the holder pauses", the difference between a remembered claim and a measured one is audible.

These are not substitutes for the design pages. Work the design cold, then build the mechanism, then read the annotation. The gap between what you predicted and what the code printed is the finding.

The Five Pages

Suggested order: C03 first (smallest surface, sharpest failure), then C11 (the highest-value single concept), then C05, C01, M02.

Where the Measurement Refuted the Prose

The reason these are worth reading rather than skimming is that several of them contradict something the first draft asserted, and the contradiction stayed on the page with the experiment that produced it.

Running Them

cd swe-interview-prep/handson

python3 c03_rate_limiter.py            # every block, then the assembly
python3 c03_rate_limiter.py --block 3  # one block and its prerequisites
python3 c03_rate_limiter.py --quiet    # the assembly only
python3 c03_rate_limiter.py --verify   # re-derive and assert every claim

python3 build_pages.py                 # regenerate every page from real output
python3 build_pages.py c11             # regenerate one
python3 test_handson.py                # 24 tests over all five pages

All five scripts are dependency-free standard-library Python, run in under a second each, and touch neither the network nor the filesystem. Fixed seeds throughout, so the pages are reproducible: if a number changes, the code changed.

Inline examples that cannot rot

Every block carries a Try it yourself snippet that the generator executes at build time, splicing in the real output. They are importable and copy-pasteable:

from c03_rate_limiter import parts
FixedWindow = parts()["FixedWindow"]      # every mechanism a page builds

A snippet that raises fails the build; one that prints nothing fails the tests. Writing them caught three errors in the surrounding prose — an example that claimed to straddle a window boundary and did not, a Little's-law queue cap compared against a p99 when the law gives a mean, and a block-table entry count off by 10×. All three are now stated correctly because the code ran.

What --verify is for

Captured output is reproducible but not necessarily right — a wrong measurement reproduces perfectly. So each script also carries a verify() that recomputes its headline numbers from a second implementation, independent of the blocks, and asserts them:

  [PASS] B4  sliding counter's worst case approaches 2x, like the fixed window  measured 1.99x at a 0.99s gap
  [PASS] B4  counter error is zero under the limit                              0.00% at 0.5x offered load
  [PASS] B4  ...and 15-25% at or above it                                       23.29% at 1.5x offered load

  10/10 claims verified

A block with a bug cannot make its own claim pass, and --verify exits non-zero on any failure — so test_handson.py runs all five in CI and the prose on these pages is checkable rather than merely assertable.

How a Page Is Built

handson/
  _harness.py            @block, run_all, check; --block N, --quiet, --verify
  build_pages.py         the generator; PAGES registry at the top
  test_handson.py        24 tests: scripts, claims, examples, annotations, freshness
  <name>.py              the script: N blocks + an assembly + verify()
  notes/<slug>.md        per-block annotation, split on '### B<n>'
  deep/<slug>.md         page-level deep dive, appended after the assembly
  <slug>.md              GENERATED — never hand-edit

Each page opens with Run it (the commands, the expected runtime) and Predict before you read (six numbers to guess first — the gap between your guess and the measurement is the point), and closes with Verify the claims (the captured --verify table).

Each rendered block is five parts: the claim (from the @block decorator), the problem (from notes/), the code (sliced from the .py), reading the implementation (from notes/), the captured output, and what the numbers say / beyond the toy (from notes/). A note may place <<<CODE>>> and <<<OUTPUT>>> to control the layout; whatever it omits is appended.

The bar for an annotation: a reader who already knows the mechanism should still learn something. If a paragraph could have been written without running the code, it does not belong.

Full build spec, conventions and the verification checklist: HANDOFF.md.

References

• Track C — the twelve worked designs
• Track D — the eight ML-infrastructure designs
• The cross-cutting concept map — which mechanism recurs where
• Track A follow-up bank — the spoken versions
• HANDOFF.md — the build spec for adding a page

The Cross-Cutting Map

Six mechanisms account for most of what the five hands-on pages measure, and each shows up on three or more of them wearing different clothes. Recognising the same mechanism across substrates is the transferable skill; the pages are only where it was measured.

Table of Contents

• The Six Recurring Mechanisms
• 1. The Ack Position, and Why There Is No Third
• 2. Time-of-Check to Time-of-Use
• 3. Fencing and Epochs
• 4. The Saturating Signal
• 5. Reserved Floors Over Strict Priority
• 6. Approximate in Fast Memory, Exact in Slow
• The Numbers Worth Memorising
• What Every Page Ends Up Saying

The Six Recurring Mechanisms

1. The Ack Position, and Why There Is No Third

The shape: an effect and a record-that-the-effect-happened are two events. One must come first. A failure between them is the only failure, and which side you lose on is decided entirely by the ordering.

Why it matters: candidates try to find a third position. There is not one — this is the two-generals result, and recognising it saves the ten minutes otherwise spent inventing a protocol that cannot exist.

What to do instead: pick at-least-once and make the second application a no-op. C01 B3 measures that it works; B5 measures the one condition it requires — the dedup key must be written in the same transaction as the effect, or the window has only moved.

2. Time-of-Check to Time-of-Use

The shape: a check establishes a fact about the past; the action depends on a fact about the present. Any delay between them is a window, and the window's size is a latency you usually do not control.

The rule: a check and the effect it guards must be atomic, which means they must happen at the same component. Any design where X validates and Y acts has this window.

How to find it in a design: ask which component orders the operations. That is the one the check belongs in. In C03 it is Redis (INCR, not GET-then-SET); in C11 it is the resource (fence check inside the write); in C01 it is the database (dedup key in the same transaction).

3. Fencing and Epochs

The shape: any identity that can be reused, superseded or restarted must carry a monotonically increasing number, and the component that acts on the identity must reject anything below the highest it has seen.

The measured claim (C11 B3): with fencing, the stale writer's update is rejected and the correct value survives — and it is rejected without the resource talking to the lock service, which is what makes it robust to the lock service being slow, partitioned or down.

The honest limit (C11 B3, beyond the toy): fencing requires the resource to cooperate. A third-party API will not check your token. When it cannot, you do not have a safe design — you have a probabilistic one, and the correct move is to say so and reach for idempotency instead.

4. The Saturating Signal

The shape: the metric everyone reaches for is bounded above, and it saturates exactly at the point where you need it to keep moving.

The general form: the utilisation of a resource is not the scarcity of that resource. A signal fit for shedding must be unbounded above and must lead rather than trail. Error rate fails the second test; utilisation fails the first.

5. Reserved Floors Over Strict Priority

The shape: two classes contend; strict priority protects the top class by starving the bottom one to zero, and zero is not a degradation, it is an outage for that class.

C05 B6 measures the middle ground: a floor recovers 87% of strict priority's gain for the top class while taking the bottom class from 5.8% to 39.2%.

The question to ask whenever a design reaches for priority: what is the bottom class guaranteed? If the answer is "nothing", it will eventually get nothing — and the guarantee you can write in a contract is the floor, not the priority.

6. Approximate in Fast Memory, Exact in Slow

The shape: an exact answer is expensive; a cheap approximate test that is wrong in only one direction guards it.

The direction is the whole design. A Bloom filter used the wrong way round — treating "probably seen" as "seen" — skips a job, which is data loss. The same structure is safe or unsafe depending only on which way the error points, and C01 B4's beyond the toy is the worked version.

The Numbers Worth Memorising

These come up in more than one round, and every one was measured on its page.

What Every Page Ends Up Saying

Read together, the five reach the same conclusion from five directions:

Put the check where the ordering happens, and make the failure cheap rather than rare.

• C01: the dedup key goes in the transaction that performs the effect — not in the worker, not in the queue.
• C03: the decrement goes in the store that orders the requests — one INCR, not GET-then-SET.
• C05: the deadline check goes at dequeue, where the capacity is about to be spent — not at enqueue, where nothing has waited yet.
• C11: the fence check goes in the resource that orders the writes — not in the client that is about to be descheduled.
• M02: the admission check goes on KV occupancy, the resource that actually binds — not on the utilisation metric that saturates.

And in each case the second half matters as much as the first. C01 does not prevent duplicates, it makes them no-ops. C05 does not prevent overload, it makes the failure a countable drop instead of an invisible 18-second queue. C11 does not prevent zombies, it makes their writes harmless. A design that makes the bad case cheap beats one that makes it rare, because rare failures are the ones nobody has tested.

PLAN — 26 Weeks, 22 Hours a Week

⚠ Personalized allocation is LOCKED pending diagnostic scores

Everything on this page marked FIXED is decided and will not change. Everything marked PENDING is deliberately blank, because writing it now would mean guessing your level — and a plan optimized for a person who does not exist is worse than no plan.

Unlock it by taking the baseline diagnostic and reporting your scores. Three hours. It is the single highest-leverage thing you can do this week.

Table of Contents

• What Is Decided and What Is Not
• The Budget
• FIXED: The Six Phases
• FIXED: The Milestone Calendar
• FIXED: The Weekly Rhythm
• FIXED: The Invariant Rules
• PENDING: Hour Allocation
• PENDING: Week-by-Week
• How Rebalancing Works
• If the Timeline Compresses
• References

What Is Decided and What Is Not

The Budget

2h × 5 weekdays  +  6h × 2 weekend days  =  22 h/week
22 h/week × 26 weeks                      ≈  570 hours

Six months is enough to do this properly rather than to triage. Concretely, what 570 hours buys that 12 weeks would not:

• Both 48-hour take-homes plus both deep-dive interrogations (Track E generalizes rather than being memorized)
• A real portfolio artifact with measured numbers, built without a clock
• Track D from first principles rather than from vocabulary
• Six diagnostic re-tests, so the plan is corrected five times rather than never
• Enough spaced repetition for month-one material to survive to month six

FIXED: The Six Phases

Each phase has an exit criterion. You do not advance on the calendar; you advance on the criterion. If a phase runs long, the following phases compress — and the milestone dates below are the compression budget.

Phase 1 — Calibrate (weeks 1–2)

Establish ground truth and build the daily habits. Baseline diagnostic, first harness runs, first design written, story-bank extraction begins, Charter and engineering-blog reading done and recorded.

Exit: diagnostic scored, levels assigned, PLAN.md unlocked, one full gated harness run completed, one design artifact written.

Phase 2 — Foundations (weeks 3–8)

Rebuild whatever the diagnostic says is weak. Heaviest phase for Tracks A and B. Track C's mandatory designs (d01 job scheduler, d02 distributed KV). Track D begins from the roofline derivation. Weekly mocks start.

Exit: time-to-first-gate ≤ 12 min consistently · d01 and d02 written and survived critique · the decode-bandwidth derivation reproducible from memory · 8+ stories in the bank.

Phase 3 — First Take-Home (week 8, inside Phase 2)

The 48-hour webhook build, on a real clock, followed by the deep-dive interrogation.

Exit: shipped, frozen, interrogated, scored. Every undefendable answer in review/.

Phase 4 — Depth (weeks 9–16)

Track D to full depth at both altitudes. The remaining ten designs. Track G begins. Portfolio artifact starts. Back-to-back mocks become routine.

Exit: "design ChatGPT" at hire (staff) in a scored mock · 8+ designs written · 3+ Track G tasks scored · portfolio artifact producing real numbers.

Phase 5 — Second Take-Home and Generalization (week 16)

Different domain, same 48-hour discipline, second interrogation. This is where Track E stops being memorization.

Exit: second project shipped and interrogated, with the score better than the first.

Phase 6 — Loop Readiness (weeks 17–26)

Full-loop simulations monthly. Every track to maintenance except the weakest. Behavioral and forward-looking answers rehearsed to fluency. Numbers sheet memorized. The portfolio artifact finished and written up.

Exit: two consecutive full-loop simulations at hire (staff) or better in every round.

FIXED: The Milestone Calendar

Weeks 8 and 16 are the immovable ones. Everything else can shift a week; those cannot, because they need a clear 48-hour block booked in advance and they gate the deep-dive drills that follow them.

FIXED: The Weekly Rhythm

The shape that makes 22 hours sustainable for six months. Track content is pending; the shape is not.

Two structural decisions worth naming:

The daily anchor is non-negotiable and deliberately small. Twenty-five minutes survives a bad day. The single biggest risk to a six-month plan is not a bad week — it is the bad week that becomes a bad month because the habit broke. A 25-minute floor is one you can hit while travelling, while sick, or on a launch week.

Behavioral gets a fixed weekly slot from week 1, not a cram in week 24. Reported sources name the values round as the leading failure mode at a peer lab, and it is the thing senior engineers most reliably under-prepare because it does not feel like real work.

FIXED: The Invariant Rules

These do not change regardless of your diagnostic profile.

1. Reading never completes anything. Only a passed drill, a working artifact, or a scored mock does.
2. Every miss enters review/ at the 1-day interval and resurfaces at 1, 3, 7, 21 days.
3. One scored mock every week. From week 9, at least one back-to-back per month. From week 17, at least one full-loop per month.
4. Score down when unsure. A generous rubric is the one thing that guarantees you fail the real loop.
5. Every performance claim has a script. If a note asserts a number, there is a file that measures it.
6. STATE.md updated at the end of every session. Assume the next session starts cold and reads only that file.
7. Commit at every milestone, with a real message.
8. Re-run Phase 0 research at each diagnostic. If something newer and better-sourced than the source report appears, supersede it.
9. Re-run the coverage audit at each diagnostic. No row goes unaddressed.

PENDING: Hour Allocation

Filled in from your diagnostic. The baseline column is the starting point; the actual column is computed from your levels per diagnostics/RUBRIC.md.

Track E is fixed because it is two 48-hour blocks plus two interrogation drills — a schedule, not a dial.

Three of seven tracks are unmeasured by the baseline, by design: a three-hour battery cannot measure a 48-hour take-home. So the first month's allocation for D, E and G is provisional and gets its first real correction at the week-4 re-test.

PENDING: Week-by-Week

Twenty-six rows, generated once the levels are known. Each row will carry: the primary track, the specific drills, the milestone if any, and the mock type.

Not written yet, deliberately. See the banner at the top of this file.

How Rebalancing Works

At each of the six diagnostic re-tests:

1. Take the battery cold; score it; add the rows to diagnostics/scores/.
2. Recompute levels per the rubric.
3. Any track that reaches L3 drops to its L3 share; the freed hours go to the lowest-level track.
4. Re-run the coverage audit and the Phase 0 search.
5. Rewrite the remaining week-by-week rows.

This is the mechanism that stops a six-month plan from becoming a six-month ritual. A plan that is never corrected is a plan that stopped being about you somewhere around week five.

If the Timeline Compresses

If an interview lands earlier than week 26, the triage order is fixed in advance so the decision does not have to be made under pressure:

In the 2-week case, learn nothing new. Rehearse what you have, sleep properly, and take the loop. Cramming new material in the final fortnight reliably costs more in fluency and confidence than it adds in coverage.

References

• diagnostics/README.md — the thing that unlocks this file
• diagnostics/RUBRIC.md — how levels become hours
• tracks/README.md — what each track contains
• mocks/README.md — the weekly scoring protocol
• STATE.md — where you are right now
• research/findings.md — what this plan is built against, with epistemic labels

STATE — Progress Ledger

Read this file first. Every session starts cold and reads only this. It is updated at the end of every session with: what we did, the scores, what is next, and what is blocked.

Table of Contents

• Right Now
• Your Next Action
• Blocked On You
• Levels
• Session Log
• Build Backlog
• Mock Scores
• Milestone Tracker
• Pre-Interview Checklist

Right Now

Your Next Action

Take the 3-hour baseline diagnostic.

Book one uninterrupted block. Timer visible, recorder on, no AI, no search, no docs.

Then score against RUBRIC.md, record in scores/, and report the numbers. PLAN.md unlocks the moment I have them.

Blocked On You

Things I cannot do without input from you. Each blocks something real.

Levels

Assigned from the diagnostic. Blank until it is taken.

Session Log

Newest first. One entry per working session.

2026-07-31 — Session 7: Track G's diff bank

Did: wrote tracks/agentic/DIFFBANK.md — 30 agent-produced diffs to accept, reject or revise in 90 seconds each, extending the five in the warmup. Track G was the thinnest track and its core skill — deciding what the agent produced is safe to ship — had five examples. Eight categories, a six-pass review ordered by how cheaply each pass finds a fatal problem, and a ranked taxonomy of what agents actually get wrong.

Two structural additions that matter more than the diffs:

• Section H — "Looks Wrong, Is Right". Reflexive rejection is a scored failure and the bank now tests for it directly. An engineer who rejects all thirty scores worse than one who accepts the three that are correct.
• "The Things You Cannot See in a Diff." git diff --stat first, every time; and after the agent's tests pass, break the implementation and confirm the test fails. Thirty seconds, directly targets what agents are worst at, and almost nobody does it.

The measurement that changed a section: the folk rule "s += x in a loop is O(n²)" is false on CPython — measured 1.5× vs join and linear at n up to 500k, because unicode_concatenate resizes in place at refcount 1. Hold one extra reference and it becomes 300× at n=50k and quadratic. So the diff is ACCEPT-with-a-precondition, not REJECT — and the transferable point is that a performance rule resting on an interpreter optimization must be stated with its precondition.

Next: unchanged — the diagnostic.

2026-07-31 — Session 6: Track A's follow-up bank

Did: wrote tracks/coding/QUIZBANK.md — 150 questions asked after your code works, the Track A counterpart to Track B's quiz bank. Fourteen sections, one per WARMUP chapter plus complexity, testing and concurrency, each mapped to the harness problem it attaches to. Opens with the six shapes of follow-up, because misclassifying the shape is how a correct answer becomes an irrelevant one, and closes with the twenty that recur most.

Every measurable claim was measured on 3.13 rather than asserted, and three came out somewhere other than where I expected:

• list.pop(0) vs deque.popleft at n=100k: 15,895 ns vs 40.7 ns — 390×.
• flush() vs flush()+fsync(): 2.2 vs 24.5 µs — only 11×, because macOS fsync() does not flush the drive's write cache (that needs F_FULLFSYNC). The low ratio is itself the finding and is now taught as one.
• dict[k] += 1 across 4 threads lost zero updates — the same eval-breaker behaviour Track B's experiments found. Recorded as "an implementation detail, not a guarantee", with the free-threading consequence.

Next: unchanged — the diagnostic.

2026-07-31 — Session 5: Track D gets its own eight worked designs

Did:

• Wrote m01–m08 — the ML-infrastructure design round, in the same shape as Track C's twelve: nine sections, six hostile critiques, six revisions. 48 defects found, 48 fixes. LLM API platform · KV cache tier · GPU cluster scheduler · pretraining data pipeline · eval harness · RAG serving · LoRA serving · training fault tolerance.
• Wrote designs/README.md for the track, including the section that is worth more than any single design: which Track C primitives carry over, and which distributed-systems instincts actively fail on a bandwidth-bound substrate.
• Every number in all eight was computed by script before being written down.

Two real errors that surfaced while doing that arithmetic — both in material already committed, both the kind that would have been quoted in a round:

• Machine balance was 2× too high. The guide used NVIDIA's headline 1,979 TFLOP/s BF16, which is the with-2:4-sparsity number. LLM weights are dense, so the honest figure is 989.5 and the balance is 295 FLOP/byte, not 590. Fixed everywhere, and the asterisk is now taught as a trap — quoting a sparsity number for a dense workload is a fast way to lose credibility.
• gpu_math.py was 4× pessimistic on anything multi-GPU. It divided aggregate bytes and FLOPs by single-GPU bandwidth, so a 70B on 4×H100 reported $4.92 per 1M output tokens. Corrected it is $1.23, which is in the range real providers charge. The ratio (and so the memory-bound verdict) was always right; every absolute number was not.

The lesson worth keeping: both errors survived a full pass of writing and review, and both died the moment a number had to be used in a downstream calculation. Deriving something from a number is a much stronger check than reading it.

Next: unchanged — the diagnostic.

2026-07-31 — Session 4: all twelve designs, plus the two reference documents

Did:

• Wrote d02 through d12 — the eleven remaining design exercises, in the same shape as d01: nine template sections, then six hostile critiques, then six revisions. Across the twelve that is 72 defects found and 72 fixes written. Every one names a concrete flaw in the first draft, not a stylistic quibble.
• Wrote designs/README.md — the index. Beyond the table it carries the two things that generalize: a cross-cutting pattern map (which of the ~13 primitives recurs in which designs), and a defect taxonomy over all 72 critiques.
• Wrote CHEATSHEET.md — every track compressed into what fits in working memory before a round, including the verbatim scripts to say out loud at each of the six moments an interview goes wrong.
• Wrote GLOSSARY.md — every term used anywhere in the program, one line each, each pointing at where it is actually taught.
• Registered all of it in SUMMARY.md; corrected the Track C and root READMEs, which still described d02–d12 as future work.

The finding worth keeping — from tabulating what the 72 critiques actually caught. The single most common defect class is arithmetic never done: ten of the twelve first drafts asserted something a two-line calculation disproves (d10's rebalance moving 2.4 TB off one node; d05's circuit-state read at 1M/s). Second is an uncosted hot path, eleven instances. Neither is a knowledge gap — both are the same missing habit.

Before defending a component, size it. That one rule would have prevented 21 of 72.

Next: unchanged — the diagnostic. Twelve worked answers are worth nothing until you have measured yourself against one cold.

2026-07-31 — Session 3: the harness fully automated, Track E written

Did:

• Automated all 13 remaining harness problems. Every one of the 15 now ships a starter.py, a heavily-commented reference solution.py, and a gate-test module. 60 of 60 gates green, in ~6 seconds: python3 tracks/coding/harness/runtests.py.
• Rewrote the problem catalog so every gate brief is API-precise — the briefs are the spec the candidate codes against, so vagueness there is a bug.
• Dropped the --self-certify path from the harness; on completion it now prints the WARMUP chapter that teaches the pattern.
• Wrote tracks/take-home/WARMUP.md — the last track without a study guide. Hour-by-hour 48-hour playbook, the webhook system specified with seven logged decisions and a worked benchmark write-up, and the deep-dive interrogation: 40 questions across seven classes with full model answers, including the hostile ones.

Bugs the gate tests caught in my own reference solutions — which is the point of writing the tests first:

• path-resolver: physical mode resolved .. against the cwd string instead of walking the cwd's own symlinks, so /a/link/.. gave the logical answer in physical mode.
• text-index: re-adding a document did not purge its buffer postings, and _postings unioned across segments before filtering — so a replaced document's OLD terms resurfaced in results.
• async-crawler: an empty seed list hung forever, because the sentinel that ends the stream is only produced by a worker and no worker ever ran.
• object-pool: __slots__ removes weakref support along with __dict__, so the pooled class needs '__weakref__' explicitly or the leak detection cannot work at all.

And one finding worth keeping: on CPython 3.11+ the instance dict is managed and created lazily, so a subclass that omits __slots__ measures identical to a slotted one — same sys.getsizeof, same tracemalloc — until something is actually stored in the dict. Then it is 5.8× larger (41.6 MB vs 7.2 MB over 100k instances). The reliable tell is hasattr(x, "__dict__"), not the size. The gate test now teaches exactly that.

Next: unchanged — the diagnostic.

2026-07-30 — Session 2: study material written

Why: the first pass produced inventories and pointers — what to practise and how you're scored — but not the material itself. Everything named was a link to somewhere else. That was the right criticism and this session fixes it.

Did — eight self-contained study guides, ~15,000 lines:

• tracks/coding/WARMUP.md — ten patterns from first principles with complete implementations (MVCC/predecessor queries, delta logs, intrusive lists, four rate limiters, heap scheduling, streaming state machines, dependency graphs, WAL + crash recovery, Bloom filters, backpressure). 63 behavioural checks run green, including a WAL test that truncates the file at every byte offset.
• tracks/python-internals/WARMUP.md — the runtime from the interpreter up, including an event loop built from scratch.
• tracks/python-internals/QUIZBANK.md — 150 questions with mechanism-level answers, spot-checked against a live interpreter.
• tracks/systems-design/WARMUP.md — every primitive from zero: Little's law, the utilization knee, the failure taxonomy, clocks/Lamport/vector/HLC, leases and fencing in full, quorums, Raft including both safety rules, consistency models, partitioning, delivery semantics and the outbox, load control, CRDTs.
• tracks/systems-design/designs/d01-job-scheduler.md — the reported screen question worked end to end, then attacked by a hostile interviewer, then revised. The critique found six real defects in the first draft, which is the point.
• tracks/ml-infra/WARMUP.md — inference from zero with the roofline derived, plus a complete "design ChatGPT" answer at both altitudes and the follow-ups answered. 24 arithmetic claims verified by script.
• tracks/behavioral/WARMUP.md — all twelve categories with worked model answers at staff density.
• tracks/agentic/WARMUP.md — a fully worked 60-minute agent-driving transcript with scoring commentary, and five diffs to accept or reject.

Errors caught by verification, worth remembering:

• gc default thresholds are (2000, 10, 10) on CPython 3.13, not the long-documented (700, 10, 10). Both files now teach the shape plus gc.get_threshold() rather than a memorized constant — it is a live example of the confident-wrong failure mode.
• The decode memory/compute ratio is 590×, not 600× — and it lands exactly on the machine balance, which is a useful self-check that the derivation is right.

Next: unchanged — the diagnostic. The study guides do not replace it; they are what you read after it tells you where you are weak.

2026-07-30 — Session 1: program built

Did:

• Phase 0 research. Corroborated the source report against independent sources; wrote research/findings.md with confirmed / reported / inference labels and an explicit source-quality assessment.
• Wrote research/source-report.md — all 41 rows, each with a corroboration mark and a destination, plus a coverage audit.
• Wrote research/company-brief.md — charter structure, talking points, three questions to ask, adaptation table for eight other labs.
• Built the full baseline diagnostic: 4-gate coding problem with a working test runner and reference solution (all gates verified passing), system-design exercise with hidden follow-ups, 20-question internals quiz (every answer verified against a live interpreter), 3 behavioral prompts, answer key, rubric with level mapping, score template.
• Built the progressive harness — gating, timing, chart, 15-problem catalog. Two problems fully automated (versioned-kv, token-stream-differ), both verified 4/4.
• Wrote all seven track documents with concept inventories, drill sets, failure modes and rubrics.
• Built and verified 5 Track B experiment scripts, the Track C envelope calculators, Track D's gpu_math.py, and the review.py spaced-repetition queue.
• Registered the track in the mdBook build and the hub.

Findings worth carrying forward:

• The agentic round is not a one-lab beta — Meta, Google and CodeSignal all ship the format. Track G is not optional.
• Reported sources disagree on the coding pass bar (2/4 vs stricter). Assume the stricter one; the error is asymmetric.
• AI-lab levelling is compressed: "L5 Senior" reportedly carries Staff scope. Every rubric in this program scores at both levels and names which one you hit.
• AI tool policy is opposite at different labs. One peer lab reportedly bans AI in live rounds entirely. Ask per company, per round.
• The textbook GIL race demo does not reproduce on modern CPython (the eval breaker is checked at backward jumps, after the STORE). Put a call between the load and the store and it loses 3–61% of updates. Measured in exp03_gil.py and folded into the answer key.

Next: the diagnostic. Then PLAN.md.

Blocked: B1–B6 above.

Build Backlog

Work on the program itself, in priority order.

Mock Scores

Weekly, from week 3. Verdicts on the hire-bar scale.

Milestone Tracker

Pre-Interview Checklist

Run this once a loop is scheduled. Not before — it is a pre-flight, not a study guide.

Per company

Per loop

Phase 0 Research — Findings

Captured 2026-07-30. Everything below is stamped with what it is: confirmed, reported, or inference. Read the epistemic labels before you act on any line of it. A prep program built on a confidently-wrong model of the loop fails in a way that is invisible until the day itself.

Table of Contents

• How to Read This Document
• The Epistemic Ladder
• Confirmed
  • C1. Python free-threading status
  • C2. vLLM serving mechanics
  • C3. OpenAI Charter exists and has four named pillars
  • C4. OpenAI has published real infrastructure engineering
  • C5. GPU hardware numbers
  • C6. AI-assisted and agentic coding rounds are a real industry-wide format
• Reported by Candidates and Prep Vendors
  • R1. Loop shape
  • R2. The progressive gate format
  • R3. Recurring coding problems
  • R4. The take-home
  • R5. System design
  • R6. Behavioral and mission fit
  • R7. Levelling
  • R8. AI tool policy varies by lab
• My Inference
• Source Quality Assessment
• What I Could Not Verify
• How This Changes the Program
• References

How to Read This Document

The originating artifact for this program is a single candidate's account of an OpenAI software-engineering loop, posted to a subreddit and roughly four days old at time of capture. That is one unverified source. The loop varies by team, by level, and by quarter. Treating it as ground truth would be a methodological error, and building six months of training on top of it without corroboration would be a worse one.

So Phase 0 did two things:

1. Corroborate — go find independent, dated sources that agree or disagree with each reported claim.
2. Bound the blast radius — where corroboration is impossible, mark the claim as reported and make sure the program does not become so narrow that an unexpected round is a surprise.

The result is the three-tier ladder below.

The Epistemic Ladder

A hard rule for the whole program: you never say to an interviewer "I heard your process does X." Reported material shapes what you practice. It is not conversational material.

Confirmed

C1. Python free-threading status

Status as of Python 3.14 (released October 2025): the free-threaded build is officially supported but not the default. PEP 703 laid out a three-phase plan; PEP 779 defined the criteria for moving from "experimental" (Phase I, Python 3.13) to "officially supported" (Phase II, Python 3.14). Phase III — free-threading as the default build — has not happened and is not scheduled for the near term.

Reported performance characteristics of the 3.14 free-threaded build: single-threaded overhead down to roughly 5–10% (from ~40% in the 3.13 experimental build), multi-threaded CPU-bound speedups in the ~4x range on suitable workloads, and a memory footprint roughly 15–20% higher than the GIL build.

Why this matters for the loop: "Is the GIL gone?" is exactly the kind of question that separates someone who read a headline from someone who tracks the runtime. The correct answer has three parts — which build, which phase, and what it actually costs. This is Track B material, and the drill for it is a runnable script that reports sys._is_gil_enabled() and measures the overhead, not a memorized sentence.

Verification: python3.14 -c "import sys; print(sys._is_gil_enabled())" on a python3.14t build. The Track B experiments directory includes this as a runnable check.

C2. vLLM serving mechanics

The four techniques that define modern open-source LLM serving are documented in vLLM's own material and are verifiable by reading the source:

• PagedAttention — KV cache stored in fixed-size non-contiguous blocks with a block table per sequence, rather than one contiguous pre-allocated buffer per sequence. Removes internal fragmentation and the need to reserve for max sequence length.
• Continuous (in-flight) batching — scheduling at iteration granularity rather than batch granularity. A finished sequence's slot is refilled on the next forward pass instead of the batch idling until its slowest member completes.
• Chunked prefill — splitting a long prompt's prefill across multiple scheduler steps so decode iterations for other sequences are not blocked for the full prefill duration. Trades a small amount of prefill throughput for materially better TTFT tail latency.
• Prefix caching — reusing KV blocks for identical prompt prefixes across requests (system prompts, tool definitions, few-shot blocks).

Confirmed mechanism; the magnitudes are vendor-reported. Claims like "3–5x more traffic than a naive PyTorch loop on the same H100" come from blog benchmarks, not from a measurement you have made. The program's rule (see Operating Rules) is that any performance number you quote in an interview must either be one you measured or one you attribute. Track D includes the measurement harness.

C3. OpenAI Charter exists and has four named pillars

The OpenAI Charter (published 2018) is organized around four commitments, whose headings are quoted consistently across independent mirrors and academic indexes:

1. Broadly Distributed Benefits
2. Long-Term Safety
3. Technical Leadership
4. Cooperative Orientation

The Charter includes the well-known merge-and-assist clause: a commitment to stop competing and start assisting if a value-aligned, safety-conscious project comes close to building AGI before OpenAI does. It also commits to using any influence obtained over AGI deployment for the benefit of all and to avoiding uses that harm humanity or unduly concentrate power.

Caveat, and it matters: openai.com/charter returned HTTP 403 to automated fetching during this research pass. The four headings and the merge-and-assist clause are corroborated across the MIT CyberIR index and the ETO AGORA instrument database, both of which catalogue it as a 2018 document. Before your recruiter screen, open the Charter in a browser yourself and read the primary text. Do not walk into that call with a second-hand summary — the whole point of the question is that you read the actual document. Treat company-brief.md as a scaffold you fill in from the primary source, not as a substitute for it.

C4. OpenAI has published real infrastructure engineering

"Scaling Kubernetes to 7,500 nodes" is a genuine OpenAI engineering post (a follow-on to an earlier 2,500-node post). Documented content includes: replacing Flannel with native pod networking via Azure VMSS IP configurations and the corresponding CNI plugins, and building automated health-check systems to detect and evict malfunctioning nodes at that scale.

Why this matters: the "Reading and rebuttal" differentiator in this program requires you to ask a specific question about a specific design choice they published. This post is a concrete target. See company-brief.md.

C5. GPU hardware numbers

Specifications (vendor datasheet figures, stable and citable):

Cloud hourly pricing is volatile and provider-dependent — figures in the ~$1.49–2.99/hr (H100), ~$3.80/hr (H200), ~$6.50/hr (B200) range were reported in 2026 sources. Treat prices as order-of-magnitude anchors with a date attached, never as facts.

The load-bearing insight, and the one to actually internalize: H200 has identical compute to H100 but ~43% more bandwidth and 76% more memory, and it is meaningfully faster for LLM decode. That is the cleanest available proof that autoregressive decode is memory-bandwidth-bound, not compute-bound. If you can derive why from arithmetic intensity — one weight load per token per parameter at batch size 1 — you have the core of the "design ChatGPT" round. Track D builds this from first principles.

C6. AI-assisted and agentic coding rounds are a real industry-wide format

Independently corroborated beyond the source report: Meta began rolling out AI-enabled coding interviews in late 2025; Google is piloting a Gemini-assisted coding format; CodeSignal shipped agentic coding assessments as a product. Reported formats center on a 60-minute session against a multi-file codebase, progressing through phases (bug fix → core implementation → optimization), with the assistant confined to a chat panel rather than given direct file-edit authority. Stated evaluation criteria across these programs converge on AI fluency: prompt construction, output validation, and debugging the assistant's work.

This is the single most important corroboration in the whole research pass. The source report describes the agentic round as beta and not universally administered — which invites you to skip preparing for it. The independent evidence says the format is becoming an industry standard. Track G is therefore not optional.

Reported by Candidates and Prep Vendors

Everything in this section comes from candidate accounts and prep-vendor guides. Sources disagree with each other in places, and I have flagged where.

R1. Loop shape

The most common reported shape for mid-to-senior SWE:

1. Recruiter screen (~30 min)
2. Technical screen (~60 min live coding, CoderPad)
3. System design screen (~60 min, Excalidraw) — sometimes combined with (2) into one day
4. Take-home / work trial — 48-hour window, reported as paid and under NDA
5. Onsite loop — reported variously as 4 rounds, 4–6 rounds, or 6 components

Disagreement between sources, and it is worth naming: the source report says "4 rounds" onsite plus a beta agentic round. Aggregators list up to six onsite components including a technical presentation and a separate team-fit conversation. Two independent corroborations of the same-day two-round screen exist, which matches the source report.

Two claims corroborate the source report's most distinctive details: that the screen is two 60-minute rounds on the same day, and that the take-home is a 48-hour "build something real" project. One vendor source reports a flat payment for the trial (~$1,000, early 2026) — unverified, and irrelevant to preparation.

R2. The progressive gate format

Multiple independent prep sources describe OpenAI's coding assessment as a progressive obstacle course: each problem has roughly four gates of increasing difficulty, and the reported pass bar is clearing two. Clearing all four is reported as rare.

One source contradicts the leniency: it reports the bar as not passing candidates at "2/4 or a low 3/4." Assume the stricter version. Preparing for a 3/4 bar and encountering a 2/4 bar costs you nothing. The reverse costs you the offer.

This directly corroborates the source report's central claim — the progressive multi-part format, with each stage gated on the previous one working — and it is the reason the progressive harness is the highest-priority build in this program.

R3. Recurring coding problems

Reported patterns, aggregated across sources and deduplicated:

• Time-based / versioned key-value store — reported by several sources independently. This corroborates the source report's screen question directly.
• LRU cache from scratch
• Resumable iterator with state serialization — note how precisely this targets the reported Python-internals emphasis on iterators and generators.
• Rate limiter (token bucket or sliding window)
• KV store serialize/deserialize with delimiter-bearing keys and values
• In-memory database with SQL-ish operations
• Unix cd with symlink resolution
• Spreadsheet formula evaluation with dependencies and cycle detection
• Multithreaded web crawler
• Meeting rooms / interval scheduling

Reported emphases: write substantially more code than in a typical FAANG interview; production-quality, maintainable solutions with real edge-case handling; practical problems over algorithmic tricks. One source states flatly, "you're not going to get questions on string manipulation."

Also reported: occasional math-flavored problems (KL divergence for continuous distributions, expected-iterations problems, cross-entropy minimum error) — more likely on research-adjacent teams. Not corroborated by the source report; the program includes a short optional module rather than ignoring it.

R4. The take-home

Corroborated: 48-hour window, "build something real," reported as paid and under NDA. Reported evaluation criteria converge tightly and are worth taking literally:

• Code quality
• Test coverage
• A written design doc explaining tradeoffs
• How you handled the deliberately under-specified parts of the brief

One source states the principle directly: a working solution with a thoughtful README beats a clever solution with no docs. Another notes the 48 hours include sleep and suggests roughly 4h understanding + design draft, 24–30h implementation and tests, 6–8h polish and writeup, remainder as buffer.

The source report's specific example — a distributed webhook delivery system with retry logic and dead-letter queues — is corroborated by at least one independent vendor source describing a webhook delivery system as a work-trial project. That is meaningful corroboration of an unusually specific detail.

R5. System design

Reported prompts span both conventional systems (Yelp, Twitter, notification systems) and the AI-native ones. The source report's "design ChatGPT" prompt with an interviewer focused on GPU allocation, autoscaling under non-stationary traffic, and distributed coordination is consistent with published treatments of the problem and with the SageServe / ENOVA line of academic work on forecast-aware autoscaling for LLM serving.

Job scheduler with fault tolerance is reported both as a screen question and as a component inside larger architecture prompts (webhook listener → API service → workflow engine → job scheduler).

Reported anti-pattern, and it is a real one: name-dropping technologies without being able to defend the tradeoff. Saying "I'd use Kafka" and being unable to explain the alternative you rejected is worse than proposing a queue you can actually reason about.

R6. Behavioral and mission fit

Reported emphasis on ethics and safety reasoning, and on cross-functional collaboration with researchers, PMs, and safety teams — not only with engineering peers. For Anthropic specifically, multiple sources report the culture/values round as the most common failure point, which is a striking claim for a set of companies whose technical bars are this high.

This corroborates the source report's recruiter-screen question about where AI is headed, and raises its weight. See Track F.

R7. Levelling

Reported, with real disagreement in the details but consensus on the shape: OpenAI runs L3–L7 on the IC track, and its levelling is compressed relative to Google/Meta — an OpenAI level maps to roughly one level higher elsewhere. Multiple sources describe L5 as carrying Staff-equivalent scope despite a "Senior" title.

Practical consequence, and this is the one that changes how you prepare: if you are targeting senior/staff at an AI lab, calibrate your behavioral stories and system-design altitude to Staff at a big-tech company, not Senior. Cross-team architectural influence, not "I owned a service." Every rubric in this program therefore scores at two levels and tells you which one you hit.

R8. AI tool policy varies by lab

Reported: Anthropic prohibits AI tool use in live interviews, and candidates have reportedly been removed from processes for using it. Meanwhile Meta and Google are actively piloting AI-assisted rounds, and OpenAI reportedly runs an agentic round in beta.

These are opposite policies at companies you may interview at in the same month. Ask the recruiter explicitly, per company, per round. Never assume. This goes on the pre-interview checklist in STATE.md.

My Inference

Clearly labelled. None of this is sourced; it is my reasoning from the material above.

I1. The take-home and the deep dive are one round, not two. The take-home's real function is to generate a personalized interrogation surface. The interviewer reads your code and writes questions from it. That means every decision you make in the 48 hours is a question you will be asked in week three. The optimization target is therefore not "best code" — it is "code every line of which I can defend, plus a written record of the alternatives I rejected." A slightly simpler system you can defend completely beats a sophisticated one with three choices you made on autopilot. This reframing drives Track E entirely: you keep a decision log while building.

I2. "Abstract the model-serving layer unless told otherwise" is a scoping test, not a hint about depth. The interviewer wants to see whether you can identify which component of a system is load-bearing for this conversation and hold the rest at a stable interface. Candidates who immediately dive into PagedAttention are demonstrating knowledge while failing the actual signal, which is judgement. The correct move is to name the abstraction explicitly ("I'll treat the inference engine as a service with these three SLOs and this admission interface — tell me if you want to open it up"), then spend your time on traffic, coordination, and failure. But you must be able to open it on request within seconds. Hence Track D drills both altitudes and defaults to the abstracted one.

I3. The progressive format inverts the standard optimization. In a normal coding round you can spend fifteen minutes designing before writing. In a gated format, time-to-first- passing-stage is the metric that compounds — every minute of upfront design is a minute stolen from stages 2, 3, and 4, and a gate you never open scores zero regardless of how elegant your unwritten design was. This argues for a deliberately different habit: build the smallest correct thing fast, then refactor under the pressure of the next stage. It also argues that your stage-1 code must be extensible, since you will be extending it under time pressure. That tension — fast but extensible — is precisely what the format tests, and it is trainable. Time-to-first-correct is a first-class tracked metric in the harness.

I4. The systems-flavored coding round is where the reported Python-internals questions live. "State management, concurrency, memory efficiency" plus "generators, async constructs, iterators" is not two separate observations. It is one observation: they ask you to build a stateful streaming component, and the internals questions arise naturally from your implementation choices. Preparing internals as trivia is the wrong shape. Preparing them as "why did you choose a generator here, and what does that cost" is the right shape.

I5. Your background is closer to this loop than a generic senior SWE's. Multilingual search and recommendation is retrieval, ranking, embeddings, and index serving — which is structurally the same problem as the retrieval-augmentation and serving layers around a chat product. The gap is not conceptual; it is the GPU-economics vocabulary and the inference-specific scheduling. That is roughly six weeks of focused work, not six months. The genuinely unproven areas are speed under gated time pressure and staff-altitude behavioral narrative.

Source Quality Assessment

Be honest about what these sources are. Most "OpenAI interview 2026" results are SEO content marketing produced by interview-prep vendors, some of which sell products of questionable legitimacy. They recycle each other. Agreement between two such sources is weak evidence, not strong evidence — it frequently means one copied the other.

Rule enforced throughout this program: every performance claim you make in an interview must be one you measured or one you attribute. "vLLM gets 3–5x" is a thing a blog said. "I measured 2.8x on my harness at batch 32 with a 512-token prompt" is a thing you can defend under follow-up. The second is worth ten of the first.

What I Could Not Verify

Listed explicitly, because an unmarked gap becomes a false belief.

1. The source report itself. I could not locate the originating subreddit post. Its contents are treated as reported, and every distinctive claim is separately corroborated or explicitly marked uncorroborated in source-report.md.
2. The Charter's primary text. openai.com/charter returned HTTP 403 to automated fetching. Four pillar headings and the merge-and-assist clause are corroborated across mirrors. You must read the primary source in a browser before the recruiter screen.
3. Take-home payment terms. One low-weight source; unverified; irrelevant to preparation.
4. Exact onsite round count. Sources disagree (4 / 4–6 / 6 components). The program prepares for six components so that a fifth or sixth round is not a surprise.
5. Whether the agentic round is administered to senior/staff candidates specifically. Reported as beta and selective. Prepared for regardless — see C6.
6. Any current, dated OpenAI publication describing their own inference stack in detail. The public serving literature (vLLM, TensorRT-LLM, Triton, Ray Serve, and the arXiv autoscaling work) is the grounding for Track D. Do not claim knowledge of OpenAI's internal stack; reason from public systems and say that is what you are doing.

How This Changes the Program

Six research-driven adjustments to what would otherwise be the obvious plan:

1. Track G is not optional. C6 shows the agentic format going industry-wide, not staying a one-lab beta.
2. Assume the strict gate bar (3/4, not 2/4). R2 has sources on both sides. The asymmetry of the error is total.
3. Behavioral weight goes up, not down. R6 reports values/culture as the leading failure mode at a peer lab. Senior engineers systematically under-prepare this. It gets a fixed weekly slot, not a week-eleven cram.
4. Calibrate everything to Staff, not Senior. R7 — compressed levelling means the "Senior" title carries Staff scope. Every rubric scores both and names which one you hit.
5. The volume signal changes coding practice. R3 — write more code than a typical FAANG interview. Typing throughput and clean-first-draft ability are trainable and are trained explicitly, not assumed.
6. Design-doc-writing is a first-class drilled skill. It appears in the take-home criteria, in the deep dive, and in the design rounds. It is drilled to a time budget with a fixed template, not treated as a byproduct.

References

Primary and technical

• OpenAI. Scaling Kubernetes to 7,500 nodes. https://openai.com/index/scaling-kubernetes-to-7500-nodes/
• OpenAI. Charter (2018). https://openai.com/charter/ — read this in a browser; it 403s to fetchers
• Python Software Foundation. PEP 703 — Making the Global Interpreter Lock Optional in CPython. https://peps.python.org/pep-0703/
• Python Software Foundation. PEP 779 — Criteria for supported status for free-threaded Python. https://peps.python.org/pep-0779/
• CPython docs. Python support for free threading. https://docs.python.org/3/howto/free-threading-python.html
• Python Free-Threading Guide. https://py-free-threading.github.io/
• vLLM project. https://github.com/vllm-project/vllm · docs https://docs.vllm.ai/
• vLLM Blog. Inside vLLM: Anatomy of a High-Throughput LLM Inference System (2025-09-05). https://vllm.ai/blog/2025-09-05-anatomy-of-vllm
• Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023). https://arxiv.org/abs/2309.06180
• Yu et al. Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022) — origin of continuous batching.
• Agrawal et al. Sarathi-Serve / chunked prefill. https://arxiv.org/abs/2403.02310
• SageServe: Optimizing LLM Serving on Cloud Data Centers with Forecast Aware Auto-Scaling. https://arxiv.org/pdf/2502.14617
• ENOVA: Autoscaling towards Cost-effective and Stable Serverless LLM Serving. https://arxiv.org/abs/2407.09486
• NVIDIA. H100 Tensor Core GPU. https://www.nvidia.com/en-us/data-center/h100/

Interview process (reported — weight accordingly)

• interviewing.io. OpenAI's Interview Process & Questions. https://interviewing.io/openai-interview-questions
• interviewing.io. Anthropic's Interview Process & Questions. https://interviewing.io/anthropic-interview-questions
• Hello Interview. OpenAI Coding Interviews: Real Questions. https://www.hellointerview.com/blog/openai-coding-questions
• Hello Interview. OpenAI L5 Interview Guide. https://www.hellointerview.com/guides/openai/l5
• Hello Interview. Design ChatGPT. https://www.hellointerview.com/learn/system-design/problem-breakdowns/chatgpt
• Exponent. OpenAI Software Engineer Interview Guide. https://www.tryexponent.com/guides/openai-software-engineer-interview
• Exponent. Google's AI-Assisted Coding Interview (2026 Guide). https://www.tryexponent.com/blog/google-ai-coding-interview
• interviewing.io. How to use AI in Meta's AI-assisted coding interview. https://interviewing.io/blog/how-to-use-ai-in-meta-s-ai-assisted-coding-interview-with-real-prompts-and-examples
• Glassdoor. OpenAI Interview Experience & Questions. https://www.glassdoor.com/Interview/OpenAI-Interview-Questions-E2210885.htm
• CTAIO. AI Lab Levels Explained 2026. https://ctaio.dev/en/salary/ai-lab-levels-explained/

Books that back the design tracks

• Kleppmann, M. Designing Data-Intensive Applications, 2nd ed. O'Reilly.
• Ongaro, D. and Ousterhout, J. In Search of an Understandable Consensus Algorithm (Raft). USENIX ATC 2014.
• Beyer et al. Site Reliability Engineering. O'Reilly, 2016 — chapters on load shedding, cascading failure.
• Ramalho, L. Fluent Python, 2nd ed. O'Reilly — data model, iterators, coroutines.
• Slatkin, B. Effective Python, 3rd ed. Addison-Wesley — concurrency and generator idioms.
• Larson, W. Staff Engineer: Leadership Beyond the Management Track.

Source Report — Fidelity Checklist

The originating artifact for this program is one candidate's account of an OpenAI software-engineering loop, posted to a subreddit and roughly four days old at time of capture. It is a single unverified source. The loop varies by team, by level, and by quarter.

This file exists so that nothing from it is silently dropped. Every detail is a row. Every row has a destination in the program and a corroboration status. If a row has no destination, the program has a hole.

Table of Contents

• How to Use This File
• Corroboration Legend
• The Checklist
  • Stage 1: Recruiter Screen
  • Stage 2: Technical Screen
  • Stage 3: Take-Home
  • Stage 4: Deep Dive
  • Stage 5: Onsite
  • Stage 6: Agentic Round
  • Meta
• Coverage Audit
• The Anti-Narrowing Clause
• References

How to Use This File

Read it at three moments:

1. Now, once, so you know what the program is built against.
2. At each monthly diagnostic re-test, to confirm no row has quietly gone unaddressed.
3. In the final two weeks, as a pre-flight checklist — every row should map to something you have done, not something you have read.

The rightmost column is a live audit surface. A row whose destination file does not exist yet is a tracked gap, not an oversight.

Corroboration Legend

Details in findings.md.

The Checklist

Stage 1: Recruiter Screen

Stage 2: Technical Screen

Stage 3: Take-Home

Stage 4: Deep Dive

Stage 5: Onsite

Stage 6: Agentic Round

Meta

Coverage Audit

Run this audit at every monthly diagnostic. A row is covered only when its destination exists and you have a passed drill, a working artifact, or a scored mock against it — never on the basis of having read something.

Every one of the 41 rows has a destination. Existence of the destination is not evidence of competence — that is what the rubrics and the review/ queue are for.

The Anti-Narrowing Clause

The provenance note attached to the source report is the most important sentence in it:

...do not let one report narrow the preparation so far that an unexpected round is a surprise.

Three concrete guards, enforced structurally rather than by good intentions:

1. Breadth floor. Every track carries material the source report does not mention but corroborated sources do: LRU caches, rate limiters, spreadsheet dependency evaluation with cycle detection, symlink resolution, multithreaded crawlers, in-memory SQL, and the occasional math-flavored problem (KL divergence, expected iterations). Roughly 25% of Track A's problem set is deliberately off-report.
2. Round-count buffer. The onsite is prepared as six components, including a technical presentation and a separate team-fit conversation that the report never mentions but aggregators do.
3. Company-agnostic core. Tracks A–D and F transfer to Anthropic, DeepMind, Scale, Cursor, xAI, Databricks, Netflix, and Stripe with only Track D's depth and Track F's mission material swapped. The program is not overfit to one company, and the company-specific surface is deliberately isolated in company-brief.md.

References

• findings.md — the corroboration evidence and full source list behind every ✅/🟡/⚪/⚠️ in this file
• company-brief.md — mission/charter digest, talking points, questions to ask
• ../PLAN.md — how these rows become weeks
• ../STATE.md — the live progress ledger and pre-interview checklist

Company Brief — Mission, Charter, and Talking Points

Purpose: to walk into the recruiter screen having read the primary documents, with a defensible forward-looking position and three questions sharp enough that the interviewer has to think.

⚠️ Verification gate. openai.com/charter returns HTTP 403 to automated fetching. The structure below is corroborated across independent mirrors, but you must open the Charter in a browser and read the primary text before your recruiter call. Fill the quote slots marked [VERIFY] with the actual sentences. A second-hand summary defeats the entire purpose of the question.

Table of Contents

• The Verification Gate
• The Charter: Four Pillars
• What the Charter Actually Commits To
• Reading the Charter Like an Engineer
• Published Engineering: What They Have Told Us
• Talking Points: One Page
• Where Is AI Headed: The Answer
• Three Sharp Questions to Ask Them
• Adapting This Brief to Other Labs
• Rehearsal Protocol
• References

The Verification Gate

Before this brief is usable, complete these four steps and record the date in ../STATE.md:

Why this is a gate and not a suggestion: the reported recruiter-screen advice is literally read the charter before that call. If you paraphrase a summary of a summary, it will show in the follow-up, and the follow-up is the actual test.

The Charter: Four Pillars

Published 2018. Four commitments, headings corroborated across the MIT CyberIR index and the ETO AGORA instrument database:

1. Broadly Distributed Benefits

Commits to using any influence obtained over AGI's deployment for the benefit of all, and to avoiding uses of AI or AGI that harm humanity or unduly concentrate power.

[VERIFY] — paste the actual sentence here.

2. Long-Term Safety

Commits to doing the research required to make AGI safe, and to driving broad adoption of such research across the AI community rather than treating safety work as proprietary advantage.

Contains the merge-and-assist clause: if a value-aligned, safety-conscious project comes close to building AGI before OpenAI does, OpenAI commits to stop competing with it and start assisting it.

[VERIFY] — paste the merge-and-assist sentence verbatim. It is the single most quotable line in the document and the one most likely to come up.

3. Technical Leadership

Asserts that policy and safety advocacy alone are insufficient — to be effective at addressing AGI's impact on society, the organization must be at the frontier of AI capabilities.

[VERIFY]

4. Cooperative Orientation

Commits to actively cooperating with other research and policy institutions, and to seeking to create a global community working together to address AGI's global challenges.

[VERIFY]

What the Charter Actually Commits To

Read as an engineer, not as a reader of mission statements. A charter is a constraint document: it says what the organization will refuse to do. Three constraints are load-bearing:

1. A stopping condition. The merge-and-assist clause is a pre-commitment to abandon a competitive position under a specified trigger. That is unusual and it is checkable.
2. A non-concentration constraint. "Unduly concentrate power" is a constraint on deployment, not on research. It is the pillar most in tension with commercial reality, and the one a thoughtful candidate can discuss honestly.
3. A capability-is-prerequisite-to-safety argument. Pillar 3 asserts that you cannot steer what you cannot build. This is the claim that draws the most external criticism and the one you should be able to argue both sides of.

This is the depth the question is actually probing. Anyone can say "I love the mission." The signal is whether you have read it closely enough to notice that pillars 2 and 3 are in productive tension, and whether you can hold that tension without either dismissing it or being naive about it.

Reading the Charter Like an Engineer

The recruiter screen question is "where do you think AI is headed?" — asked by someone who has heard four hundred answers. Here is what separates the tiers:

The strong version requires having an actual position. That is what Where Is AI Headed below and the technical-opinion essay in ../projects/README.md exist to produce.

Published Engineering: What They Have Told Us

You cannot claim knowledge of their internal stack. You can reason from what they published — and doing so is far more impressive than speculation.

Scaling Kubernetes to 7,500 nodes

A genuine OpenAI engineering post, following an earlier 2,500-node post. Documented content:

• Networking: Flannel could not sustain the required throughput at that node count. They moved to native pod networking using Azure VMSS IP configurations and the corresponding CNI plugins.
• Node health: at that scale, automated detection and eviction of malfunctioning nodes is mandatory. They built health-check systems for it.
• Thesis: one very large cluster keeps researcher-facing infrastructure simple — scale up without changing your code — and they judged that simplicity worth the operational cost of pushing a single cluster past its comfortable envelope.

Why this is the right post to have read. It is a tradeoff post, not a victory lap. They chose one big cluster over many small ones and paid for it in networking and node-health engineering. That choice is arguable, which makes it a real question to ask about — see Q1.

What is not public

There is no current, dated OpenAI publication describing their inference stack in the detail that vLLM or TensorRT-LLM describe theirs. Do not pretend otherwise. The correct framing in a design round:

"I don't know how you do this internally, so I'll reason from the public systems I've read — PagedAttention, continuous batching from Orca, chunked prefill from Sarathi-Serve — and you can tell me where that diverges from your reality."

This is a strength move, not a hedge. It shows you know the literature, you know the boundary of your knowledge, and you can be corrected without losing the thread.

Talking Points: One Page

Compress to this. Rehearse until it is conversational, not recited.

On the mission (30 seconds). Four pillars: broadly distributed benefits, long-term safety, technical leadership, cooperative orientation. The structurally interesting part is that it is a constraint document with a stopping condition — the merge-and-assist clause pre-commits to abandoning a competitive position under a specified trigger. Pillars 2 and 3 are in real tension: capability is argued as a prerequisite for safety. I find that argument mostly persuasive and I can say where I think it strains.

On why this company (30 seconds). Ground it in the work, not the brand. Your honest version: you have spent a decade on retrieval, ranking, and serving systems where the constraint was always "make this sub-100ms and cheap at scale." The serving layer around a frontier model is the same problem with a harder cost structure and a memory-bandwidth wall instead of an I/O wall. That is a continuation of your career, not a pivot.

On what you would work on (30 seconds). Inference serving and the retrieval systems around it. Be concrete: continuous batching and scheduler policy, KV cache and prefix reuse, admission control and fairness under non-stationary load. These are queueing and scheduling problems, and you have shipped queueing and scheduling systems.

On their hardest unsolved engineering problem (60 seconds). Your defensible answer: serving cost per useful token under adversarial, non-stationary, multi-tenant load, with a latency SLO that users can feel. Decode is memory-bandwidth-bound (the H100→H200 comparison is the clean proof: identical compute, ~43% more bandwidth, materially faster decode). So throughput comes from batching, and batching fights latency, and latency is the product. Every technique — continuous batching, prefix caching, speculative decoding, chunked prefill — is a different point on that curve. Meanwhile agentic workloads make traffic burstier and less predictable, so autoscaling signals that were fine for request-response chat degrade badly. Be ready to be told you are wrong and to incorporate the correction.

On safety posture (30 seconds, honest). Have a real read. Note the tension between pillar 3's capability-first argument and pillar 2's safety commitment; note that the merge-and-assist clause has never been triggered and its trigger conditions are not operationally defined. State that you find the "you can't steer what you can't build" argument credible while thinking the non-concentration commitment is the hardest one to keep. Do not perform either enthusiasm or skepticism. Interviewers at these companies have finely tuned detectors for both.

Where Is AI Headed: The Answer

Full written answer lives in ../tracks/behavioral/README.md and gets a rehearsal slot every week. The structure it must have:

1. A specific claim, not a trend list. Example shape: "The binding constraint on useful AI over the next two years is not model capability, it is the cost and latency of inference under agentic workloads, where one user turn becomes fifty model calls."
2. Evidence you can cite or have measured. Arithmetic intensity of decode; the H200's bandwidth-only advantage; what continuous batching does to the throughput-latency curve; what a tool-calling loop does to token volume per user action.
3. What would change your mind. "If speculative decoding acceptance rates hold at high ratios on real agentic traffic, or if a genuinely different serving architecture lands, the cost curve moves faster than I'm assuming and the constraint shifts back to capability." Stating a falsifier is the single strongest signal in the answer.
4. The connection to what you would build. Ties directly to the talking points.

Length: 90 seconds. Then stop and let them push. The push is where the points are.

Three Sharp Questions to Ask Them

Not "what's the culture like." Questions that demonstrate you read their work and thought about it. Each names a specific design choice and asks about the tradeoff behind it.

Q1 — On the single-cluster bet

"The 7,500-node post argues that one very large Kubernetes cluster keeps things simple for researchers — scale up without changing your code — and you paid for that with the Flannel replacement and the node-health automation. Now that a large share of the fleet is serving production inference rather than research training, does the simplicity argument still hold? I'd expect serving and training to want opposite things from a scheduler — serving wants fast preemption and tight tail latency, training wants gang scheduling and long uninterrupted holds. How do you keep those from fighting?"

Why it works: quotes a real published choice, understands why they made it, and identifies a specific reason it might have aged. It is a question only someone who has run schedulers would ask.

Q2 — On the serving/latency tradeoff

"Everything in the public serving literature — continuous batching, chunked prefill, prefix caching — is a different point on the throughput-versus-tail-latency curve. Where do you sit on that curve, and is it one curve or several? I'd guess an interactive chat turn, a long agentic tool loop, and a batch API want genuinely different scheduler policies, which implies either separate pools or a priority-aware scheduler with preemption. Which way did you go, and what did it cost?"

Why it works: shows you know the technique inventory and that you understand the techniques are not free wins but positions on a tradeoff. The "one curve or several" framing is the question a serving engineer asks.

Q3 — On the charter under commercial pressure

"The Charter's non-concentration commitment — avoiding uses that unduly concentrate power — is the pillar with the most tension against a commercial deployment business. Is that something engineers encounter as a concrete constraint on design decisions, or does it live at the policy layer? I'm asking because I'd rather know now whether it shows up in code review."

Why it works: takes the mission seriously as an engineering constraint rather than as decoration, and asks a question whose answer actually affects whether you would enjoy the job. Reported sources say values rounds are the leading failure mode at peer labs — demonstrating you engage with the mission substantively rather than reverently is the distinguishing behavior.

Have all three ready. Ask two. Leave one in reserve for the round where the interviewer finishes early.

Adapting This Brief to Other Labs

Tracks A–D and F transfer wholesale. Only this file and Track D's depth emphasis change.

Note the pattern: Cursor, Netflix, and Stripe each map onto something you have already built. Those are your highest-conversion targets, and the webhook project doubles as Stripe-relevant portfolio work.

Rehearsal Protocol

Weekly, 15 minutes. Recorded, then scored against ../mocks/README.md's behavioral rubric.

1. 90-second career narrative — cold, to a timer.
2. "Where is AI headed?" — 90 seconds, ending on a falsifier.
3. "Why us?" — 30 seconds, grounded in the work.
4. "What's our hardest unsolved engineering problem?" — 60 seconds, then defend it against one pushback.
5. Ask your three questions out loud. If any sounds like it came off a list, rewrite it.

Failure mode to watch for: over-rehearsal. These must sound like opinions you hold, not paragraphs you memorized. If a recording sounds recited, cut it to bullet points and re-derive it live next session.

References

• OpenAI. Charter (2018). https://openai.com/charter/ — primary; read in a browser
• OpenAI. Scaling Kubernetes to 7,500 nodes. https://openai.com/index/scaling-kubernetes-to-7500-nodes/
• OpenAI Index (engineering and research posts). https://openai.com/index/
• MIT CyberIR. OpenAI Charter (index entry). https://cyberir.mit.edu/site/openai-charter/
• ETO AGORA. OpenAI Charter (instrument 767). https://agora.eto.tech/instrument/767
• Anthropic. Core Views on AI Safety. https://www.anthropic.com/news/core-views-on-ai-safety
• Anthropic. Responsible Scaling Policy. https://www.anthropic.com/rsp
• Google DeepMind. Frontier Safety Framework. https://deepmind.google/discover/blog/introducing-the-frontier-safety-framework/
• Kwon et al. Efficient Memory Management for LLM Serving with PagedAttention (SOSP 2023). https://arxiv.org/abs/2309.06180
• Yu et al. Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022).
• findings.md — corroboration status for every claim above
• source-report.md — rows 4 and 5 land here

Baseline Diagnostic — Day One

A timed 3-hour battery. You take this before any plan exists. Its only job is to replace assumptions about your level with measurements, so the six-month plan is built on what is actually weak rather than on what is conventionally assumed to be weak.

Do not read ANSWER-KEY.md or any solution.py before you finish. A contaminated baseline is worse than no baseline — it produces a plan optimized for a person who does not exist.

Table of Contents

• Why a Diagnostic at All
• Setup
• The Protocol
• Part 1: Coding (45 minutes)
• Part 2: System Design (45 minutes)
• Part 3: Python Internals Quiz (30 minutes)
• Part 4: Behavioral, Written (40 minutes)
• Scoring
• Recording Your Scores
• Monthly Re-Tests
• Rules I Will Hold You To
• References

Why a Diagnostic at All

The candidate-context assumptions this program started from — strong on search, retrieval, ranking and distributed systems reading; weak on timed coding speed, Python runtime depth, GPU/inference design, and staff-altitude behavioral narrative — are plausible and unverified. They came from a self-assessment.

Self-assessments are systematically wrong in a specific direction: people underrate skills they use daily (because familiarity feels like ease, not competence) and overrate skills they have read about but not performed under time pressure. If those assumptions are wrong in either direction, six months of study gets allocated to the wrong track, and you will not find out until the loop.

So: measure first. The battery deliberately spans all four onsite round types plus the internals layer, so the plan can be rebalanced against evidence rather than against a hunch.

This battery re-runs monthly. Its second job is producing a trend line — the single most motivating artifact in a six-month program, and the only honest evidence that the work is working.

Setup

cd swe-interview-prep/diagnostics
python3 --version          # 3.11+ required; 3.12 or 3.13 preferred

No third-party dependencies. pytest is optional — the test files run standalone.

You need, physically present before you start:

• A timer you can see. Not a phone you will unlock.
• A drawing surface for Part 2 — Excalidraw is reported to be the actual design-round tool, so use it. Diagramming under time pressure is a motor skill.
• A voice recorder. Part 1 is narrated out loud, and you will score the narration.
• Somewhere to write Part 4 that is not this repo (you will paste it in afterwards).

Close everything else. No AI assistant, no search, no documentation, no autocomplete beyond what your editor does natively. The point is to measure the floor, and the floor is what you have without tools.

The Protocol

Three hours, in one sitting, in this order. The ordering is deliberate: the reported screen is two 60-minute rounds back to back, so fatigue is part of what is being measured.

Hard stop means hard stop. When the timer ends, you stop typing mid-word. An interview does not grant extra minutes, and the entire diagnostic value of a timed instrument comes from honoring the timer. If you run over and score well, you have learned nothing.

Part 1: Coding (45 minutes)

Problem: d1-coding/problem.md — a resumable iterator with serializable state, presented in four progressive gates exactly as the reported onsite format works.

Why this problem. A resumable iterator with state serialization is one of the most-reported OpenAI screen problems (../research/findings.md), and it sits precisely at the intersection of the three reported Coding-2 themes — state management, memory efficiency, and the iterator protocol. It also produces diagnostic signal for Track B at the same time, which is why it is worth 45 of your 185 minutes.

The reported screen problem — the versioned key-value store — is deliberately not used here. It is the highest-value practice problem in Track A and burning it on a diagnostic would cost more than it measures.

How to run it

cd d1-coding
cp starter.py attempt.py          # work in attempt.py
# ... 45 minutes ...
python3 test_diagnostic.py attempt.py

The test runner reports per gate, so a partial result is a real result. It also prints which gate you reached and when — record the wall-clock time at which each gate first passed, because time-to-first-passing-gate is the single most predictive metric in this whole battery (see inference I3 in ../research/findings.md).

The rules that make it diagnostic

1. Narrate out loud the entire time, recorded. Restate the problem, state your approach, state complexity, name the invariant you are protecting. If narrating slows your coding noticeably, that is a finding — write it down. It is one of the most common causes of a passed-on-paper, failed-in-room outcome.
2. Open gates in order. Do not read gate 3 before gate 1 passes. The format's whole difficulty is that you cannot design for requirements you have not seen, and reading ahead destroys the measurement.
3. Record the clock time when each gate first passes. Write it in the log at the bottom of problem.md.
4. If you finish all four before 45 minutes, write down the elapsed time and stop. Do not polish. Speed is the variable being measured.

Part 2: System Design (45 minutes)

Problem: d2-system-design.md — a fault-tolerant distributed job scheduler. This is the reported screen design question, verbatim in shape.

Deliverable: a written design document plus a diagram. Both are graded. Producing a written artifact under time pressure is itself the skill — it appears in the design rounds, in the take-home grading criteria, and in the deep dive.

Use the template in the problem file. Do not skip the "tradeoffs I explicitly rejected" section — reported sources name "name-dropping technologies without defending the tradeoff" as the leading design-round anti-pattern, and that section is where the antidote lives.

Time budget inside the 45: roughly 5 minutes requirements and scale, 5 minutes API and data model, 10 minutes high-level architecture and diagram, 15 minutes deep dive on the two hardest components, 10 minutes failure modes and tradeoffs.

Part 3: Python Internals Quiz (30 minutes)

Quiz: d3-python-internals.md — 20 questions, closed book.

Answer in prose, briefly. Several questions ask you to predict program output; write your prediction before running anything, and do not run anything until scoring. The gap between your prediction and reality is the actual measurement — a question you got right by running the code measures nothing.

Mark each answer with your confidence: certain / fairly sure / guessing. A confident wrong answer is a different and more dangerous defect than an admitted gap, and the rubric scores them differently.

Part 4: Behavioral, Written (40 minutes)

Prompts: d4-behavioral.md — three prompts, written answers.

Written rather than spoken, deliberately: writing exposes whether the content is there. Spoken delivery can paper over a story with no decision in it, and delivery is a separately trainable skill you will drill later. Right now we are measuring whether you have the raw material.

Roughly 12 minutes each, plus 4 minutes to re-read. Do not edit for polish — the rubric scores decision content, tradeoff articulation, and scope, not prose quality.

Scoring

Score yourself against RUBRIC.md after all four parts are complete, using ANSWER-KEY.md.

The rubric maps each part's score to a starting level per track, which is what determines the shape of PLAN.md:

Score honestly, and if in doubt score down. A generous rubric is the one thing that guarantees you fail the real loop. It costs nothing to be told you are L1 and discover in week 6 that you are L2. The reverse costs the offer.

Recording Your Scores

Write your results into scores/ using the template there, then tell me the numbers. Only then does PLAN.md get written.

The minimum I need to build the plan:

The two subjective fields matter as much as the numbers. Where you froze localizes the gap far more precisely than the aggregate score does.

Monthly Re-Tests

Re-run at roughly weeks 4, 9, 13, 17, 21, and 25. Variants live beside this file as they are generated (retest-01/, retest-02/, …) — same shape, different problems, so you are measuring skill rather than recall.

At each re-test:

1. Take the battery cold.
2. Score it.
3. Compare against the trend line in scores/.
4. Rebalance the plan. If a track has reached L3, its hours move to the weakest track. This is the mechanism that keeps a six-month plan from becoming a six-month ritual.
5. Re-run the coverage audit.
6. Re-run the Phase 0 search. If something newer and better-sourced than the source report appears, supersede it.

Rules I Will Hold You To

• No reading ahead. Gate N+1 stays closed until gate N passes.
• No tools. No AI, no search, no docs. This measures the floor.
• Hard stops. Timer ends, hands off.
• Predict before running. Part 3 measures your model of the runtime, not the runtime.
• Score down when unsure. See Scoring.
• Record the freeze points. Where you got stuck is worth more than what you scored.
• Completion is never "I read it." Nothing in this program is marked done on the basis of reading. Only a passed drill, a working artifact, or a scored mock counts.

References

• ../research/findings.md — why each part is shaped this way
• ../research/source-report.md — the 41-row fidelity checklist
• RUBRIC.md — scoring bands and level mapping
• ANSWER-KEY.md — reference answers, after you finish
• ../mocks/README.md — the weekly scored mock protocol this feeds into
• Excalidraw — https://excalidraw.com (reported design-round tool)

D1 — Resumable Iterator with Serializable State

45 minutes. Four gates. Narrate out loud, recorded.

Open one gate at a time. Do not scroll past a gate until its tests pass. The entire diagnostic value of this problem is that you cannot design for requirements you have not seen yet.

Table of Contents

• Setup
• The Prompt, As An Interviewer Would Say It
• Gate 1: Basic Resume
• Gate 2: Batching
• Gate 3: Map and Filter
• Gate 4: Flat Map and Mid-Group Checkpoints
• Timing Log
• Narration Self-Score

Setup

cp starter.py attempt.py
python3 test_diagnostic.py attempt.py           # runs all gates, reports per gate
python3 test_diagnostic.py attempt.py --gate 1  # run one gate only

Start the timer. Start the recorder.

The Prompt, As An Interviewer Would Say It

"I'd like you to build a resumable iterator. The idea is: you're processing a big stream of records, and the process can die at any point. When it comes back, you want to pick up where you left off — without re-processing anything you already emitted, and without holding the whole stream in memory.

So the object wraps a source, you iterate it normally, and at any point you can ask it for a checkpoint. That checkpoint needs to be something you could write to disk — JSON, basically. Later, you hand the checkpoint plus the same source back, and you get an iterator that produces exactly the items you hadn't gotten to yet.

Assume the source is replayable — you can call the factory again and get the same sequence. Start there and we'll build on it."

What is not said, and what you should clarify out loud:

• Is the source finite? (Assume it may be very large; do not materialize it.)
• Is the source deterministic across replays? (Yes — that is the premise.)
• What if the checkpoint is from a different source? (Out of scope; a version field is enough.)
• Does state() before any iteration mean "start from the beginning"? (Yes.)

Asking these earns real points. Assuming them silently does not.

Gate 1: Basic Resume

Implement ResumableIterator:

it = ResumableIterator(lambda: range(10))
first = [next(it) for _ in range(4)]          # [0, 1, 2, 3]
ckpt = it.state()                              # JSON-serializable dict
resumed = ResumableIterator.resume(lambda: range(10), ckpt)
rest = list(resumed)                           # [4, 5, 6, 7, 8, 9]

Requirements:

• ResumableIterator(source_factory) where source_factory is a zero-argument callable returning a fresh iterable.
• Implements the iterator protocol: __iter__ returns self, __next__ yields items, raises StopIteration at the end.
• state() returns a dict that survives json.dumps / json.loads round-tripping.
• ResumableIterator.resume(source_factory, state) is a classmethod returning a new iterator positioned after the last item that was emitted.
• The source must not be materialized into a list. The test asserts this by passing a generator-backed factory and counting how many items get pulled.
• state() on a fresh, un-iterated instance must round-trip to an iterator producing the full sequence.

Run: python3 test_diagnostic.py attempt.py --gate 1

Stop. Record the time. Only then read gate 2.

Gate 2: Batching

Add batch(n):

it = ResumableIterator(lambda: range(10))
batches = it.batch(3)
assert next(batches) == [0, 1, 2]
assert next(batches) == [3, 4, 5]
ckpt = it.state()
resumed = ResumableIterator.resume(lambda: range(10), ckpt)
assert list(resumed.batch(3)) == [[6, 7, 8], [9]]

Requirements:

• batch(n) returns an iterator of lists, each of length n except possibly the last.
• n <= 0 raises ValueError.
• A checkpoint taken after a yielded batch resumes exactly at the next unemitted item.
• batch must be lazy. The test uses a source that raises if pulled more than one batch ahead.

Run: python3 test_diagnostic.py attempt.py --gate 2

Stop. Record the time. Only then read gate 3.

Gate 3: Map and Filter

Add a transform pipeline. Transforms are declared at construction and are part of the iterator's identity, not part of the state.

it = ResumableIterator(lambda: range(10)).map(lambda x: x * 10).filter(lambda x: x % 20 == 0)
first = [next(it), next(it)]                   # [0, 20]
ckpt = it.state()
resumed = ResumableIterator.resume(
    lambda: range(10), ckpt
).map(lambda x: x * 10).filter(lambda x: x % 20 == 0)
assert list(resumed) == [40, 60, 80]

Requirements:

• .map(fn) and .filter(pred) are chainable and may be interleaved in any order.
• Transforms apply in declaration order.
• Resume must be exact. The concatenation of what you emitted before the checkpoint and what the resumed iterator emits must equal the un-checkpointed output, for a checkpoint taken at every position.
• The obvious implementation — "count emitted outputs, skip that many on resume" — is wrong here, and the tests will catch it. Think about what the checkpoint has to describe: a position in the source, or a position in the output?

Run: python3 test_diagnostic.py attempt.py --gate 3

Stop. Record the time. Only then read gate 4.

Gate 4: Flat Map and Mid-Group Checkpoints

Add .flat_map(fn), where fn maps one item to zero or more items.

it = ResumableIterator(lambda: range(4)).flat_map(lambda x: [x] * x)
# source 0,1,2,3 expands to groups [], [1], [2,2], [3,3,3]
# full output: [1, 2, 2, 3, 3, 3]
first = [next(it) for _ in range(4)]           # [1, 2, 2, 3]  <- checkpoint lands INSIDE the x=3 group
ckpt = it.state()
resumed = ResumableIterator.resume(lambda: range(4), ckpt).flat_map(lambda x: [x] * x)
assert list(resumed) == [3, 3]                 # not [3, 3, 3] — one was already emitted

Requirements:

• .flat_map(fn) chains with .map and .filter in any order and any depth.
• A checkpoint may land in the middle of an expanded group. Resuming must not re-emit the sub-items already emitted from that group, and must not skip the ones that remain. This is the whole gate. A source-index-only checkpoint is insufficient.
• The state dict stays JSON-serializable and stays O(1) in size — it must not grow with the number of items consumed. The test asserts a size bound.
• Still no materialization of the source.

Run: python3 test_diagnostic.py attempt.py --gate 4

Timing Log

Fill this in as you go. Copy it into ../scores/ afterwards.

Time-to-first-passing-gate: ______ minutes

This number matters more than the total. In a gated format, an unopened gate scores zero regardless of how good your unwritten design was — so the compounding metric is how fast you get something correct and extensible. See inference I3 in ../../research/findings.md.

Narration Self-Score

Listen back to the recording. Score 0–5, one point each:

Score: ___ / 5

Going silent while stuck is the most common and most costly narration failure. The interviewer cannot give you a hint they do not know you need, and silence reads as being lost even when you are thinking productively.

D2 — System Design: Fault-Tolerant Distributed Job Scheduler

45 minutes. Hard stop. Produce a written design document and a diagram. Both are graded.

This is the reported technical-screen design question, verbatim in shape (../research/source-report.md row 8).

Table of Contents

• The Prompt, As An Interviewer Would Say It
• What You Must Produce
• The Design Template
• Time Budget Inside the 45 Minutes
• Hidden Follow-Ups
• What Is Actually Being Measured
• Submission

The Prompt, As An Interviewer Would Say It

"Let's design a distributed job scheduler. Users submit jobs — some run once at a specific time, some run on a recurring schedule, like a cron. The system runs them on a fleet of workers.

The important part is that it has to be fault-tolerant. Workers die. The scheduler itself can die. The network partitions. Jobs still need to run, and we care a lot about not silently dropping one.

Take it wherever you think is interesting. I'll interrupt with questions."

The deliberate under-specification is the test. "Take it wherever you think is interesting" means you choose which components are load-bearing. Choosing badly — spending twenty minutes on the REST API surface and four on execution semantics — is the most common way this round is lost, and it is lost silently: nothing goes wrong, you just never get to the part that mattered.

Clarify out loud, before designing. At minimum:

• Scale. How many jobs, at what submission rate, at what concurrency? (Pick numbers and say them. "Let's say 10M scheduled jobs, 50k executions/minute peak, jobs run from 100ms to 6 hours." An interviewer will correct you if it matters. Silence about scale is a red flag.)
• Delivery semantics. At-least-once or at-most-once? (This is the single most important clarifying question in the problem. Exactly-once execution of a side-effecting job is not achievable without cooperation from the job itself. If you do not say this, you have missed the core of the question.)
• Latency tolerance. Is a job firing 30 seconds late a bug or a shrug?
• Ordering. Do jobs for the same user/tenant need serialization?
• Multi-tenancy. Isolation and fairness between tenants, or a single trusted user?

What You Must Produce

Two artifacts, both inside the 45 minutes:

1. A design document at attempt-d2.md (create it next to this file), following the template below.
2. A diagram, drawn in Excalidraw — reported to be the actual design-round tool. Export a PNG next to your doc. Drawing under time pressure is a motor skill and it is being measured.

The Design Template

This is the template you will use for every design in this program. Learn it now; it is the thing that keeps you from rambling when the clock is running.

# Design: <name>

## 1. Requirements and scope
Functional. Non-functional. Explicitly out of scope.

## 2. Scale numbers
The numbers I assumed, and the arithmetic I did with them.
QPS, storage, network, concurrency, growth.

## 3. API surface
The three to five calls that matter. Request/response shapes.

## 4. Data model
Tables/collections, keys, indexes, and WHY those keys.

## 5. High-level architecture
Components and the flow between them. This is the diagram.

## 6. Deep dive: the two hardest components
Not the easy ones. The two where the design could actually fail.

## 7. Failure and recovery
For each failure: how it is DETECTED, how it is CONTAINED, how it RECOVERS.

## 8. Bottlenecks and evolution
What breaks first at 10x. What I would change.

## 9. Tradeoffs I explicitly rejected, and why
The alternatives I considered and turned down.

Section 9 is not optional. Reported sources name "name-dropping technologies without being able to defend the tradeoff" as the leading design-round anti-pattern. Section 9 is where you prove you did not do that — and writing it forces you to have actually considered alternatives rather than pattern-matching to the first architecture you have seen before.

Time Budget Inside the 45 Minutes

If you are still drawing boxes at minute 25, you have failed the round regardless of how good the boxes are. The deep dive is where senior and staff signal lives, and it needs fifteen uninterrupted minutes.

Hidden Follow-Ups

Do not read these until your 45 minutes are up. They are what a real interviewer interrupts with, and the rubric awards points for having pre-empted them in your written doc without being asked.

What Is Actually Being Measured

Five things, in descending order of weight:

1. Did you identify the right hard parts? For this problem they are (a) exactly-once dispatch semantics under scheduler failure, and (b) worker liveness and lease expiry with the resulting split-brain risk. Everything else is plumbing.
2. Do your failure sections have all three legs — detection, containment, recovery? "It retries" is not a failure analysis.
3. Did you do arithmetic? Any number at all beats no numbers. A claim like "50k executions/minute is ~830/s, so at 200 jobs/s/worker that's 5 workers plus headroom" is worth more than a paragraph of adjectives.
4. Did you reject something explicitly? Section 9.
5. Did you stay at the right altitude? Sketching a class hierarchy for the job model is too low. "We'll use a queue" with no discussion of visibility timeouts is too high.

Notably absent: whether your design is the same as the interviewer's. It does not need to be.

Submission

• Design doc: attempt-d2.md (next to this file)
• Diagram: attempt-d2.png
• Score against RUBRIC.md → Part 2
• Compare against ANSWER-KEY.md → D2 after you have scored yourself unaided, so you measure your own judgement rather than your ability to recognize a good answer when shown one

D3 — Python Internals Quiz

30 minutes. 20 questions. Closed book.

Predict before you run. Several questions ask for program output. Write your prediction first and run nothing until scoring. A question you got right by executing the code measures nothing — the whole point is to measure your model of the runtime, not the runtime.

Mark each answer certain / fairly sure / guessing. Confident-wrong is scored separately from admitted-gap, because they are different defects requiring different fixes.

Table of Contents

• How to Answer
• Section 1: Iterators and Generators
• Section 2: Async and Concurrency
• Section 3: Memory and the Object Model
• Section 4: Data Model and Performance
• Answer Sheet

How to Answer

Two sentences per question is enough. What is being scored is whether you know the mechanism, not whether you can recite the manual. "It raises TypeError" is half a point; "it raises TypeError because a just-started generator is suspended before its first yield, so there is no expression waiting to receive the sent value" is the full point.

Assume CPython on a recent 3.x with the default (GIL-enabled) build unless a question says otherwise.

Section 1: Iterators and Generators

Q1. What happens, and why?

def echo():
    while True:
        received = yield
        print("got", received)

g = echo()
g.send("hello")

Q2. What does list(outer()) produce?

def inner():
    yield 1
    yield 2
    return "done"

def outer():
    result = yield from inner()
    yield result

Q3. Does cleanup print? Explain the exact mechanism, and name the exception involved.

def gen():
    try:
        yield 1
        yield 2
    finally:
        print("cleanup")

g = gen()
next(g)
del g

Q4. What does this print, and what is the design defect?

class Countdown:
    def __init__(self, n):
        self.n = n
    def __iter__(self):
        while self.n > 0:
            yield self.n
            self.n -= 1

c = Countdown(3)
print(list(c), list(c))

Q5. What is the value of next(a) on the last line, and why is that surprising?

a = iter([1, 2, 3, 4])
b = [10, 20]
pairs = list(zip(a, b))
next(a)

Q6. What is the difference between an iterable and an iterator? Why does iter(x) is x hold for one and not the other, and what breaks if you get it wrong?

Q7. You have a generator g that has already yielded three values. You call g.throw(ValueError("x")). Where does the exception appear from the generator's point of view, and what are the three possible outcomes?

Q8. Why is itertools.tee(it, 2) a memory hazard? Describe the situation in which it buffers the entire stream.

Section 2: Async and Concurrency

Q9. One of these two tasks raises. What happens to the other one?

async def boom():
    raise ValueError("boom")

async def slow():
    await asyncio.sleep(10)
    print("slow finished")

await asyncio.gather(boom(), slow())

Then: how does asyncio.TaskGroup differ, and what exception type does it raise?

Q10. asyncio.CancelledError — what does it inherit from, and what is the practical consequence for code that writes except Exception: inside a coroutine?

Q11. What is wrong with this, and what is the standard fix?

async def main():
    for url in urls:
        asyncio.create_task(fetch(url))
    await asyncio.sleep(5)

Name two independent defects.

Q12. A coroutine calls time.sleep(2) (not asyncio.sleep). Describe precisely what happens to the event loop and to every other pending task. Then name the correct escape hatch for genuinely blocking work.

Q13. What exactly does the GIL guarantee, and what does it not? Is counter += 1 on a shared integer thread-safe? Is some_list.append(x)? Explain the difference in terms of bytecode.

Q14. What is the current status of free-threaded CPython? Name the relevant PEPs, the version in which the status changed, whether it is the default build, and roughly what the single-threaded overhead is.

Q15. Give the decision rule for threads vs. processes vs. asyncio. For each, state the workload it wins on and the specific cost that makes it lose elsewhere.

Section 3: Memory and the Object Model

Q16. Does __del__ run for objects in a reference cycle? What changed, and in which Python version? What is the remaining hazard?

class Node:
    def __init__(self): self.ref = None
    def __del__(self): print("__del__ ran")

x = Node(); y = Node()
x.ref = y; y.ref = x
del x, y

Q17. What does __slots__ actually remove, what does it break, and what happens to the memory saving when a subclass of a slotted class does not itself declare __slots__?

Q18. Why is sys.getsizeof(some_list_of_10000_strings) misleading? What does it measure, and what would you use instead to answer "how much memory is this actually costing me?"

Section 4: Data Model and Performance

Q19. Attribute lookup precedence: rank these four in the order CPython consults them for instance.x — instance __dict__, data descriptor on the type, non-data descriptor on the type, __getattr__. Then explain why @property can shadow an instance attribute but a plain function cannot.

Q20. __getattr__ vs __getattribute__ — when is each called, which one is the performance hazard, and what is the classic infinite-recursion bug in __getattribute__?

Answer Sheet

Copy this, fill it in, and score against ANSWER-KEY.md.

Correct: ___ / 20 Confident-wrong (marked certain but wrong): ___

The second number is the one that matters most. A gap you know about is a study item. A gap you are confident about is a landmine — it is the thing you will assert in an interview and be corrected on, and the correction costs far more than the admission would have. Every confident-wrong answer goes straight into the review/ spaced-repetition queue at the 1-day interval.

D4 — Behavioral, Written

40 minutes. Three prompts, roughly 12 minutes each, plus 4 to re-read.

Written rather than spoken, deliberately. Writing exposes whether the content is there. Delivery can paper over a story with no decision in it, and delivery is separately trainable later. Right now we are measuring raw material.

Table of Contents

• What Is Being Measured
• Prompt 1: The Architecture Decision
• Prompt 2: The Disagreement You Lost
• Prompt 3: Where Is AI Headed
• The Structure To Use
• Submission

What Is Being Measured

The reported signal for these rounds is technical leadership, architecture decisions spanning teams, and driving consensus under pressure — with concrete tradeoffs, not soft-skills answers (../research/source-report.md rows 33–36).

There is a second finding that raises the stakes: reported sources name the values / culture round as the most common failure point at a peer lab. That is a remarkable claim about companies whose technical bars are this high, and it means behavioral preparation is not the part you do in week eleven.

And a third: AI-lab levelling is compressed — an "L5 Senior" title reportedly carries Staff-equivalent scope (../research/findings.md). So these are graded at Staff altitude. A story where you personally made a good technical call on your own service is a Senior story. A Staff story has other teams in it, has people who disagreed, and has a decision that was expensive to get wrong.

Prompt 1: The Architecture Decision

"Tell me about an architecture decision you made that affected teams beyond your own. What was the decision, what were the alternatives, and how did it turn out?"

Write 400–600 words. Your answer must contain, explicitly:

• The decision itself, stated in one sentence in the first 60 words. Not the background. The decision.
• The constraint that made it hard. If there was no constraint, it was not a decision, it was a preference.
• At least two alternatives you seriously considered, and the specific reason each lost. "It wouldn't scale" is not a reason. "It required a synchronous cross-region call on the read path, which would have put p99 above our 200ms budget" is a reason.
• Who disagreed and what they wanted instead. If nobody disagreed, the decision was not consequential enough to be a Staff story — pick a different one.
• How you actually got alignment. Not "I explained my reasoning." What did you do? Wrote a doc? Built a prototype that settled it with data? Conceded something to get the important half?
• The measured outcome, with a number.
• What you got wrong. Every real decision has one. Omitting it reads as either dishonesty or as not having looked.

Draw from your actual history — multilingual search and recommendation, streaming, networking, enterprise infra, cloud. Ranking-pipeline redesigns, index-serving migrations, and embedding infrastructure decisions are all excellent Staff-altitude material if you write the tradeoff rather than the tour.

Prompt 2: The Disagreement You Lost

"Tell me about a technical disagreement where you did not get your way. What happened, and what do you think now?"

Write 300–500 words.

This is the highest-signal behavioral prompt in existence and it is the one candidates prepare least. It cannot be faked, because the failure modes are so visible:

What a strong answer has:

• A disagreement that mattered — where being wrong was expensive.
• Your position, stated as strongly as you actually held it. Do not soften it retroactively.
• Their position, stated fairly enough that they would recognize it. This is the single most discriminating element of the whole answer.
• What actually decided it, and whether the process was sound even if the outcome was not.
• How you behaved after losing. Did you commit or did you sandbag?
• Your honest current read: sometimes "they were right"; sometimes "I still think I was right and here is the evidence that accumulated"; sometimes "we were both solving the wrong problem." All three are strong. Only performed humility is weak.

Prompt 3: Where Is AI Headed

"Where do you think AI is headed over the next couple of years?"

Write 250–400 words. Reported as an actual recruiter-screen question (../research/source-report.md row 4).

Required structure — this is what separates a position from a newsletter summary:

1. A specific, falsifiable claim. Not "AI will transform industries." Something that could turn out to be wrong, and that you would notice being wrong.
2. Evidence. Something you have measured, built, or can cite with a number.
3. A falsifier. "Here is what would change my mind." Stating one is the strongest single move available in this answer, and almost nobody does it.
4. The connection to what you would build. Why this claim makes you useful here.

An example claim shape, which you should not copy but should match in specificity: "The binding constraint on useful AI over the next two years is inference cost and latency under agentic workloads, not model capability — because one user action now becomes tens of model calls, and decode is memory-bandwidth-bound so the cost curve doesn't fall as fast as capability rises."

Write yours from what you actually believe and can defend. A claim you cannot defend under one round of pushback is worse than a vaguer claim you can.

The Structure To Use

Not STAR. STAR was designed for behavioral interviews at companies that wanted to know if you were a good teammate, and it front-loads situation — the least interesting part — while burying the decision.

Use DTAO instead, and lead with the decision:

Context goes in a clause, not a paragraph. "On the multilingual ranking pipeline, we decided X" is enough situation-setting for any interviewer. If they need more they will ask, and them asking is good — it means they are engaged rather than waiting for you to finish.

Submission

Write into attempt-d4.md next to this file. Then:

1. Score against RUBRIC.md → Part 4, before reading the answer key.
2. Read ANSWER-KEY.md → D4 for the graded examples and re-score.
3. Note which of your 12–15 career stories these three drew on. That list becomes the seed of the story bank in ../tracks/behavioral/README.md.

On honesty: these are your stories. I will not invent them, embellish them, or let you present a Senior-scope story as Staff-scope. If the raw material for a required story category is genuinely absent from your history, that is a finding — the fix is to go acquire the experience or to find the closest real analogue and be straight about its scope, not to inflate the story you have.

Diagnostic Answer Key

Do not read this before you have completed all four parts and scored yourself unaided.

Every output prediction below was verified against a live CPython 3.13 interpreter. Where the answer depends on version, that is stated.

Table of Contents

• D1: Coding
  • What Weak, Median, and Strong Look Like
  • The Key Insight
• D2: System Design
  • The Two Hardest Components
  • A Reference Answer Sketch
  • Answers to the Hidden Follow-Ups
• D3: Python Internals
• D4: Behavioral
• References

D1: Coding

The reference solution is d1-coding/solution.py. Read its module docstring first — it explains the representation choice, which is the entire problem.

What Weak, Median, and Strong Look Like

Note what separates strong from median: not more knowledge — an earlier question. The clarifying question about replay determinism is what makes "position in the source" the obvious representation. That is why narration is scored: the question that saves you twenty minutes is one you ask out loud in minute two.

The Key Insight

The naive checkpoint — "how many outputs have I emitted" — passes gates 1 and 2 and dies at gate 3. With a filter in the pipeline, output count does not determine source position without replaying the pipeline anyway.

The representation that survives all four gates is two integers:

(source_pos, sub_index)
    source_pos -- index of the source item currently being emitted from
    sub_index  -- how many outputs of THAT item have already been emitted

Every transform then becomes the same thing — a function from one source item to a list of zero or more outputs:

Resume becomes uniform with no special cases: skip source_pos source items, expand the next one, drop the first sub_index outputs, continue. Gate 4 is free.

This is the actual lesson of the progressive format, and it generalizes far beyond this problem: the gates are constructed so that a locally-reasonable representation passes the early ones and collapses at the third. You do not get to see gate 4 first. So the trainable skill is not "solve harder problems" — it is choosing a representation that survives requirements you have not been told yet, by asking what is invariant about the problem rather than what is sufficient for the stated requirement.

Concretely, the habit: before writing state-bearing code, ask "if the requirements got harder in the most obvious direction, what would break first?" Here, the obvious direction is "transforms" and the thing that breaks is the output-count assumption.

D2: System Design

The Two Hardest Components

If your deep dive was not on these two, the round is a hire at best regardless of how polished the rest was. Identifying the load-bearing parts is the senior signal.

1. Dispatch semantics under scheduler failure. Three or more scheduler replicas exist for availability. All of them can see that job J is due at 09:00:00. Exactly one must dispatch it. The options, with their real costs:

The correct answer is any of them with the tradeoff named. The wrong answer is not noticing the problem exists.

2. Worker liveness, leases, and split brain. A worker claims a job with a lease. It partitions. The lease expires. The scheduler must decide: is the worker dead, or is it running the job on the other side of the partition?

You cannot tell these apart. That is not a gap in the design, it is the actual constraint, and saying so out loud is worth more than any mechanism you propose.

So you choose a failure mode:

• Re-dispatch on lease expiry → at-least-once, possible concurrent double execution.
• Do not re-dispatch until positively confirmed dead → at-most-once, possible silent drop.

The prompt says "we care a lot about not silently dropping one," which selects at-least-once — and therefore obligates you to say "so job handlers must be idempotent, and here is the idempotency key I give them."

The mechanism that makes at-least-once safe is a fencing token: a monotonically increasing number issued with each lease. The job's write path rejects writes carrying a token lower than the highest it has seen. Without fencing, the partitioned zombie worker's late write silently corrupts state after the replacement has already run. Naming fencing unprompted is a strong staff-level signal.

A Reference Answer Sketch

                       ┌──────────────┐
  submit ─────────────▶│   API tier   │
                       └──────┬───────┘
                              │  write job + next_run_at
                              ▼
                    ┌───────────────────┐
                    │  Job store (SoR)  │  partitioned by job_id
                    │  jobs, schedules, │  index on (shard, next_run_at)
                    │  executions       │
                    └─────────┬─────────┘
                              │  poll due jobs per owned shard
                              ▼
   ┌──────────────────────────────────────────┐
   │  Scheduler replicas (own disjoint shards)│  lease + fencing token
   │  tick -> claim -> enqueue                │  membership via etcd/Raft
   └───────────────────┬──────────────────────┘
                       │  enqueue (job_id, run_id, fence)
                       ▼
              ┌─────────────────┐
              │  Dispatch queue │  visibility timeout ≈ lease
              └────────┬────────┘
                       ▼
              ┌─────────────────┐        heartbeat / lease renew
              │  Worker fleet   │◀──────────────────────────────
              └────────┬────────┘
                       │  execution record (run_id, status, fence)
                       ▼
              ┌─────────────────┐
              │   Executions    │  the audit log: dispatched != completed
              └─────────────────┘

Arithmetic worth doing out loud: 50k executions/minute is ~830/s. At 200 concurrent jobs per worker and a 10s mean duration, one worker sustains ~20/s, so ~42 workers plus headroom — call it 60. 10M scheduled jobs at ~1KB of metadata is ~10GB, which fits comfortably in a partitioned relational store; the executions table is the one that grows without bound and needs a retention policy. Any arithmetic beats none.

Answers to the Hidden Follow-Ups

1. Partitioned worker, job still running. You cannot distinguish it from a dead worker. Choose at-least-once, re-dispatch on lease expiry, and make it safe with a fencing token checked on the job's write path, plus an idempotency key handed to the handler.
2. Three replicas, one 09:00 job. Leader election, shard ownership, or an atomic claim — any is acceptable with its cost named. Point out that the claim must be atomic with respect to the store, and that a SELECT followed by an UPDATE without a conditional predicate is a race.
3. Two-hour outage, 40k overdue jobs. This is a product decision the design must expose, not silently make. Per-job catch-up policy: run_all / run_latest_only / skip. Then rate-limit the catch-up drain so it does not brown out the fleet — a token bucket on dispatch, with overdue jobs at lower priority than newly-due ones.
4. One tenant pins workers for 6 hours. Per-tenant concurrency caps, weighted fair queuing on dispatch, and separate pools segmented by expected duration so a long-job tenant cannot starve short-job latency. Mention that duration is declared by the tenant and therefore must be enforced with a kill timer, not trusted.
5. How do you know a job ran? The executions table is the answer: dispatched and completed are different states, and only the worker's own write moves it to completed. At-least-once promises "dispatched at least once," not "ran exactly once" — say that distinction explicitly.
6. Why not just Postgres? Postgres with SELECT ... FOR UPDATE SKIP LOCKED is genuinely the right answer up to a few thousand dispatches/second, and saying so is a strength — it shows you optimize for operability rather than for résumé. It stops working when the due-job index becomes a write hotspot and vacuum can't keep up with the churn on next_run_at. The next step is partitioning by shard, then moving the hot dispatch path to a purpose-built store while keeping Postgres as the system of record.
7. Clock skew. Never compare wall-clock timestamps across nodes to decide lease expiry. Measure leases as elapsed time on the node that owns the decision, using a monotonic clock. Bound acceptable skew with NTP, and treat a node whose skew exceeds the bound as unhealthy. If you need cross-node ordering, that is what hybrid logical clocks are for.

D3: Python Internals

Q1. TypeError: can't send non-None value to a just-started generator. A freshly created generator is suspended before its first yield, so there is no yield expression waiting to receive a value. You must prime it — next(g) or g.send(None) — to advance to the first yield, and only then can you send. (Verified.)

Q2. [1, 2, 'done']. yield from delegates iteration to inner, and the sub-generator's return value becomes the value of the yield from expression (PEP 380). It is not yielded by inner; it is handed to outer, which then yields it explicitly. (Verified.)

Q3. Yes, cleanup prints. del g drops the last reference, CPython's reference counting finalizes the generator immediately, and generator finalization calls close(), which throws GeneratorExit in at the suspended yield. The finally runs as the exception propagates. Two subtleties worth stating: this is refcount-driven and therefore prompt in CPython but not guaranteed on other implementations; and if the generator catches GeneratorExit and yields again, Python raises RuntimeError: generator ignored GeneratorExit. (Verified.)

Q4. [3, 2, 1] []. The defect is that iteration state lives on the instance (self.n) rather than in the iterator. __iter__ is a generator function, so each call returns a fresh generator — but they all mutate and read the same self.n, which the first pass drove to 0. The fix is to keep iteration state local: for i in range(self.n, 0, -1): yield i. This is the iterable/iterator confusion that makes a class silently single-use. (Verified.)

Q5. next(a) is 4. zip pulled 1 and 2 from a and paired them, then pulled 3 from a, asked b for a third item, got StopIteration, and stopped — discarding the 3 it had already taken. Non-obvious because zip looks non-destructive but silently consumes one extra item from every iterator before the one that ends first. This is the bug behind "my chunked reader loses a record at the boundary." itertools.zip_longest, or buffering the pulled item, avoids it. (Verified.)

Q6. An iterable implements __iter__ returning a new iterator. An iterator implements both __iter__ (returning self) and __next__, and carries the position. So iter(x) is x holds for iterators and not for iterables. Getting it wrong produces two classic bugs: a "collection" that can only be looped over once (you returned an iterator from __iter__ and reused it), and nested loops over the same object silently sharing a cursor.

Q7. g.throw(exc) raises the exception at the point of the suspended yield inside the generator, as if that yield expression had raised. Three outcomes: (a) the generator does not catch it — it propagates out of throw() to the caller and the generator is closed; (b) the generator catches it and yields again — throw() returns that value; (c) the generator catches it and returns — throw() raises StopIteration.

Q8. tee must buffer every item that one consumer has read and the other has not. If you advance one branch to the end before touching the other, the internal deque holds the entire stream — you have silently materialized the thing you used a generator to avoid. tee is only safe when consumers advance roughly in lockstep. Independent full passes should re-create the source instead.

Q9. slow() keeps running. gather with the default return_exceptions=False propagates the first exception to the awaiter immediately, but it does not cancel the sibling tasks — they are orphaned and continue in the background. (Verified: the raise surfaces, then slow completes normally afterwards.) asyncio.TaskGroup (3.11+) fixes this with structured concurrency: a failing child causes the remaining children to be cancelled and the group's __aexit__ to raise an ExceptionGroup (caught with except*). Naming gather's orphaning as a resource-leak bug, not a stylistic difference, is the senior answer.

Q10. Since Python 3.8, asyncio.CancelledError inherits from BaseException, not Exception. (Verified: issubclass(CancelledError, Exception) is False.) Practical consequence: a broad except Exception: will not swallow cancellation — which is the point, because swallowing it makes a task uncancellable. The corollary: if you catch CancelledError explicitly for cleanup, re-raise it, or you break the cancellation contract.

Q11. Two defects. (a) The tasks are not awaited — asyncio.sleep(5) is a guess, and if the fetches take six seconds the loop exits with work unfinished and results discarded. (b) No strong reference is kept to the tasks — the event loop holds only a weak reference, so a task can be garbage-collected mid-execution and vanish silently. The fix for both: async with asyncio.TaskGroup() as tg: for url in urls: tg.create_task(fetch(url)). Failing that, collect the tasks into a set, await asyncio.gather(*tasks), and discard on completion.

Q12. time.sleep(2) blocks the entire event loop thread. The loop is a single thread running a ready-callback queue; a blocking call means no other task runs, no I/O is polled, no timers fire, and nothing is cancelled — for two full seconds. Every pending task's latency grows by 2s. The escape hatch is await asyncio.to_thread(blocking_fn, ...) (or loop.run_in_executor) for I/O-bound blocking work, and a ProcessPoolExecutor for CPU-bound work. This is the most common async production bug: one synchronous library call in a request handler, and the whole service's tail latency collapses.

Q13. The GIL guarantees that exactly one thread executes CPython bytecode at a time, so individual bytecode instructions and operations implemented in C that never release it are effectively atomic. It does not make multi-bytecode sequences atomic. some_list.append(x) is thread-safe — one C-level call that does not release the GIL. counter += 1 is not — it compiles to load, add, store, and the interpreter can switch threads between them, losing updates. The GIL protects interpreter internals, not your invariants.

The senior-level addendum, worth a point on its own. Since CPython 3.10 the eval breaker — the flag that hands the GIL to another thread — is checked only at specific instructions, mainly backward jumps and calls, not between every bytecode. So the textbook demonstration, a bare counter += 1 in a tight loop, frequently loses nothing, because the check lands on JUMP_BACKWARD, which is after the STORE. Put a call between the load and the store (counter = add_one(counter), or an operand whose __add__ is written in Python) and updates vanish immediately — ../tracks/python-internals/experiments/exp03_gil.py measures 3% and 61% loss respectively on the same machine where the naive version loses zero. The point: "I ran it and it didn't lose anything" is not evidence of atomicity. Whether a read-modify-write is interrupted depends on interpreter version, code shape, and operand type, none of which is a contract you can rely on.