C++ Interview Questions at Low Latency Trading Firms

Low latency C++ interviews weight cache behavior, lock-free concurrency and banned constructs as heavily as algorithms, and this covers the recurring rounds.

C++ interview questions at low latency trading firms test whether a candidate understands what the hardware is doing underneath the language, not whether they can write syntactically correct code on a whiteboard. A typical loop covers cache behavior, the actual cost of a pointer chase, lock-free concurrency, and the specific language constructs a production hot path avoids on purpose. Firms including Jump Trading, Hudson River Trading, Optiver and IMC Trading weight these systems questions as heavily as anything algorithmic, because a candidate who reasons well about arrays but has never thought about a cache miss will write code that looks correct and runs an order of magnitude slower than…

Interviewers start with cache mechanics because it explains more about real trading code than any other single topic. A common opener asks a candidate to explain why iterating a contiguous array beats iterating a linked structure of the same logical size, and the expected answer names the actual numbers: an L1 cache hit costs around 1 nanosecond, an L2 hit costs around 4 nanoseconds, and a main memory access costs 80 to 100 nanoseconds, so a single pointer chase that misses cache costs more than a hundred ordinary arithmetic operations. The full mechanism, including struct layout and false sharing across a 64 byte cache line, is worked through in the piece on cache locality and trading code…

A second common question asks a candidate to reorder the fields in a struct to remove padding, or to explain why two threads writing to adjacent but unrelated variables can destroy each other's throughput through false sharing even though neither thread ever touches the other's data directly.

Once memory layout is covered, the conversation moves to concurrency, and it rarely stays on mutexes for long. A candidate is expected to explain why acquiring an operating system mutex on a hot path is dangerous, since the thread holding the lock can be descheduled by the kernel at an arbitrary point and every other thread waiting on that lock now stalls for however long the scheduler takes to give the holder its turn back. The expected alternative is a single-producer single-consumer ring buffer built on atomics, a topic covered in full in the piece on lock-free data structures in trading systems, along with the memory ordering semantics that make a compare and swap loop correct rather…

A recurring question asks a candidate to name what is disallowed in a hot path and to explain why. Exceptions are avoided because stack unwinding has unpredictable, sometimes large latency and because the exception tables bloat the binary and hurt instruction cache behavior even on the path that never throws. Dynamic allocation through new or malloc is avoided because a general purpose allocator can take a lock internally, touch a page that is not resident, or fragment the heap over a long-running process, any of which introduces a latency spike that a market maker cannot absorb during a live quote update.