Trading & Capital Markets
Low-Latency / Core Engineer
Where microseconds are the product. A specialist track with a genuinely different interview.
Where microseconds are the product. A specialist track with a genuinely different interview.
A day that is actually representative
| Time | What you are actually doing |
|---|---|
| 08:00 | Read yesterday's latency histogram. The mean is meaningless; you live at the 99.9th percentile. |
| 10:00 | Profiling. Cache misses, branch mispredictions, and a hot path that allocates once and should not. |
| 13:00 | A kernel-bypass stack question — Solarflare/Onload or DPDK, and whether the NIC or the switch is adding the jitter. |
| 15:00 | Working with hardware: FPGA offload for the parsing stage, and what genuinely belongs there versus what is fashion. |
| 17:00 | Measuring, with hardware timestamps, because software timestamps do not resolve what you are chasing. |
The decisive round
“Our tick-to-trade is 6 microseconds and a competitor is at 2.”
Interviewer: “Where do you look?”
A weak answer. “I'd profile the code to find hot spots, optimise the critical path, look at using kernel bypass if we aren't already, and consider moving parsing to FPGA.” A list of techniques with no measurement discipline. It also assumes the gap is in our software, which is frequently the smallest part of a four-microsecond difference.
A strong answer. “Before optimising anything I'd want to know whether the gap is even ours to close, because a four-microsecond difference is often not in the code at all.
First, measure properly. Hardware timestamps at the NIC, in and out, not software timestamps in the application — software clocks are the same order of magnitude as the thing we're measuring. And I want the full distribution, not the mean. A p50 of 6 µs with a p99.9 of 40 µs is a completely different problem from a flat 6, and the second is usually what costs money, because the market moves precisely when everything is busy.
Then decompose the path. Wire to NIC, NIC to userspace, parse, decide, encode, send, NIC to wire. Each has its own budget. In practice the distribution is usually surprising: parsing and encoding often dominate, and the strategy logic — the part everyone assumes is the problem — is a few hundred nanoseconds.
Then the non-code causes, which I'd check before touching the code. Are we in the same colocation hall as them, on the same cross-connect topology? Are we taking the same feed — a consolidated feed versus a direct exchange multicast feed is microseconds of difference before any code runs. Is our switch adding a store-and-forward hop where cut-through would do? Is the NIC doing interrupt coalescing? Is the CPU scaling frequency, or is a core shared, or is the process migrating between NUMA nodes? Is there a page fault on a cold path? Half the latency problems I've seen were configuration, not code.
Then the code. No allocation in the hot path, no locks, no system calls, no branches you can hoist, and the data laid out so the working set stays in L1. Busy-poll rather than block, pin threads to isolated cores, disable the scheduler on those cores.
Then hardware. FPGA for feed parsing and for the simplest risk checks is real and well proven; FPGA for actual strategy logic is much rarer than the marketing suggests and only pays when the logic is genuinely simple.
And I'd ask the commercial question: is 2 µs the winning number, or is this a race we are not going to win? Sometimes the right answer is to compete on a strategy where four microseconds does not decide the outcome, and being willing to say that is not a weakness.”
Measuring the distribution rather than the mean, checking configuration and physical topology before code, and the willingness to ask whether the race is worth entering.
What to build or bring
- C++ at a level you can defend — memory model, cache behaviour, what the compiler actually emits. You will be asked to reason about assembly.
- A measured project. Something where you cut a latency number and can show the histogram before and after.
- Know the vocabulary: kernel bypass, busy-poll, NUMA, cut-through versus store-and-forward, PTP, cache-line false sharing.
- Expect a hard systems interview, not a LeetCode one. Optimisation under a stated constraint, out loud.
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $300k – $800k+ | Among the highest-paid engineering roles anywhere |
| India | ₹35L – ₹1.2Cr | Concentrated in Mumbai, Bengaluru and Gurugram prop shops |
The book for this field
Trading & Capital Markets
Eight chapters on how markets actually work: the order lifecycle end to end, the limit order book and how a price is made, the Indian and US market structures side by side, what each instrument is really for, the full cost of a trade, market data and the errors that ruin research, and the latency budget.
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 10 Trading questions → · Back to Trading & Capital Markets →