Courses · Quant developer HFT
Quant developer HFT course
The round that follows the algorithms. An interviewer at a trading firm puts twenty lines of C++ on the screen and asks why it is slow, what happens when two threads touch it, and how you would know. This course teaches you to answer from the source code down to the cache line.
- 10 modules
- 65 lessons
- 10 interview drills
- 245 check questions
- 253 model answers
The questions in brief: low-latency C++ interview questions, and what a good answer sounds like.
Course outline
Every lesson and drill is open to read in full.
Read hot code the way the interviewer does
The cost model behind every answer in this course: what one iteration of a loop makes the machine do, beyond what Big-O counts.
- What Big-O leaves out
- Vector and list: where the data actually sits
- Cache lines, locality and pointer chasing
- Allocation on the hot path
- Copies, moves and object layout
- Branches, indirect calls and inlining
- Virtual functions and vtables
- std::function, std::any and the cost of type erasure
- Benchmarking without fooling yourself
- The cost model, all at once
- Drill: reading hot codeDrill
Write C++ that stays correct under pressure
Object lifetime, ownership and the language features that fail quietly: dangling views, captured references, invalidated iterators, unsafe casts.
- When an object's life begins and ends
- RAII: tying every resource to an object
- unique_ptr, shared_ptr and weak_ptr
- Dangling views: string_view and span
- Move semantics without the mystery
- Lambdas and what they capture
- Iterator invalidation and stable handles
- Casts, aliasing and reading bytes safely
- Drill: lifetime and ownershipDrill
Choose the container, then control its memory
What each standard container does in memory, how vectors and hash maps grow, and the allocators, pools and small buffers that keep allocation off the hot path.
- Choosing a container by what it does in memory
- vector: size, capacity and growth
- Hash maps: buckets, load factor and rehashing
- map, list and deque: when nodes and blocks earn their place
- Allocators, pmr and object pools
- Small buffer optimisation
- Templates, CRTP and compile-time polymorphism
- Drill: containers and memoryDrill
Handle threads without fooling yourself
Data races, locks and their costs, the C++ memory model in the terms interviewers use, and the single-producer queue that sits between every pair of threads in a trading system.
Understand the machine under the code
Caches and how cores keep them coherent, false sharing, the out-of-order pipeline and its predictors, prefetching, and SIMD, each tied to the code that triggers it.
Keep the operating system out of the way
Virtual memory and the TLB, page faults, the scheduler, processes and shared memory, how malloc really works, and the isolation and scheduling settings trading systems run with.
Understand the network between you and the exchange
Sockets, TCP and UDP for trading, the shape of a market-data feed handler, packet loss and backpressure, where the kernel's network stack spends its time, and the hardware that removes it.
Measure latency honestly and find where it went
Percentiles and how latency is reported, profilers and what they miss, hardware counters, memory and lock bottlenecks, and how to tell the story of a performance investigation.
Speak the language of trading systems
The life of an order, the order book and how to build one, how exchanges match, the gateway and its risk checks, how market data reaches a strategy, and the C++ patterns that recur across all of them.
Get the numbers and the clocks right
How floating point behaves, why prices are integers, numerically stable statistics, and the clocks and timestamps every measurement and every regulator depends on.
What the systems round tests
Trading firms that hire software engineers for the trading path still ask algorithm questions, but the round that decides the offer is usually a different one. It is a conversation about a small piece of C++: a loop over market data, a queue between two threads, a class with a virtual function in it. The interviewer already knows the Big-O. They want to hear what one iteration costs on a real machine, and whether you can say it without guessing.
The questions are predictable once you have seen enough of them. Why is a vector faster than a
list when both are O(n)? What does std::function allocate? What does
memory_order_acquire actually promise? Why would you poll a network card instead of
waiting for an interrupt? How do you report latency, and why is the average the wrong number?
Each lesson takes one of these questions and builds the answer an experienced engineer would give.
How a lesson is built
Each lesson opens on something an interviewer actually asks, word for word as you would hear it.
What the compiler, the CPU, the kernel or the network card does, with the C++ that triggers it and a diagram of the machine.
Short questions with the reasoning behind every option, so a wrong pick teaches as much as a right one.
Model answers in the words you would use in the room: specific, measured, and without invented numbers.
Every module ends with a drill: four or five prompts in the order an interviewer would ask them, the answers that lose the point, and a strong answer to compare with your own.
Who it is for
Software engineers interviewing for developer roles at high-frequency trading firms, market makers and the engineering teams of hedge funds: titles such as software engineer, quant developer, low-latency developer or core developer. You should already be able to solve standard coding interview problems; if not, start with the coding interview course, which is part of the same subscription. You need to read C++, not to have written it for years. No finance background is assumed: the trading terms are introduced as they appear and gathered in Module 9.
Common questions
Which firms ask these questions?
Developer interviews at high-frequency trading firms and electronic market makers routinely include a systems round of this kind, and many hedge funds ask a version of it for engineers who work on execution. The format changes from firm to firm, from a whiteboard discussion to a take-home or a live debugging session, but the material is the same: C++ object lifetime, memory and caches, concurrency, the operating system, the network, and how latency is measured.
Do I need to know C++ well?
You need to be able to read it. The course explains every language feature it relies on, from RAII and move semantics to templates and type erasure, in the first three modules. Candidates who mostly write Java, Python or Rust use it to learn exactly the parts of C++ these interviews depend on.
Is this the same as the quant research interview?
No. Research and trading interviews test probability, statistics and market intuition; those are in the quant question banks. This course is for the engineering side.
Do I need an account?
No. Every lesson and drill is open in full, with its checks and model answers.
How long does the course take?
About 14 hours of reading, and longer if you work the checks and say the drill answers out loud, which is how it is meant to be used. Most candidates take two to four weeks alongside their algorithm practice.