TL;DR
Most strong software engineers are rejected by HFT firms for one of five reasons: they describe performance work without measurement, they optimise averages instead of tail latency, they show weak systems fundamentals beneath framework knowledge, they skip correctness and failure handling, or they cannot explain trade-offs when challenged.
None of these reflect a lack of talent. They reflect a different engineering culture, where predictability, measurement and correctness under live market conditions matter more than feature delivery speed.
Key points
- Bring numbers: budget, method, before and after, and percentiles.
- Talk about tail latency and jitter, not just average speed.
- Know what happens below your framework: memory, cache, syscalls, the network path.
- Correctness and recovery are part of the answer, not an afterthought.
Reason 1: performance claims without measurement
Candidates say they "made the service faster" without describing how they measured it. HFT interviewers immediately ask for the method, the tooling and the distribution of results.
Fix: prepare one story with the latency budget, how you measured it, what you changed, and the before-and-after numbers at the median and the tail.
Reason 2: optimising the average
Many engineers come from environments where average response time and throughput matter most. In trading, a system that is usually fast but occasionally slow can be worse than one that is consistently moderate.
Fix: learn to talk in percentiles, describe the sources of jitter such as allocation, garbage collection, scheduling and network queueing, and explain how you would reduce variance.
Reason 3: shallow systems fundamentals
Framework expertise does not transfer. Interviewers probe memory layout, cache behaviour, system calls, threading and the network stack.
Fix: revise CPU caches, memory allocation, false sharing, context switching and the path a packet takes into your application. Be able to sketch it.
Reason 4: ignoring correctness and failure handling
Candidates design for the happy path. In trading, a malformed message, a feed gap or a restart mid-session can create real losses.
Fix: in any design answer, cover sequence numbers, gap recovery, kill switches, restart behaviour and what you would monitor.
Reason 5: rigid answers under challenge
Interviewers push on every design choice to see how candidates reason. Repeating a rule, or defending a choice without weighing alternatives, reads as inflexibility.
Fix: state assumptions, offer the alternative, and explain the conditions under which you would change your mind.
Other common patterns
| Pattern | Why it fails | Better approach |
|---|---|---|
| Optimising before clarifying requirements | Signals process weakness | Ask about volumes, latency budget and consumers first |
| Over-engineering the design | Complexity harms latency and reliability | Start simple and justify each addition |
| Only algorithm-puzzle preparation | Misses systems depth | Practise design and measurement questions too |
| Weak knowledge of your own CV | Raises doubts about ownership | Re-read your projects and prepare specifics |
| Dismissing finance knowledge | Suggests low interest | Learn basic order book and market data concepts |
What interviewers are really testing
- Can you make something fast and keep it predictable?
- Do you measure, or do you guess?
- Will you break the trading day?
- Can you work with traders and researchers who depend on you?
- Will you learn market structure quickly?
A two-week preparation plan
| Days | Focus |
|---|---|
| 1 to 3 | Memory, caches, allocation, false sharing; write small benchmarks |
| 4 to 6 | Concurrency: lock-free queues, memory ordering, thread pinning |
| 7 to 9 | Networking: TCP and UDP, multicast, kernel bypass concepts, packet captures |
| 10 to 11 | Design practice: feed handler, order book, order gateway |
| 12 to 14 | Mock interviews, rehearse your measured-performance story |
Use the HFT C++ and system design interview guide for question-level detail.
Frequently asked questions
Are HFT interviews harder than big tech interviews?
They are different. They go deeper on systems, measurement and correctness, and less broad on general algorithm puzzles and behavioural rounds.
Do I need trading experience to pass?
No. Many firms hire engineers from networking, databases, embedded and games backgrounds, provided systems fundamentals and measurement discipline are strong.
How much C++ depth is expected?
Enough to reason about memory, allocation and performance implications of your choices. Language trivia matters less than judgement.
What is the single biggest differentiator?
Being able to talk precisely about latency you measured yourself, including how you measured it and what the distribution looked like.