Quant Developer Interview Prep roadmap
Seqlock for a hot snapshot
Publish a small struct that one thread updates constantly and many threads read, without either side ever blocking the other. If you ship only one thing from this module, make it this.
Learn
atomic, acquire/release semantics, torn reads, why the reader retries instead of waiting, false sharing, cache-line padding.
Ask an AI to teach you this
I'm preparing for a quant developer interview and I'm implementing: "Seqlock for a hot snapshot" What I'm building: A seqlock guarding a multi-field struct: writer bumps an odd sequence, writes, bumps to even; reader loops until it sees a stable even sequence either side of its read. Concepts I need to own: atomic, acquire/release semantics, torn reads, why the reader retries instead of waiting, false sharing, cache-line padding. 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
A seqlock guarding a multi-field struct: writer bumps an odd sequence, writes, bumps to even; reader loops until it sees a stable even sequence either side of its read.
Check
You're done when all of these are true:
- Correct with memory_order_acquire/release, and you can justify each fence individually
- A reader never observes a half-updated struct — prove it with a stress test that would catch a torn read, not by inspection
- The sequence counter sits on its own cache line — and you can measure the difference, not just assert it
- You can say what this structure is bad at, and why an unlucky reader can starve
Ship
Repo plus a latency histogram for both reader and writer against a mutex-guarded equivalent.
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.
- P5 — explain the slowdown at the hardware level
- P6 — defend your design decisions with the code closed