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.