Whiteboard Drills & Spoken Scripts

Reading is not interviewing. These six drills convert the book into spoken, timed performance — do each one against a wall clock, out loud, standing at a whiteboard or shared doc, and score yourself against the rubric after, not during. Record audio for drills 4 and 5; you will hate it and it will fix you. Each rubric is out of 20: 16+ means interview-ready for that topic, 12–15 means re-read the chapter and re-run in two days, below 12 means the gap is knowledge, not delivery — go back to the chapter and the lab first.

Drill 1 — Design the tick-to-trade path with a per-stage latency budget (35 min)

Prompt (read aloud, then start the clock): “Design the full path from a market-data packet arriving at the NIC to an order leaving it, for a market-making system. Give me a latency budget per stage and defend the total.”

Expected shape: ingest (kernel vs bypass choice, justified for the deployment context) → decode (binary fixed-layout vs JSON, per venue) → book update → signal/strategy → risk checks (in-process tables) → encode + TX. Numbers per stage with the two honest totals: colo-class (~1µs software) and your crypto-class reality (host µs + venue RTT ms, and why the RTT dominates placement decisions). Must include: where the two wire timestamps live, threading model (single pinned hot thread vs pipeline, and the handoff cost either way), what’s precomputed off-path, and the burst story — what degrades at 10x message rate.

Rubric (20): stages complete and ordered, nothing hand-waved (4); numbers plausible at each stage and self-consistent with the total (4); measurement honesty — timestamps, percentiles-not-averages, coordinated-omission awareness if a harness comes up (4); burst/degradation story unprompted (3); context-appropriate technology choices with the “when NOT” cases — e.g. DPDK wrong for internet venues (3); crisp close: restates budget, names the dominant term, says what you’d optimize first (2).

Drill 2 — Market-data fan-in for 20 venues with gap recovery (40 min)

Prompt: “Twenty venues, mixed protocols — binary multicast, FIX, WebSocket JSON. Design the market-data subsystem that feeds one strategy tier: normalization, gap handling, and how consumers learn they can’t trust the book.”

Expected shape: per-venue feed handler as isolation boundary (venue protocol never escapes it) → normalized internal schema, versioned per ch14 → sequence numbers end-to-end → per-venue book builder with explicit validity state machine (LIVE / GAPPED / RESYNCING, exposed to every consumer) → recovery ladder: A/B arbitration, retransmit channel, snapshot+buffered-delta splice (with the bounded-buffer overflow answer) → internal distribution (single writer per stream, no consumer backpressure onto the feed path, conflation only for the slow tier) → resource tiering: hot venues get pinned cores, the long tail shares an epoll thread. This is your home turf — the rubric penalizes not using your 20-venue war stories.

Rubric (20): normalize-layer isolation stated as a design principle, not an accident (4); gap detection AND full recovery ladder including the splice mechanics (4); validity/poisoned-book contract with consumers — the “crossed book” answer (3); no-backpressure internal distribution design (3); heterogeneity handled — per-venue quirks table, hot/cold resourcing, staleness deadlines (3); at least two concrete venue anecdotes deployed naturally as evidence (3).

Drill 3 — Your matching engine + a zero-downtime deploy story (45 min)

Prompt: “Walk me through the matching engine you built. Now ship a new version of it at 3pm with markets open — take me from CI to full size, including what goes wrong.”

Expected shape:

• Part one (~15 min): your real engine — event-sourced core, determinism contract with the forbidden-inputs list, snapshot mechanics, hot standby as log consumer, one real failover story with numbers.
• Part two (~25 min): the ch16 runbook, phase by phase — replay-regression gate with classified diffs; N-1 read-back check; follower start (snapshot + tail + live, outputs sinked); rolling hash comparison; LeadershipTransfer cutover with epoch fencing; venue session takeover (FIX seqnums vs crypto re-auth burst — both); open-order reconciliation as a hard gate; bake with the write-format flip deferred; and the rehearsed rollback branch.
• Part three (~5 min): interviewer injects “hashes diverge at T-5 minutes” — you abort, disqualify, bisect offline, and say why cutting over anyway is never the answer.

Rubric (20): engine description is concrete and yours — real numbers, real failover story (4); determinism contract stated precisely and connected to why the deploy works (3); full runbook with mechanical pre-committed gates (4); session takeover handled for both FIX and WS worlds (3); rollback discipline — N-1 compatibility, write-flip-after-bake, kill-switch-before-decision (3); handles the injected divergence calmly with the correct call (3).

Drill 4 — Diagnose-the-regression roleplay (30 min, needs a partner or self-script)

Prompt (interviewer script — have a friend read it, or record yourself playing both sides): “Since Tuesday, p99.9 tick-to-trade on venue X doubled. p50 is flat. Nothing obvious changed. You have full access. Go — and I’ll answer questions as the system.”

Hidden cause (self-run version — pick one at random after writing three cards): (a) a deploy Tuesday added logging on an error path that fires under burst; (b) IRQ affinity reset by a driver update, feed lands on the wrong core; (c) venue X changed snapshot depth, tripling decode work in bursts.

Expected behavior — the method is the answer: verify the measurement first (where are the timestamps, sample counts at p99.9, conditional-on-load view); bracket in time and correlate with change records (deploys, config, host, venue notices); split code from environment with the replay trick — same day’s log through Tuesday’s and Monday’s builds, deterministic input isolates the binary; then bisect the path with per-stage histograms; state a hypothesis before each measurement and say what result would falsify it. Interviewers grade the loop — hypothesis, cheapest discriminating measurement, update — not the lucky guess.

Rubric (20): interrogates the measurement before the system (4); explicit hypothesis list, ranked by prior and cost-to-test (4); uses replay/determinism as an isolation tool unprompted (4); each step names the expected evidence and what would falsify it (3); reaches the planted cause — or a correctly-reasoned dead-end with a next step — inside 25 minutes (3); closes with prevention: the regression becomes a CI replay gate (2).

Drill 5 — Explain kernel bypass to a PM (30 min: 10 prep, 5 delivery, repeat twice)

Prompt: “Our PM asks: engineering wants three months to move feed handlers to kernel bypass. What is it, why does it matter, and should we do it? Five minutes, no jargon that survives without being unpacked, end with a recommendation.”

Target script shape (write yours, then say it in under 5): an analogy that carries the mechanism (mail sorted through the office mailroom vs a courier straight to your desk — the mailroom is fair and general-purpose, and slow because of it); the two numbers that matter (what we pay per message today, what bypass gets us, and — the number that dwarfs both — our venue RTT, which is 1000x either number if we’re internet-connected); what it costs (specialized NICs, losing standard tooling, one engineer’s quarter, new failure modes); the recommendation as a conditional (“for our colo tradfi legs, yes, staged, Onload first because it keeps the standard interface; for the crypto internet legs, no — the physics of distance makes it pointless, here’s the arithmetic”). What the drill trains: numbers translated into money and risk, jargon unpacked at first use, and a recommendation the PM can act on without trusting you blindly.

Rubric (20): analogy accurate enough that a technical listener wouldn’t wince (4); quantified trade-off including the “when it’s pointless” case (4); zero unexplained jargon — every term unpacked in one clause or cut (4); lands a concrete staged recommendation with a decision criterion (4); under five minutes, structured (signposted beginning/middle/end), spoken not read (4). Score the recording, not your memory of it.

Drill 6 — Full mock loop: the 14-day self-run schedule (planning drill, 45 min once; then execute)

The final drill is running yourself through a complete interview loop using the question banks (ch19–ch21) under realistic conditions: questions drawn cold, answered aloud, timed, scored against the model answers — never read-then-nod. Rules of engagement: 25 questions per qbank session is too many for one sitting — draw 8–10 randomly per session so ordering doesn’t become memorized rhythm; grade each answer 0/1/2 (missed it / got there with flab / crisp and complete) and re-queue everything below 2; any answer that runs past 90 seconds without a point being made gets a “so what?” interrupt from you-as-interviewer. Labs are re-typed from memory on day 12, not re-read — retrieval is the point.

The 14-day plan (60–90 min/day):

Interleaving is deliberate: reading and its matching drill are 2–6 days apart because retrieval after forgetting is what builds interview recall, and every qbank session mixes banks by day 14. If an interview lands mid-plan, days 6, 8, and 13 are the highest-yield subset — do those three.

Rubric for the loop itself (20): all 75 qbank questions attempted cold at least once (4); every sub-2 answer re-queued and cleared (4); drills 1–5 each run with scored rubric, 16+ achieved or repeated (5); lab re-typed from memory successfully on day 12 (3); recordings actually reviewed for drills 4–5 (2); weak-spot list written on day 14 and scheduled (2).

Interviewer will ask

This chapter’s version of the box is about the meta-round — how interviewers probe your preparation and self-assessment itself.

Q1: “How did you prepare for this interview?” Tell the truth with structure: identified my gaps against the role (DB operations, deployment of always-on stateful systems — my engine background is strong, my platform-ops vocabulary was thinner), built a study plan interleaving reading, a runnable lab, and timed spoken drills, and pressure-tested with question banks answered cold and scored. Naming a specific artifact — “I built a 250-line event-sourced book that live-upgrades v1→v2 with hash-verified cutover” — turns “I prepared” into evidence.

Q2: “What’s your biggest technical weakness for this role?” Pick a real one you’ve bounded and worked: “Production colo networking — multicast operations, kernel bypass — I know the theory cold and I’ve operated the crypto analog of every failure mode, but I haven’t carried the pager for a multicast outage. Here’s how I’d close it in the first month.” Never claim a strength dressed as a weakness; interviewers pattern-match that instantly.

Q3: “Tell me about a time you were wrong about a system.” Have one prepared from your real history — a determinism bug, a recon gap, a venue assumption that failed — told as: what I believed, what the evidence was, the moment I updated, what mechanism (not intention) now prevents it. The mechanism ending is what separates a growth story from an anecdote.

Q4: “Whiteboard question you’ve clearly seen before — do you say so?” Yes, one sentence — “I’ve worked through this class of design; want me to go fast and you push on the corners?” — then deliver at full quality. Interviewers usually know the banks; pretending to derive freshly what you’ve rehearsed reads as performance, while disclosure plus depth reads as preparation, which is the trait they’re hiring.

Q5: “You’ve talked a lot about your event log. What if we don’t use event sourcing here?” Show the transfer, not the attachment: the log is one implementation of properties I’d want anywhere — reproducibility of incidents, verifiable state transfer for deploys, an audit trail. If the shop uses checkpoint/restore or DB-backed state, I’d ask how they get those properties and adapt — and I can argue trade-offs of their approach against mine credibly precisely because I’ve operated one end of the spectrum.

Q6: “Any questions for us?” (It’s a drill too.) Prepare three that do work for you: one that shows operational depth (“what does your deploy-to-full-size timeline look like for engine changes, and what gates it?”), one about failure culture (“walk me through your last significant incident’s post-mortem — what changed after?”), and one calibration question (“what does the strongest engineer at this level here do that others don’t?”). Their answers also tell you whether the shop practices what this book preaches — which you now know how to evaluate.

Further reading

• The question banks (ch19–ch21) and labs of this book — the drills’ raw material; the drills are worthless without them.
• Gil Tene, “How NOT to Measure Latency” — re-watch before Drill 1 and Drill 4; the measurement-first instinct is the single highest-yield drill habit.
• Kleppmann, DDIA — skim chapter summaries (each chapter ends with one) the night before any loop; they’re the best-written 2-page refreshers in print.
• Aeron Cluster docs + Martin Fowler’s event-sourcing and blue-green articles — the citable anchors for Drill 3; naming real systems and real authors under pressure signals depth cheaply.
• Your own incident notes and venue-quirks table — the most further of further reading: every drill above improves more from one real story of yours than from any external source.