Track A — Coding Under Time Pressure

The reported onsite has two coding rounds, and the first uses a progressive multi-part format that the source candidate explicitly said he did not know how to prepare for (../../research/source-report.md row 41). That makes it the least-practised round in the loop and the highest-leverage thing in this program.

This track is not a LeetCode grind. It is a taxonomy of stateful systems problems built to match what these loops reportedly ask.

→ Study guide: WARMUP.md — the ten patterns from first principles, with complete runnable implementations, complexity tables and failure modes. Read that to learn the material; read this file to know what to practise and how you are scored.

→ QUIZBANK.md — 150 questions asked after your code works, with mechanism-level answers. The round is not decided by the tests passing; it is decided by the ten minutes afterwards when the interviewer asks why. Work a harness problem, then answer that section out loud before reading it.

Table of Contents

• What This Round Actually Is
• Concept Inventory
• The Progressive Harness
• The Problem Set
• Drill Set
• Time-to-First-Correct
• The Talk-While-Coding Checklist
• Failure Modes
• Self-Assessment Rubric
• References

What This Round Actually Is

Three reported facts define it:

1. Progressive gates. Each problem has roughly four stages of increasing difficulty. Each stage must work before the next opens. The reported pass bar is clearing two; at least one source reports a stricter bar. Assume the stricter one — the asymmetry of that error is total.
2. Volume. Multiple sources report that you write substantially more code than in a typical FAANG interview, and that solutions are judged on production quality — real edge cases, maintainable structure — not on cleverness.
3. Practical, not algorithmic. One source states flatly that string-manipulation puzzles do not appear. What appears is stateful data structures, versioning, streaming, parsing, caching, scheduling, and concurrency.

The structural consequence, and it is not obvious: the gated format inverts the normal optimization. In a standard round you can spend fifteen minutes designing before writing. In a gated format, every minute of upfront design is stolen from stages 2–4, and a gate you never open scores zero regardless of how elegant your unwritten design was.

So you need a habit most senior engineers have spent a decade unlearning: build the smallest correct thing fast, then extend it under pressure. But — and this is the tension the format actually tests — your stage-1 code must be extensible, because you will be extending it in eight minutes with no warning about the direction.

Fast and extensible. That is trainable, and this track trains it.

Concept Inventory

Every item names the file that teaches it and the problem that drills it.

A1. Stateful data structures

A2. Streaming and incremental algorithms

A3. Concurrency and backpressure

A4. Rate limiting and scheduling

A5. Parsing and memory

The Progressive Harness

cd tracks/coding/harness
./progressive.py list                       # the catalog
./progressive.py start token-stream-differ  # begin; prints gate 1 ONLY
./progressive.py test  token-stream-differ  # run current gate; unlock on pass
./progressive.py chart                      # time-to-first-gate trend

The harness enforces the format's actual constraint: gate N+1 is not printed until gate N's tests pass. You cannot design for requirements you have not seen, which is precisely the difficulty the real round exercises.

It records, per gate: wall-clock time at first pass, and how many test runs it took. From that it derives the metric that matters — see below.

Rules for using it honestly:

• Do not read problems/*/README.md or solution.py before finishing. They contain the gate structure.
• Do not open the gate tests. Same reason.
• Narrate out loud, recorded, every time.
• When the budget expires, stop. A problem finished in 70 minutes tells you nothing about a 45-minute round.

The Problem Set

Fifteen problems, four gates each. Run ./progressive.py list for the live catalog.

All fifteen have automated gate tests — 60 gates, all green. Run them against the reference solutions any time with python3 harness/runtests.py; the whole suite takes about six seconds. Each problem's solution.py carries a module docstring explaining the representation that survives all four gates, and the harness prints the WARMUP chapter that teaches the pattern once you finish.

Roughly a quarter of the set is deliberately off the source report. One candidate account must not be allowed to narrow preparation into a blind spot — see the anti-narrowing clause.

Drill Set

Time-to-First-Correct

The metric the whole track optimizes. ./progressive.py chart plots it.

Why it dominates: in a gated format an unopened gate scores zero. Two candidates who both understand the problem perfectly, one reaching gate 1 at minute 8 and the other at minute 20, do not finish 12 minutes apart — they finish one to two gates apart, because the later gates are where the time goes.

The trap on the other side: rushing gate 1 with a representation that dies at gate 3 costs more than a slow start. Both failure modes are visible in the harness log — a fast G1 followed by a long G3 gap is the signature of a bad representation, and it is exactly what the extension drill trains against.

The reconciliation is not "design longer." It is asking better clarifying questions in the first two minutes. In both automated problems, one question at minute one determines whether gate 3 is additive or a rewrite. That is the skill.

The Talk-While-Coding Checklist

Every problem, every time, out loud:

1. Restate the problem in your own words.
2. Clarify — at least two questions, and at least one that could change your representation. (Not "should I handle empty input." Something like "is the source replayable?" or "are versions global or per key?")
3. State the approach in two sentences, and name the data structure.
4. State the complexity before implementing, not after.
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 I'm writing a for loop" is a keystroke.
7. When stuck, keep talking. Say what you tried and why it failed. Silence is the single costliest narration failure: the interviewer cannot give you a hint they do not know you need, and it reads as lost even when you are thinking productively.

Self-score 0–5 after each recording. Anything below 3 twice in a row triggers a narration-only drill.

Failure Modes

Self-Assessment Rubric

Level bands

Hire-bar translation

L3 is not "solved it." L3 is "chose a representation at minute three that made minute forty easy."

References

• harness/progressive.py — the harness
• harness/problems/__init__.py — the full catalog with gate briefs
• ../../research/source-report.md — rows 7, 17–23, 41
• ../../research/findings.md — corroborated problem patterns
• ../python-internals/README.md — where Coding 2's follow-ups live
• Sedgewick, R. and Wayne, K. Algorithms, 4th ed. — for the structures, not the puzzles
• Kleppmann, M. Designing Data-Intensive Applications, 2nd ed. — Ch. 3 (LSM, B-trees, WAL), Ch. 7 (snapshot isolation, write skew)
• Brooker, M. Exponential Backoff and Jitter. https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/