Quantitative Developer Interview Prep: Questions and a Mock Test

Coding rounds here look like ordinary algorithm interviews with one difference: the follow-up is always about constant factors and memory behaviour, not only about asymptotic complexity.

Asymptotics still come first, and the costs of language built-ins are part of that. Python's documented average cases make the point compactly: appending to a list is O(1) while inserting at position zero is O(n), indexing is O(1) while membership testing with x in list is O(n), and set membership and dictionary access are O(1). A seen-before check written against a list rather than a set turns a linear algorithm into a quadratic one with almost no visible change to the code.

What is added in this domain is the layout question. A structure with the same complexity can be an order of magnitude apart in practice because of memory access patterns. An array of contiguous values is scanned far faster than a linked structure of the same length, because the hardware prefetches sequential memory and every pointer chase is a potential cache miss. That is why a flat vector frequently outperforms a linked list even for operations the linked list is supposedly better at, and why a linear scan of a small contiguous array can beat a hash lookup.

For an order book specifically, the interview conversation is about the access pattern rather than the ideal abstraction: prices near the top of the book are touched constantly, prices far away almost never, and updates are overwhelmingly at or near the touch. A design that optimises the common case and accepts a slower path for the rare one is the expected answer.

Concurrency questions dominate the systems rounds because the bugs are hard to find and expensive when they escape.

The basics are examined precisely. A race condition is two threads accessing shared state with at least one writing, without synchronisation ordering them. A deadlock requires a cycle of threads each holding a lock another needs, and the standard prevention is a consistent global lock ordering. Livelock is threads actively responding to each other without progressing. Starvation is a thread never getting scheduled or never acquiring a contended lock.

The distinction interviewers probe most is atomicity versus visibility. Making an operation atomic ensures it happens indivisibly; ensuring visibility means another thread will actually observe the result rather than a cached older value. A variable can be updated atomically and still be read stale by another core, which is what memory ordering and barriers exist to control, and it is why a naive check of a flag in a loop can spin forever.

Lock-free structures come up constantly, and the honest framing scores better than enthusiasm. Lock-free means progress is guaranteed for at least one thread and no thread can block others by being descheduled while holding a lock, which removes the worst latency tail. It does not mean faster in the average case, it is far harder to get right, and the ABA problem, where a value is changed and changed back so a compare-and-swap succeeds when it should not, is the classic trap.

The single-writer principle is worth naming: much of the fastest financial software avoids the problem entirely by giving one thread ownership of a piece of state.

Performance rounds test whether you reason about the machine and whether you measure before optimising.

The mental model expected is a rough hierarchy of costs: a register access is essentially free, an L1 cache hit costs a few cycles, an L2 hit more, main memory is a large multiple of that, and anything crossing the network is in a completely different regime. You are not expected to recite exact figures, and quoting them confidently to two significant figures is worse than describing the shape, but you are expected to know that the gaps are orders of magnitude and that memory access dominates most real workloads.

The consequences are practical. False sharing occurs when two threads write to different variables that happen to occupy the same cache line, so the line ping-pongs between cores and performance collapses without any logical contention; padding the variables apart fixes it. Branch misprediction costs a pipeline flush, which is why branchless formulations sometimes win. Allocation in a hot path is usually the first thing to remove, since it can trigger unpredictable pauses.

On measurement, the discipline being assessed is not to report an average. Latency distributions in this domain are heavily skewed and the tail is the point: p99 and p99.9 are what a trading system lives or dies by, and a mean hides exactly the events that matter. Measure on the target hardware, with realistic input, with the system warm, and be aware that the measurement apparatus itself perturbs what it measures. A candidate who says they would profile before optimising, and names what they would look at, outscores one who lists optimisations.

This is the topic most reliably separating candidates who have worked with financial data from those who have not.

The underlying fact is documented plainly in Python's own tutorial: "no matter how many base 2 digits you're willing to use, the decimal value 0.1 cannot be represented exactly as a base 2 fraction. In base 2, 1/10 is the infinitely repeating fraction 0.0001100110011001100110011001100110011001100110011...". The visible consequence follows: summing three values of 0.1 does not equal 0.3, and the documentation shows exactly that, with 0.1 + 0.1 + 0.1 == 0.3 evaluating to False.

Three practical rules follow. Never compare floats with equality; the documentation points at math.isclose for "comparing inexact values". Never store money as a binary float; use an integer number of minor units, or a decimal type with defined rounding. And be aware that error accumulates over long summations, which is why the standard library's sum "uses extended precision for intermediate rounding steps as values are added onto a running total", and why compensated summation exists.

Ordering matters too: adding a very small number to a very large one can lose the small number entirely, so summing from smallest to largest is more accurate than the reverse. Subtracting two nearly equal numbers loses precision catastrophically, which is why numerically stable formulations of variance and of quadratic roots are written differently from the textbook version.

Expect a question about rounding a price to a tick, and remember that naive rounding of a value already carrying representation error produces off-by-one-tick bugs that are extremely hard to trace.

You are not being interviewed as a trader, but you are expected to understand the domain well enough to spot a specification that cannot be right.

Order semantics are the foundation, and the SEC's own definitions are exact. A market order "guarantees that the order will be executed, but does not guarantee the execution price", with the explicit warning that "the last-traded price is not necessarily the price at which a market order will be executed". A limit order is "an order to buy or sell a security at a specific price or better". A stop order becomes a market order once the stop price is reached, inheriting the price uncertainty precisely when prices are moving fastest.

That asymmetry drives real implementation decisions: a system that treats a fill price as known in advance is wrong, and one that assumes a limit order will fill is equally wrong.

Market data handling is the other half. Feeds are sequenced, and gap detection plus recovery is a correctness requirement rather than a nicety, because a silently dropped message leaves your book wrong in a way that produces confident bad decisions. Snapshot plus incremental update is the standard construction, and the interview question is usually how you resynchronise after a gap without stopping.

The vocabulary to have ready: the top of book, the spread as the immediate cost of a round trip, and the difference between a trade print and a quote update. And be able to say what your system should do when it does not know the state of an order, since the answer, treating the outcome as unknown and reconciling rather than assuming, is the same idempotency reasoning that applies everywhere else.