If you prepped for a quant interview by drilling probability puzzles and eight-minute arithmetic, you prepped for the wrong job. That screen belongs to the trader track. The quant developer track hands you a compiler and asks what your code costs the machine. The two loops share a lobby and almost nothing else, and candidates who don’t notice the difference walk into a C++ memory-model question expecting a coin-flip brain teaser.
A quant developer builds and runs the software that trades: the market-data handlers, the strategy engines, the order gateways, the simulation and backtest infrastructure. At an HFT firm like Hudson River Trading or Jump, that software has to make a decision and fire an order in single-digit microseconds, so the interview is organized around one question asked six different ways: do you know what actually happens when your program runs? The day-to-day work of a quant developer versus a researcher or trader diverges hard, and so does the loop.
One scope note before the rounds. This maps the C++ and low-latency developer track, the one built around order gateways and microsecond hot paths. Functional-language shops like Jane Street, whose stack is OCaml, and the more research-adjacent developer roles run a materially different loop, so if that’s your target this map will mis-prep you. Coming the other way, from a standard software job, the first question is whether the transition itself makes sense, which the move from SWE to quant developer covers before you spend a month on C++ internals.
Why the loop looks nothing like the trader screen
The quant trading interview filters on expected-value speed: mental math, probability, market-making games. A developer loop barely touches those. Instead it front-loads a coding screen and then spends the onsite drilling into systems depth. Some firms mix a little probability into a fit conversation, and most won’t reject a developer for slow arithmetic, though a few still run a timed numerical-reasoning gate even in the dev funnel (Optiver is the one candidates flag most). The onsite rejects you for not knowing why a std::map lookup stalls the pipeline, or for writing a data race and not seeing it.
The rounds below are the common shape across Optiver, Citadel Securities, Hudson River Trading, Jump, DRW, IMC, Tower, and XTX. Not every firm runs all of them, and the order shifts, but the classes of questions are stable.
Round 1: the coding screen
Usually a timed CoderPad or HackerRank session, sometimes automated. The problems are LeetCode-medium in shape but the grading is not. Interviewers watch whether you reach for the right container and whether you can reason about its cost, which means the Big-O of the standard containers is table stakes, not trivia. A classic here is “implement an LRU cache” or “parse this feed and answer top-of-book queries” — problems that are really asking whether you understand hash maps, ordered maps, and the constant factors the textbook complexity hides. Write clean C++ that compiles, and narrate the container choice as you go.
Round 2: the C++ deep dive
This is where candidates most often report the loop turning at HRT, Citadel Securities, and Jump. It is not a language quiz. Worth flagging for anyone pivoting from a Java, Go, or Python job: writing LeetCode in C++ is not the C++ this round tests. Solving array problems with the standard library never forces you to think about object cost, the memory model, or where a copy hides, so a pivoter who feels fluent on the screen can badly underestimate this round. The interviewer hands you code and asks where the allocations and copies are, or asks you to explain move semantics, the object model, template instantiation, or the memory model well enough to reason about a specific latency problem. What HFT firms actually test in a C++ interview is whether you can see the machine underneath the syntax: cache lines, branch prediction, where a virtual call or an exception path costs you. Reciting that unique_ptr has no overhead is not the answer; explaining how you’d measure it is.
Round 3: concurrency
Trading systems are pipelines of threads passing messages, and the shared-memory hot path can’t afford a lock. So the concurrency round goes past “what is a mutex” into the memory model: std::atomic, acquire-release ordering, false sharing, and the reason a naive lock guards correctness at the cost of a latency spike you can’t tolerate. The canonical exercise is to build a lock-free single-producer single-consumer queue, then defend why it’s correct under a weak memory model. If you can’t articulate what a memory barrier prevents, this round ends early.
Round 4: where the microseconds go
A low-latency reasoning round, often opened with a deceptively simple prompt. Optiver and IMC both like some version of: a market-data packet lands on the NIC, walk me through everything before your strategy sees the price. The point is that the default answer, the kernel receive path, is the slow answer, and strong candidates know why HFT desks bypass the kernel for market data and can count the interrupts, context switches, and copies they’re removing. The same round can veer into hardware: some desks run their fast path on silicon, and what an FPGA interview at a low-latency firm probes is whether you understand the CPU-versus-gate tradeoff rather than whether you can write Verilog.
Round 5: the order book, or a matching engine
Nearly every developer loop reaches for it. In its small form it’s a data-structure problem: design an in-memory limit order book with fast add, cancel, and top-of-book, and the interviewer is watching whether you land on price-time priority and the right pair of containers because you thought about it, not because it’s the textbook answer. In its larger form it becomes a full matching-engine system design: sequencing, determinism, recovery, and how the book stays correct under load. State the two-line matching spec back before you touch a data structure; getting the rules wrong sinks everything after.
Round 6: reading and debugging code
Less advertised, common at Optiver and the market-makers. You’re shown a chunk of real-looking C++ and asked what’s wrong with it, or handed a system that behaves badly and asked to reason to the cause. It rewards the same skill as the C++ round from the other direction: seeing hidden cost and undefined behavior in code someone else wrote. Some desks that run their analytics or research stack on kdb+/q will fold a data-layer question in here too, though that leans more toward the research-adjacent developer roles.
How this differs from a normal SWE loop
A big-tech loop rewards breadth: distributed systems, API design, product sense. The quant developer loop rewards depth on one machine. Determinism matters more than scale, tail latency matters more than throughput, and “it’s fast enough” is never the answer; the interviewer wants the number and the method you’d use to get it. The behavioral round exists but carries less weight; nobody is running leadership-principle scripts. What they’re checking is whether you’ll obsess over a p99 the way the desk does.
| Round | What it tests | Where candidates report it weighs most |
|---|---|---|
| Coding screen | Container choice, clean C++, complexity awareness | All firms (gate) |
| C++ deep dive | Memory model, object cost, hidden allocations | HRT, Citadel Securities, Jump |
| Concurrency | Atomics, lock-free structures, false sharing | Optiver, Jump, HRT |
| Low-latency reasoning | Kernel bypass, cache, where microseconds go | Optiver, IMC, Citadel Securities |
| Order book / matching engine | Price-time priority, data structures, determinism | Nearly all developer loops |
| Code reading / debug | Spotting UB and cost in others’ code | Optiver, market-makers |
The through-line is that none of these rounds have a clever trick. They test whether you’ve spent real time with what the machine does under your code, which is exactly the job. The candidates who pass don’t recite the fast answer; they explain the tradeoff and how they’d measure it, and then they measure it. If you’re arriving from a standard CS or backend background, work the deep-dives in dependency order rather than at random: the C++ round first because every later round assumes it, then concurrency once the object model is solid, then low-latency reasoning on top of that, and the order book or matching engine last since it leans on all three. That sequence turns this map into a study plan. If you’re deciding which firms to target by how hard that bar sits, the quant firm interview difficulty index and the full set of quant firm interview guides break it down desk by desk.
