Introduction: How to Use This Book

You are a senior software engineer with a production trading-systems background — matching engine, order routing, market-data pipelines, built on crypto/web-stack infrastructure. The hardware floor under those systems is the gap, and three parts of it stand between you and holding your own against an experienced HFT engineer:

1. Kernel bypass & networking — you’ve optimized your code; HFT engineers also optimize the path between the wire and your code.
2. Performance measurement — you know your system does ~10ms; they will ask which microsecond went where, and how do you know your measurement isn’t lying.
3. State upgradability & deployment — how do you change the schema, the protocol, or the binary of a system that must not stop.

Each part ends in a runnable lab. Read a chapter, run its lab, then answer its “Interviewer will ask” box out loud before moving on. Part IV is pure drilling — question banks and spoken scripts to rehearse, no new material.

Running the labs

• Labs are Rust unless stated; each lab chapter has a cargo scaffold to copy.
• Networking labs that need Linux (io_uring, AF_XDP, perf) are marked [Linux]; run them on a throwaway cloud VM or any Linux box — 2 vCPU is enough. macOS-safe alternatives are given where they exist.
• Nothing here needs special hardware. Where real HFT uses exotic gear (solarflare NICs, FPGAs, PTP grandmasters), the chapter tells you what to say about it, since the interview tests understanding, not ownership.

The standing rule

Every claim you make in an interview must be one of: something you built, something you measured, or something you can derive on the whiteboard. This book fills the third category and gives you the vocabulary for the first two.