Build a market-data feed handler

Consume a sequenced message feed, normalise it, maintain live top-of-book, and survive the packets that arrive late, twice, or not at all. Domain-relevant, real engineering, and a conversation starter in every quant interview you take.

Learn

Sequence numbers and gap detection, normalisation across message formats, top-of-book maintenance, backpressure, and why throughput and latency are separate goals that trade against each other.

Ask an AI to teach you this

I'm preparing for a quant developer interview and I'm implementing: "Build a market-data feed handler"
What I'm building: Parse a sequenced feed into normalised events, track per-symbol top-of-book in a flat structure, detect gaps, buffer out-of-order messages, and expose a recovery path when the gap can't be filled.
Concepts I need to own: Sequence numbers and gap detection, normalisation across message formats, top-of-book maintenance, backpressure, and why throughput and latency are separate goals that trade against each other.

Run this as implementation coaching, not a lecture. One design decision at
a time. Wait for my code before moving on.

Per decision:
1. Frame it. State the decision in one line, then the options and what each
one costs. Assume I write C++ but have never had this explained properly.
No jargon without defining it.
2. "The 60-second version" — how a strong candidate would DEFEND that choice
out loud. First person, spoken register, no bullets, no headers. That's
what I'm rehearsing.
3. Tell me what to write, and ask me one question about the edge case I'm
most likely to get wrong.

When I show you code, reply in exactly this shape:

Verdict: correct / partly correct / wrong — one line on what's wrong.
What breaks: the input or sequence that breaks it. Only if something does.
Vocabulary: only if I used a wrong or vague term. Give the right one.
Example answer: how I'd defend this design out loud, 30 seconds, first person.
More info: define any term I probably don't know, one line each.
Follow-up probe: the one question an interviewer asks someone whose code
looks like that.

Skip any section that doesn't apply. Don't pad. If it's wrong, say wrong —
don't soften it.

Do not write my implementation for me. If I ask, refuse and ask what I'd
try instead — I need to defend this code with the editor closed.

Do

Parse a sequenced feed into normalised events, track per-symbol top-of-book in a flat structure, detect gaps, buffer out-of-order messages, and expose a recovery path when the gap can't be filled.

Check

You're done when all of these are true:

A dropped, duplicated, or reordered packet is detected and handled — not silently applied
The hot path does no allocation, and you can prove it rather than believe it
Benchmarked: messages/sec, and latency percentiles rather than just the mean
You can say what your handler does when it falls behind — and 'it wouldn't' is not an answer

Ship

Repo, a README explaining the data-structure choices, benchmarks, and a replay against a public or synthetic feed.

Practice with AI

Use these to make the AI your examiner, not your author. If the AI wrote the code, this node doesn't count — you can't defend a design you didn't make.

P3 — HFT-style code review, ends in hire/no-hire
P4 — live mock interviewer

Resources

Curated resources for this node are on the way. Use what you already know how to search for, and check back soon.