C++ quant developer interviews: systems, low latency and the coding rounds

A quant developer loop at a trading firm looks like a software engineering loop from the outside: a coding screen, then a few technical rounds. Inside, the questions run deeper. Interviewers ask how your container grows, what your move constructor promises, why a socket option exists and what a piece of code you have never seen actually does. This guide covers C++ and systems interviews at trading firms: what firms say they test, what candidates report being asked, and how to prepare. Every claim about a firm or a candidate is labeled as official (firm pages and job postings), reported (press), or self-reported (forums and candidate write-ups), with its date; C++ language rules cite the cppreference documentation.

Last reviewed 2026-10-28. Interview content changes by firm, team, office and year, and self-reported accounts are single data points. Use them as a map of what can come up.

Which quant developer are you interviewing for?

"Quant developer" covers several jobs, and the preparation differs. This split is our own reading of job ads and firm guidance; titles and boundaries vary by firm.

This guide is written mostly for the first and third rows. If you are aiming at a research or pricing seat, the C++ sections still apply; the low-latency ones matter less.

The job ads show the bar for C++ roles:

On pay, our comparison of trader, researcher and developer pay shows that posted bases for the three roles are often identical at the top firms.

What the firms say they test

Four firms have published unusually direct guidance for engineering candidates (DRW's is written for university applicants).

Hudson River Trading. In an October 2025 post on engineering and interviewing at HRT, HRT's Joe Smith wrote that candidates choose C++, Python, or TypeScript/Python for full-stack roles, and that the firm tries to "stray away from 'burst of insight' leet-code style questions." Onsites are "generally composed of coding and debugging rounds, technical design discussions, and team fit," and HRT gives "the same technical tests to candidates at all levels." The post names a shallow understanding of fundamentals as the most common reason candidates fail, and gives two examples of the depth expected: whether you know how most compilers implement virtual classes, and the memory growth characteristic of a Python list as it expands. (Official: HRT, October 2025.)

Optiver. Optiver's interview tips for software engineers say the firm uses technical discussions "instead of relying on standard Leetcode puzzles or brainteasers." Candidates need confident knowledge of C++, Java or Python, the space and time complexity of standard data structures, and may be asked "how data is represented in memory and how operations work under the hood." The page also tells candidates to revisit computer architecture, networking, concurrency and memory management, and to expect "Why did you make this design decision?" (Official: Optiver, March 2025.)

Jane Street. Its software engineering interview guide says you can use any language, that interviewers expect real code in a real programming language with pseudocode ruled out, and that you should be comfortable with basic data structures and APIs in that language. One of its four suggestions is simply "Know your language." It avoids "algorithm bingo" and does not ask software engineers to do mental math or logic puzzles. (Official: Jane Street, accessed 2026.)

DRW. DRW's technical challenge page, part of its university recruiting material, says software developer applicants take a coding assessment on Codility, with questions at varying difficulty that "assess both correctness and performance of your code." (Official: DRW, accessed 2026.)

The common thread: the firms describe practical problems and depth in one language, and play down puzzle-style algorithm drills. Practical problems can still be hard, and some candidates report LeetCode-hard questions at other firms, so algorithm practice remains part of the preparation.

The C++ round: containers, ownership and moves

Candidate reports show what "know your language" means in C++. In a Blind thread from January 2022 collecting C++ questions asked at mid-senior and senior level across industries, commenters listed implementing a shared pointer, the copy-and-swap idiom, move versus copy semantics, the rule of five, RAII, placement new, the cast operators, an unordered_map and a thread pool. (Self-reported, Blind, January 2022.) A 2026 candidate write-up of a Squarepoint risk technology engineer process describes implementing an ordered vector with an interface consistent with std::vector, including emplace_back and move semantics; a later round asked why weak_ptr exists and how shared_ptr works internally. (Self-reported, PracHub candidate write-up, August 2026.) eFinancialCareers quoted an engineer from Chicago Trading Company as saying that most firms focus on STL utility, "deep dive questions on templates" and modern C++, and differ in "how idiomatic you are with C++." (Reported: eFinancialCareers, February 2024.)

A warm-up in the style of these rounds. What happens to ptr here?

std::vector<std::string> values;
values.reserve(2);
values.push_back("A");
values.push_back("B");
auto* ptr = &values[0];
values.push_back("C");

It depends on capacity(). reserve(2) only guarantees a capacity of at least 2. If capacity() is 2 after the first two insertions, the third push_back forces a reallocation, invalidating all pointers, references and iterators into the vector: reading through ptr is undefined behavior. If the implementation reserved more, nothing is invalidated, because push_back only reallocates when the new size exceeds the old capacity. To avoid reallocation during a known sequence of insertions, reserve enough capacity beforehand; later reallocations, or operations such as erase, can still invalidate pointers and iterators. (Reference: cppreference, reserve and push_back, accessed 2026.) Two follow-ups an interviewer might add. If moving an element could throw, would the reallocation be safe? For std::string the question is moot, because its move constructor is noexcept. And with std::vector<std::unique_ptr>, a pointer to an element (the unique_ptr) is invalidated by the same reallocation, while a raw pointer to the managed T stays valid, because the T objects never move. Try the reverse case, where capacity is already reserved, in the free problem Vector Growth and Iterator Invalidation.

Why container questions are really exception-safety questions. A vector rewrite exposes whether you know what the real one guarantees. Per cppreference, std::vector::push_back has no effect if an exception is thrown (the strong exception guarantee), and that guarantee is waived if the element's move constructor is not noexcept and the element cannot be copied. During reallocation, an implementation can use std::move_if_noexcept, which returns an rvalue reference when moving cannot throw or copying is unavailable, and a const lvalue reference otherwise. That reference type selects the move or the copy constructor, so the vector copies when a throwing move would break the strong guarantee. (Reference: cppreference, accessed 2026.) If you write one, be ready to say why your move constructor should be marked noexcept and what state your container is in if constructing a new element throws halfway. Practice: Vector Reallocation and the Missing noexcept.

Why shared_ptr questions are really allocation and threading questions. cppreference describes a typical shared_ptr as two pointers, one to the object and one to a dynamically allocated control block holding the deleter, the allocator and two counts (owning shared_ptrs and weak_ptrs). Different shared_ptr objects that share ownership can be copied from multiple threads without extra synchronization, but unsynchronized non-const access to the same shared_ptr object is a data race. That safety covers the control block only: the pointed-to object needs its own synchronization if threads modify it. std::make_shared typically allocates the control block and the object together (the standard recommends a single allocation without requiring it). That saves an allocation, but while any weak_ptr remains, the combined block, including the space the object occupied, can stay allocated after the object's destructor has run. (Reference: cppreference, accessed 2026.) Practice both: Hot-Swapping a Config Behind a shared_ptr and make_shared, weak_ptr, and a 64 MiB Snapshot. Our C++ & Systems course covers object lifetime, moves and memory management in order.

Low-latency and systems questions

Experienced loops add the machine underneath the code. HRT's C++ posting describes using "deep knowledge of C++, OS internals, CPU architecture, and networking hardware and protocols." (Official: HRT, November 2025.) Candidate reports match:

• Linux and networking. The Squarepoint write-up describes rounds on TCP congestion control, Linux process scheduling, kernel bypass and shared memory, how TCP_NODELAY and Nagle's algorithm work, and DPDK versus OpenOnload. (Self-reported, PracHub candidate write-up, August 2026.)
• Lock-free code. eFinancialCareers reported from Blind posts that lock-free programming "appears a common trend" in HFT interviews, and that one engineer at Headlands "was asked to implement a lock-free SPSC queue in C++." (Reported: eFinancialCareers, February 2024.)
• Operating systems. A 2023 Blind poster preparing for prop shop and hedge fund engineering roles wrote that interviews at HRT and D.E. Shaw "grilled" them on operating systems and the JVM. (Self-reported, Blind, January 2023.)

Not every candidate needs all of it. This split of fundamentals and role-dependent topics is our reading:

You do not need to memorize every processor latency or networking parameter. Understand the mechanisms, know their rough performance cost, and be able to explain how they change a design. Why can false sharing hurt scalability? When does a contiguous data layout make better use of the cache? What do you trade between spinning and blocking? Three problems to test yourself: False Sharing in a Parallel Counter and A Lock-Free Stack Under Preemption, both free, and Mutex or Spinlock on the Hot Path?.

For background, Carl Cook's CppCon 2017 talk on high-performance trading systems frames the core problem: the critical path is a small fraction of the codebase, runs "infrequently and unpredictably," and must still be fast, while compilers, operating systems and standard hardware are tuned for throughput and fairness. (Reported: isocpp.org, September 2018.) For how the trading horizon shapes the skills firms screen for, see our HFT, mid-frequency and low-frequency comparison.

The coding rounds: practical builds over puzzles

When candidates describe the coding itself, the problems tend to look like small pieces of a trading system:

• Order books and matching engines. In a 2024 Blind thread about Optiver's software engineer online assessment, a commenter said theirs was to implement an order matching system for a stock exchange with first-in, first-out matching. (Self-reported, Blind, May 2024.)
• Parsers with tests. The Squarepoint write-up describes coding questions that "were not LeetCode-style algorithms," such as a polynomial parser that had to pass the interviewer's unit tests while handling negative numbers and overflow. (Self-reported, PracHub candidate write-up, August 2026.)
• Custom tasks. At a ProfitView webinar reported by eFinancialCareers in March 2023, Mike Tsantekidis, a quant developer at HFT firm Portofino Technologies, showed an adapted LeetCode problem but said that "during a real interview, we would use custom tasks." (Reported: eFinancialCareers, March 2023.)
• Performance counts. DRW's Codility challenge for university applicants scores performance as well as correctness (Official, accessed 2026), so a brute-force solution that passes small cases can still lose points.

Not every firm leans this way. A 2024 Blind commenter on a Citadel Securities C++ engineer process said it was team dependent but to "expect LC hard." (Self-reported, Blind, July 2024.) A commenter on a 2024 Blind question about developer interviews at SIG wrote that "our interviews put a big emphasis on the basics," and that if you pick a data structure "you should know how it works." (Self-reported, Blind, August 2024.)

To test yourself under interview conditions, run the timed quant developer assessment simulator.

Reading code you did not write

HRT says candidates "may be given problems that require you to analyze code in an unfamiliar language," and that grading takes language familiarity into account. (Official: HRT, October 2025.) Its graduate posting lists, as part of the profile, that you "can look at code, figure out how it works, and identify how to make it better." (Official: HRT, July 2026.) Debugging is a named round type in HRT's onsite, and the Squarepoint write-up describes a section where the interviewer showed several code snippets and asked the candidate to find and fix potential bugs. (Self-reported, August 2026.)

To practice, read unfamiliar open-source code in a language you rarely use and explain out loud what each function does before running it. For C++ specifically, practice predicting the output of short programs that turn on object lifetime, virtual dispatch during construction, implicit conversions and undefined behavior.

A preparation plan

1. Go deep in the language your target role requires. Some firms let you choose your interview language, while dedicated C++ roles assess C++ itself. For C++, prepare object layout and vtables, value categories and moves, the standard containers' complexity and invalidation rules, smart pointers, templates, and the memory model. Our C++ & Systems course covers this ground.
2. Rebuild the standard pieces. Write a vector with correct copy, move and growth behavior and a noexcept move constructor, a unique_ptr and a shared_ptr with a control block, a ring buffer and an LRU cache. For each one, state the exception guarantee each operation gives.
3. Build one trading-shaped system. A limit order book with price-time matching, with tests, covers a practical problem several candidates report and gives you something concrete to discuss in design rounds.
4. Learn the machine. Start with the fundamentals column above, then the advanced topics your target role lists. Be ready to connect each one to a decision in your own code.
5. Practice under time. Timed coding and multiple-choice drills in the practice problems, then a full run of the quant developer assessment simulator. The quant developer prep page puts the course, practice and simulator in one plan.
6. Read firm-specific notes. Our guides to HRT, Optiver, DRW, Jane Street and SIG collect what each firm says about its process, with sources.

A note on AI tools

HRT's post says some candidates try to cheat early stages "by using LLMs and the like" and that the firm does "not welcome cheating candidates to interview again at a later time." Its current job postings state that use of AI tools during interviews or assessments "is strictly prohibited, unless otherwise instructed or agreed upon." (Official: HRT, October 2025 and 2026.) Policies differ by firm and stage, and some ads list practical use of AI coding tools as a skill for the job itself, as DRW's algo engineering posting does. (Official: DRW, June 2026.) If the rules for an assessment are unclear, ask the recruiter before you start.

QuantReady is an independent prep platform and is not affiliated with, endorsed by, or sponsored by any firm named here. All trademarks belong to their respective owners. Interview processes change, and candidate reports describe individual experiences. If something here is out of date or wrong, tell us via /contact.

QuantReady is an independent prep platform and is not affiliated with, endorsed by, or sponsored by any firm we write about. All company names and trademarks belong to their respective owners. Read how we source our content.