How C++ interviews for quant developers work
At trading firms the C++ deep dive is a 45 to 60 minute conversation about what code costs on real hardware: object lifetime and copies, move semantics, templates against virtual calls, undefined behavior, memory ordering and cache effects. Often you read a snippet and say what it really does. The guides we read agree that reciting a rule is only the baseline; the signal is saying what a construct costs and how you would measure it.
Key points
- For every claim about speed, be ready for “how would you measure that?”. A number and a way to check it beat a rule of thumb.
- Know exactly when objects are constructed, copied, moved and destroyed. Hidden copies and allocations are the classic snippet question.
- Pick the weakest memory ordering that is correct and say what breaks if it is weakened. The strongest ordering “to be safe” is a reported failure.
- Spot undefined behavior and explain what the compiler is allowed to assume, not only that the code is wrong.
- Think in cache lines as well as big-O: false sharing and pointer chasing are where the time goes.
Where the C++ round sits in the loop
Prep guides describe a quant developer loop that is mostly C++ and systems. The C++ deep dive is one round; concurrency and low-latency design are often separate rounds that go further on the same ground.
| Round | Typical time | What happens |
|---|---|---|
| Online assessment | 60 to 120 min | Two to four problems with hidden tests; a correct but slow solution usually fails. |
| Live coding | 45 to 60 min | Often in C++: containers chosen for their cost, clean code that compiles, then optimization and harder follow-ups. |
| C++ deep dive | 45 to 60 min | Questions and snippets: hidden copies and allocations, move semantics, templates, the object model and the memory model. |
| Concurrency | 45 to 60 min | Atomics and memory ordering, often built up to a single-producer single-consumer queue that you then defend. |
| Low-latency design | 45 to 70 min | Trace market data to a trading decision; design an order book, a matching engine or a feed handler. |
| Code reading | About 45 min | Find undefined behavior and hidden cost in someone else’s code, or reason back from a latency spike. |
What interviewers look for
No firm publishes its rubric. The guides describe the same signals:
- Cost awareness: every container, copy and allocation has a reason, and big-O is not the end of the performance talk.
- Measurement: a number and a way to get it, profiling before optimizing, and tail latency rather than the average.
- Object lifetime: when constructors, copies, moves and destructors run, and why a move constructor should not throw.
- Memory model: the weakest correct ordering for each operation and what a barrier prevents. Code that passes on one processor is not proof.
- Hardware: cache lines, false sharing, branch prediction and the cost of indirection.
- Undefined behavior: spotting it in a snippet and explaining what the compiler may legally do with it.
- Composure: the same snippet gets harder questions until you reach the edge of what you know.
The topics that come up most
- Object lifetime and ownership: RAII, the rules of zero, three and five, and what each smart pointer costs.
- Value categories and move semantics: what std::move really does, perfect forwarding, copy elision on return.
- Templates against virtual functions: compile-time against run-time polymorphism, and the trade between call cost and code size.
- Undefined behavior: signed overflow, dangling references, data races, aliasing violations.
- Containers and allocation: the right container for the access pattern, iterator invalidation, pools and arenas.
- Concurrency: atomics and memory orderings, false sharing, lock-free queues, and when a lock is simply better.
The mistakes guides report most
- Treating everyday C++ fluency as enough and underestimating the depth of the round.
- Reciting a rule with no cost and no way to measure it.
- Using the strongest memory ordering everywhere to be safe, without knowing what a barrier prevents.
- Optimizing without profiling, or optimizing the rare path instead of the frequent one.
- Missing the classic surprises: std::move on a returned local can block copy elision, and a growing vector invalidates its iterators.
- Ignoring failure paths, such as a gap in the market data feed.
How the interviewer behaves
Expect one artifact to grow. A queue becomes lock-free, then gets non-trivial element types, batching and cache-line padding; a snippet gets one more hidden cost each time you find the last one. After any performance claim, the usual follow-up is how you would measure it.
One guide reports that the round can end early when a core concept such as memory ordering is missing, which is why the guides spend more time on the memory model and object lifetime than on syntax.
How the bar changes with level
Sources on levels are thin for this round; treat the table as a tendency, not a rule.
| New graduate to mid-level | Senior and above | |
|---|---|---|
| Emphasis | C++ fundamentals, data structures and a correct, cost-aware baseline | C++ internals, deeper concurrency and systems you ran in production |
| Templates | Reads and uses them | Talks comfortably about constraints and compile-time techniques |
| Performance | Knows to measure | Diagnoses latency spikes and leaks, and explains the trade-off behind each fix |
| Follow-ups | Correct answers with reasons | The same question pushed further, until the trade-offs run out |
Modern C++ and other languages
One guide reports that trading-system code is mostly on C++17 or C++20, and that std::optional, std::variant, concepts and std::span are the modern features interviewers reach for most. Knowing where each one fits matters more than writing coroutines from memory.
The same guide notes that many firms accept your strongest language for general coding rounds and that C++ depth matters most for trading-system roles.
Go deeper on this round
Practise the round out loud
Mockich’s C++ deep dive is the quant track’s fundamentals round: 35 min, six questions at regular and five at lead on data layout, move semantics, undefined behavior, templates, memory ordering and the systems around a trading engine, asked out loud with no code to read. Vera probes each answer once or twice for depth and gives at most one small hint. The report scores accuracy, depth, practical judgment, communication (plus breadth and connection at lead) and quotes what you said.
Sources
We read these public guides on 2026-10-30 (source 6 on 2026-11-02) and summarised where they agree, in our own words. Sources 1, 3 and 6 come from one publisher and count as one voice. They report typical practice; no firm publishes its rubric, and firm-specific claims in them are not verified.
- [1] techinterview.org, The quant developer interview loop, round by round
- [2] TraderMath, The Quant Developer Interview Guide
- [3] techinterview.org, The lock-free queue question every HFT interview comes back to
- [4] quantt.co.uk, Quant developer interview questions
- [5] Aced, Quant Developer Interview Questions and Prep (2026 Guide)
- [6] techinterview.org, C++ for Quants: What HFT and Low-Latency Firms Test in C++ Interviews