Lakshya

Trading & Capital Markets

Low-Latency / Core Engineer

Trading · small, brutal, very well paid

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

TimeWhat you are actually doing
08:00Read yesterday's latency histogram. The mean is meaningless; you live at the 99.9th percentile.
10:00Profiling. Cache misses, branch mispredictions, and a hot path that allocates once and should not.
13:00A kernel-bypass stack question — Solarflare/Onload or DPDK, and whether the NIC or the switch is adding the jitter.
15:00Working with hardware: FPGA offload for the parsing stage, and what genuinely belongs there versus what is fashion.
17:00Measuring, 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

MarketBandNotes
United States$300k – $800k+Among the highest-paid engineering roles anywhere
India₹35L – ₹1.2CrConcentrated 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.

CHAPTER 8Latency: where it comes from, and what it costs to removeA budget in microseconds, an arms race with a physical floor, and the honest question of whether you should be in the race at all.READ THE CHAPTER →CHAPTER 2The order book, the spread, and how a price is actually madePrice is not a number the market has. It is the outcome of a queue, and understanding the queue explains costs, liquidity and most of what a trading firm does.READ THE CHAPTER →CHAPTER 4The US market: fragmentation, Reg NMS and the NBBOSixteen exchanges, dozens of dark pools, and a rulebook built to make a fragmented market behave like one. This is where American market-structure jobs come from.READ THE CHAPTER →

All 8 chapters in Trading & Capital Markets →

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.

Latency and cost arithmeticThe one piece of maths that is genuinely counterintuitive — and it comes up in every agent interview.READ THE CHAPTER →Design under constraintThe decisive round for SRE, AI Platform, Infrastructure — and the reason strong engineers fail it.READ THE CHAPTER →Measuring what resists measurementTested in every field on this site under a different name — evals, SLOs, DORA, ablations. Named in 59% of AI and 42% of platform postings, and almost nobody studies it deliberately.READ THE CHAPTER →

Practice the 10 Trading questions →  ·  Back to Trading & Capital Markets →