# Inside the FPGA interview at a low-latency trading firm

Source: https://www.techinterview.org/post/3233477296/fpga-interview-low-latency-trading-firm/
Updated: 2026-08-10 · techinterview.org

A tuned x86 server running kernel bypass will move you from a market-data packet landing on the wire to an order leaving the NIC in roughly one to five microseconds. A well-built FPGA does the same loop in a few hundred nanoseconds, and the fastest published wire-to-wire figures sit under 25 nanoseconds. That gap is the entire reason these jobs exist, and the interview is built to find out whether you can hold a design in your head at that timescale without losing the thread.

The roles carry a few titles: FPGA engineer, hardware acceleration engineer, low-latency network engineer. The desks hiring for them are the ultra-low-latency shops you'd expect, Jump Trading, Hudson River Trading, Optiver, IMC, Citadel Securities, DRW, XTX. The work is Verilog or VHDL, occasionally high-level synthesis, running on AMD (Xilinx) or Intel (Altera) parts, wired to a market-data feed on one side and an exchange order gateway on the other.

## How the loop is structured

Expect a recruiter screen, then a technical phone screen that is mostly digital-design questions plus one small HDL problem you write in a shared editor. Pass that and the onsite splits into three or four rounds: a longer HDL exercise, a fundamentals grilling on timing and clock domains, a networking round, and a systems round where they ask how you'd build the tick-to-trade path from the wire in to the wire out. Some firms hand you a take-home instead: parse this market-data format in RTL, hit this latency target, show me your testbench.

What people underestimate is how much of the bar is ordinary digital design done cleanly, not clever trading logic. The logic on the critical path is usually simple on purpose. The hard part is making simple logic meet timing at 300-plus MHz with single-cycle determinism, and doing it in a way the next engineer can read.

## The Verilog they make you write

The classic warm-up is a parser. You're handed a fixed-layout market-data message and asked to pull one field out with the lowest latency you can manage. The naive version registers the whole frame, then indexes into it. The better version streams the packet a word at a time as it comes off the MAC and grabs the field the cycle it lands, because waiting for the last byte of a frame before you start is latency you'll never get back.

Other staples show up again and again: a parametrized synchronous FIFO with correct full and empty flags, a fixed-priority arbiter, a small state machine that decodes a length-prefixed message. If you can write something like this and then talk about its latency in cycles, you're most of the way there:


```
// price lands on the beat where beat_idx == 1; grab it that cycle
always @(posedge clk) begin
  if (valid && beat_idx == 1)
    price <= data[63:32];   // upper 32 bits of this 64-bit beat
end
```


They care less about flawless syntax than about whether you know when your data is valid, how many cycles you just spent, and whether the logic is registered so it will actually close timing on a real part.

## The fundamentals round is where people fall out

This is metastability, clock domain crossing, and timing closure, pushed until you run out of depth. Market data arrives on the MAC clock, say 156.25 MHz for 10-gigabit Ethernet, while your core logic runs faster on its own clock. Every signal that crosses between the two is a chance to sample a value mid-transition and latch garbage. They'll ask how you move a single control bit across (a two-flop synchronizer), how you move a whole word (a small asynchronous FIFO or a request-acknowledge handshake), and what actually breaks if you skip it. "It worked on the bench" is the wrong answer, because metastability is a probability, and at these clock rates a one-in-a-billion event shows up on a human timescale.

Then timing closure. A path that fails setup means the signal doesn't settle before the next clock edge, and the fix menu is short: pipeline the logic into more stages, cut the fanout, retime the registers, or drop the clock frequency, which you can't do here. Interviewers want to hear you reach for pipelining first and then acknowledge the catch, that every stage you add is one more cycle of latency you're spending. That tension, more pipelining to close timing versus fewer cycles to stay fast, is the actual craft of the job, and a good interviewer keeps poking to see whether you feel it.

## Where the nanoseconds go

The systems round tends to open with "walk me through tick-to-trade." The answer they want is a budget, not a hand-wave. A packet hits the transceiver, works through the PCS and MAC layers, you parse it, update whatever book or signal state you keep, make a decision, encode an order, and push it back out through the MAC and SerDes. Each stage is tens of nanoseconds or less, and the SerDes crossing in each direction is a fixed tax you cannot optimize away, which is why people quote it separately.

| Tick-to-trade implementation | Typical tick-to-trade latency | Latency jitter | What it fits | Main cost |
| --- | --- | --- | --- | --- |
| Standard kernel network stack (BSD sockets) | 10-50 microseconds | High | Research and strategies that aren't latency-bound | None beyond a normal server |
| Kernel bypass on a tuned CPU (Onload, DPDK) | 1-5 microseconds | Moderate | Most latency-sensitive strategies | Specialized NIC plus heavy tuning |
| Hybrid: FPGA feed handler, CPU strategy | Hundreds of nanoseconds to ~1 microsecond | Low on the fast path | Fast hardware trigger, complex decision in software | Hardware team plus software team |
| Full FPGA tick-to-trade | Tens of nanoseconds to a few hundred | Very low, single-cycle deterministic | Simple, well-defined hot path such as quote or cancel | Scarce HDL talent, long build cycles, rigidity |

The table is the argument you're making in the room. You don't put everything in hardware because you can. You put the latency-critical slice there and leave the rest where it's cheaper to change.

## What lives on the FPGA and what stays on the CPU

A senior answer draws the line on purpose. On the FPGA: feed decoding, book building or a lightweight signal, pre-trade risk checks, order encoding. On the CPU: the strategy's slower brain, parameter updates, position and P&L tracking, anything you'll want to change without an hours-long place-and-route. The pattern most desks settle on is a fast trigger in hardware, something like quote-or-cancel on a specific condition, with the CPU loading the thresholds and stepping in when the situation is more complicated than the hardware path was built for.

The follow-up that catches people: how do you change a strategy that lives in the fabric? You don't recompile mid-session. You parameterize. The FPGA reads thresholds and enable bits out of registers the CPU writes, so software can retune behavior without a new bitstream. When a change genuinely needs new logic, that's a rebuild and a redeploy between trading sessions, and the fact that this is slow and rigid is the whole reason the complicated logic stays in software.

## The market-data questions

You'll get protocol specifics. CME's MDP 3.0, Nasdaq's ITCH, and the exchange's binary order-entry format are the usual reference points. They'll ask about A/B line arbitration, where the exchange sends two identical multicast feeds and you take whichever copy of a packet arrives first, deduplicating by sequence number. They'll ask what you do on a sequence gap: you detect the hole and, depending on the design, either request a replay or fail over to a recovery feed, all without stalling the fast path. And they'll ask how you timestamp, because you can't measure tick-to-trade if you can't put a nanosecond-accurate stamp on the inbound packet at the MAC layer, usually off a PTP-disciplined clock.

A handful of questions phrased close to how they land in the room:

- "Parse this fixed-layout message and give me the price field with the fewest cycles of latency."

- "Cross this valid signal from the 156.25 MHz MAC clock into your 322 MHz core clock."

- "A setup path is failing by 200 picoseconds. Walk me through your options."

- "Two multicast lines, one drops a packet. How does your feed handler stay correct and still keep up?"

- "Where would you place a pre-trade fat-finger check so it doesn't add to the critical path?"

One theme sits under all of it. What the desk is paying for is determinism, not the best average latency. A CPU can beat an FPGA on a good day and then blow a tail latency the moment the kernel schedules something or a cache misses. The FPGA does the same work in the same number of cycles every time, and that flat, boring, predictable tail is the thing worth building a hardware team around. Show up able to talk about jitter as precisely as you talk about the mean, and you're speaking the language they hire in.