Citadel System Design Interview Questions

Before you prep a single design, settle one thing about what "system design" means at Citadel. It is not the "design Twitter" round you rehearsed for a consumer company. The systems here move orders and market data in microseconds, and the interview probes the same instincts the desk lives on: how fast, how deterministic, how correct under a burst. A limit order book. A market-data feed handler. An order gateway with pre-trade risk on the hot path. The vocabulary is trading, and the clock reads in microseconds, not the hundreds of milliseconds a web request can spend.

The Citadel angle

Two firms share the Griffin name, and the design round looks different at each. Citadel Securities is the electronic market maker, and this is where the deepest low-latency C++ trading-systems design lives: order books, feed handlers, kernel-bypass networking, lock-free queues. Citadel, the hedge fund, staffs platform and data-infrastructure roles, along with risk and research-tooling seats that lean on the same order-book and market-data vocabulary but with more of a data-infra and risk flavor. The two hire and interview separately. So the first move in your prep is knowing which entity your loop belongs to, because it sets how far into microsecond territory the round will push. This guide serves both, and each design ahead notes where the two diverge.

The round is gated, and it comes in two shapes

A dedicated boxes-and-arrows design round is not universal. Candidate reports point to a split by seniority and team. New-grad and junior software-engineer loops are coding-dominant: an online assessment on HackerRank, then live coding phone screens. When "design" appears for them, it usually arrives as a coding-flavored exercise. Most often you implement a working order book in about 45 minutes and then defend its cost model, rather than talking through a whiteboard. Senior and HFT-adjacent loops add the standalone design round at the onsite Superday, and there the low-latency, kernel-bypass, lock-free depth is expected. Treat the two modalities below as one continuum, from "build the structure" to "architect the system."

• The coding-design exercise: Implement it live. Most common for phone screens and junior loops. Build a working order book or matching engine in roughly 45 minutes, then defend the per-operation cost. A big-tech loop is satisfied when your solution is correct with the right big-O. This round assumes that and asks the deeper questions: where does the memory come from, what is the cache behavior, what would you profile first.
• The verbal design round: Architect the system. Senior and HFT-adjacent onsites. Feed handler, order gateway with risk, risk aggregation, "design a real-time trading platform." Judged on microsecond latency, on determinism and replayability and reliability, and on a repeated "why that data structure?" drill over every choice you name.
• Where it is not: The online assessment. The HackerRank OA is pure algorithms, with no system design. Design surfaces only later, in a phone screen or the onsite, so do not expect boxes and arrows before a human is in the room.
• The language lean: C++ for the hot path. Citadel Securities and low-latency roles skew heavily to C++, where the memory model and cache lines and allocation cost are all part of the answer. The hedge fund platform side is more language-flexible, with Python and other tools common on data and research infrastructure.

The Citadel angle

Confirm on the recruiter call whether a standalone design round is even in your loop. For a new-grad software-engineer seat the honest answer is often no, and the order-book work reaches you as a coding exercise instead. For a senior systems or Securities C++ seat, assume yes, and assume it runs deep on latency and concurrency. Preparing full architecture designs for a junior coding loop wastes the hours you should spend on the implement-it-live drill; walking into a senior Securities onsite with only algorithm practice leaves the low-latency questions unanswered. The gating is real. Calibrate your prep to the seat, not to a generic "there is a design round" assumption.

The design shapes, by how often they surface

Every design worth prepping is a trading system. The chart groups them by shape, collapsing the many re-skins into the underlying problem. Citadel does not publish a question list, and the surface is team-dependent, so read the ordering as a steer toward where your hours pay off rather than a measured rate. One representative prompt anchors the section:

Each shape forces a different hard tradeoff. That is why they are worth learning separately rather than as one "trading system." The order book is about picking structures where the common operations, and especially cancels, stay O(1) or O(log n). The whole thing has to stay cache-friendly under a burst. The feed handler has to decode proprietary binary streams from many venues into one canonical schema, then recover cleanly when a packet goes missing without stalling everything behind it. The order gateway runs pre-trade risk checks on the hot path in constant time while still committing an event log durably. The durability commit, not the checks, is what dominates the latency budget. The running fan-in that rolls per-symbol exposure across thousands of strategies rides on top of those same gateway checks. The hard call there is how stale a risk number is allowed to get before it turns dangerous. The tick store is historical data at scale, a columnar time-partitioned layout tuned so a research query can scan years of ticks without touching the order path. Backtesting and replay then reuse that same append-only log to reproduce a day bit for bit, so a strategy only ever sees what existed at the simulated moment.

The Citadel angle

What separates a Citadel answer is that it defends the cost of every choice, in the units the desk cares about. Naming a balanced tree for the price levels is the start of the answer, not the end. The follow-up comes fast. Why not a flat array indexed by tick? What does that trade in memory for a cache-friendly O(1) lookup? And a cancel that has to walk a list is the difference between a book that keeps up during a burst and one that falls behind. Calling for a queue invites "which one, and how much does it buffer before you decide a gap is real." Reaching for new and delete on the order path is close to disqualifying at a latency-sensitive shop; the expected answer is a pre-allocated memory pool with a free list. The mode to practice is a senior engineer at a whiteboard who can put a number and a reason on each decision, not a candidate reciting a reference architecture.

The pipeline the designs plug into

The five designs are not independent. They are stages of one machine that turns raw market data into orders and keeps risk honest while it does. Carry the whole pipeline in your head. It lets you place any single prompt inside the larger flow and speak to the boundaries the interviewer will push on.

Read the flow in chips. A trading venue pushes ticks into the feed handler, which fans them into the order book and the tick store. The strategy engine reads the book, sends orders through the order gateway and its pre-trade risk gate, and orders leave for the venue while the event log captures everything for replay. Here is the instinct to carry. The order book and the risk gate sit on the hot path where microseconds count. The tick store and replay run at scale but off that path. Knowing which side of the line a component sits on decides how you reason about it.

The latency and capacity budget

Numbers anchor this round more than most. Have a few in your pocket before you draw anything. These are representative of the constraints that show up in reported prompts and in the public literature on exchange and market-maker systems, not figures Citadel publishes about its own stack.

• Feed decode: 1 to 5 microseconds. A tuned feed handler decodes a market-data message in low single-digit microseconds. Kernel-bypass networking (DPDK or Solarflare) and RDMA are what take you from the 20 to 50 microseconds a normal kernel socket path costs down to that range. Naming the source of the win, not just the number, is the point.
• Order book op: O(1) cancel, O(1) top-of-book. The winning structure keeps add, cancel, and best-bid/best-ask cheap even under a burst. Cancels are often more frequent than fills, so an O(1) cancel through a hash map from order id to node is the load-bearing choice, not a nice-to-have.
• Gateway target: P99 ack < 5 ms at 200k orders/s. A commonly reported low-latency-gateway prompt gives roughly 200,000 orders per second at peak with a P99 end-to-end acknowledgment under 5 milliseconds, RPO near zero and RTO under a minute. The synchronous durability commit for RPO near zero is what eats most of that budget, and saying so is the senior move.
• Memory discipline: Pools, not new/delete. On the order path, allocate from pre-allocated pools and free lists so there is no per-order heap allocation and no fragmentation after 72 hours of uptime. Allocation cost and cache locality are first-class in this budget, not an afterthought.

The interface these designs share is small and worth naming precisely, because the interviewer will call these operations by name when they push on the cost model. The order book is the canonical example:

What the round rewards

The bar is not "the design works." A correct architecture can still fall short here. Say it never puts a latency number on the hot path, never defends a data structure against its alternative, never reaches determinism and failure recovery. Then it misses the bar, the same way a working-but-suboptimal solution misses in the coding round. The contrast below is the shape of a strong answer against a generic one.

The worked designs

Five designs follow, each a distinct trading-systems shape. Start with the limit order book and matching engine. It is the signature. It appears in both the coding and the design tracks, and every other design in the section touches the vocabulary it establishes.

Each design assumes the fundamentals from the System Design course: the scaling playbook for read and write paths, and the toolbox for when to reach for a log, a queue, or a store. The pages here stay on the trading-systems and low-latency judgment Citadel tests. They lean on those for the general mechanics.