TL;DR
HFT engineering interviews test four areas: modern C++ and its performance implications, memory and CPU behaviour, concurrency and networking, and the ability to design a trading component with a latency budget in mind. Most also include a practical coding exercise and a discussion of latency you have actually measured.
Strong candidates talk in numbers and percentiles, explain trade-offs rather than reciting rules, and show they understand why predictability matters more than average speed.
Key points
- Expect questions about allocations, cache behaviour and tail latency, not language trivia.
- Prepare one real performance story: the budget, the measurement, the change, the result.
- System design rounds usually cover an order book, feed handler or order gateway.
- Correctness comes first: a fast system that trades wrongly is worse than a slow one.
C++ language questions
Why avoid dynamic allocation on the hot path? Allocation can take variable time, may involve locks and can cause page faults, which creates jitter. Strong answers mention pre-allocated pools, arenas and reserving capacity upfront.
When is std::map a poor choice in trading code?
It is node-based, so elements are scattered in memory and lookups cause cache misses. Alternatives include sorted arrays, flat hash maps or direct indexing by price level.
What do move semantics change in performance-sensitive code? They avoid unnecessary copies, but in hot paths the better answer is usually to avoid ownership transfer entirely and reuse pre-allocated buffers.
How do virtual functions affect latency? They add indirection and can prevent inlining, which matters in the hottest code. Alternatives include templates, static dispatch and the curiously recurring template pattern.
What is false sharing? Two threads writing to different variables in the same cache line cause repeated cache line invalidation. The fix is padding or aligning data so hot variables sit in separate cache lines.
Memory, CPU and operating system
- How do CPU caches and prefetching influence the layout of your data structures?
- What does NUMA mean for a multi-socket trading server?
- Why do teams pin threads to cores and isolate CPUs?
- How do page faults and huge pages affect latency?
- How would you reduce jitter caused by the operating system scheduler?
Strong answers connect each idea to measured effects rather than repeating rules.
Concurrency
- Design a single-producer, single-consumer lock-free queue. What memory ordering do you need, and why?
- When is a spinlock better than a mutex, and when is it dangerous?
- How would you pass market data updates to several strategies without contention?
- What are the risks of using atomics without understanding memory ordering?
Networking and market data
- What is the difference between TCP and UDP for market data and order entry?
- How do you detect and recover from a gap in a multicast feed?
- What is kernel bypass, and what does it change?
- How do you timestamp packets accurately, and why does clock synchronisation matter?
Latency measurement
Expect detailed questions here, because it separates real experience from theory.
- How do you measure the latency of a code path without distorting it?
- Why report percentiles rather than averages?
- What is the difference between tick-to-trade latency and internal processing latency?
- How do you build a latency histogram in production without adding overhead?
Worked system design answer: an order book
Question: design an in-memory order book that updates from an exchange feed.
A strong answer covers:
- Requirements: which venue and protocol, update rate, depth needed, consumers of the data and the latency budget.
- Data layout: contiguous arrays for price levels near the top of the book, with an index for order IDs, chosen for cache efficiency rather than theoretical complexity.
- Hot path: no allocation, no locks, minimal branching; updates applied in place.
- Correctness: sequence number checks, gap detection, snapshot recovery, and handling of exchange-specific edge cases.
- Publishing: how strategies are notified, for example a lock-free ring buffer, and what happens if a consumer is slow.
- Measurement: timestamps at ingress and egress, percentile reporting, and tests that replay recorded feeds.
- Failure modes: what happens on a malformed packet, a stale feed or a restart mid-session.
Other common design questions include a feed handler, an order gateway with pre-trade risk checks, and a strategy runtime that hosts multiple strategies safely.
The practical coding exercise
Firms often ask for a small piece of performance-aware code, such as a ring buffer, a fixed-size hash map or a message parser. Priorities, in order: correctness, clarity, then performance. Write tests, state your assumptions, and mention what you would measure before optimising further.
Questions candidates should ask
- What is the latency budget for this component, and how is it measured?
- How do engineers and researchers work together here?
- What does the deployment and testing process look like during market hours?
- Which parts of the stack are in C++, and which are elsewhere?
Common mistakes
- Quoting rules without explaining trade-offs.
- Claiming performance improvements without numbers or method.
- Optimising in the interview before clarifying requirements.
- Ignoring correctness, recovery and failure handling.
Frequently asked questions
What C++ topics do HFT interviews focus on?
HFT C++ interviews concentrate on memory management and allocation strategy, cache behaviour and data layout, templates and static dispatch over virtual calls, move semantics, lock-free concurrency, and the performance cost of standard library choices. Expect to be asked what the compiler actually generates and to justify a design against a latency budget. Firms are testing whether you reason about the machine rather than whether you know the language specification.
Do HFT interviews include algorithm puzzles?
Many HFT interviews include algorithm questions, but they are rarely the deciding round. The emphasis sits on systems knowledge, measured performance work you have personally done, and the design of trading components such as a feed handler or an order book. A candidate who can describe a latency problem they diagnosed and the measurement that proved the fix will outperform one with a stronger competitive programming record.
How should I prepare for an HFT system design round?
Practise designing the three components that come up most: a market data feed handler, an order book, and an order gateway. For each, be ready to discuss the latency budget, where time is actually spent, how the component behaves under a burst, what happens on a gap or a disconnect, and how you would measure it in production. Interviewers care more about failure handling and measurement than about the happy path.
What if I have no trading experience?
Focus on measured performance work from your current domain, systems fundamentals and willingness to learn market structure. Many firms hire from networking, databases, embedded and games backgrounds.