Citadel Software Engineer Case Interview: Low‑Latency Order Book and Risk Monitor

This case mirrors real Citadel SWE work: you will design and implement a simplified, production‑leaning limit order book with real‑time risk checks under tight performance constraints. You’ll pair‑program with a Citadel engineer who plays the role of the PM/quant user. Focus areas: (1) data structures for price levels and FIFO time priority; (2) correctness under adversarial market events (add/modify/cancel, marketable orders, crossed markets, out‑of‑order and duplicate messages); (3) latency‑aware coding (O(log P) per update, cache‑friendly layouts, memory management/GC considerations); (4) real‑time metrics (top‑of‑book, rolling VWAP over last N trades, P&L for a position, per‑symbol and aggregate notional/position limit checks with immediate reject/alert); (5) robustness (idempotency, replay, backpressure) and testability. Session structure reflecting Citadel’s style: (a) Problem framing and API sketch (5–10 min) — clarify assumptions, choose language (C++/Java/Python), define message schema (e.g., New, Cancel, Replace, Market), and outline core operations. (b) Implementation (35–40 min) — build: price‑level map keyed by price with per‑level FIFO queue; order id index; handlers for New/Cancel/Replace; matching for Market/marketable limit orders; queries for best bid/ask; rolling VWAP; position/P&L and notional limit risk checks. Code should compile/run; write minimal unit tests on edge cases (partial fills, complete fills, cancels after fill, replace that crosses the spread). (c) Performance and failure analysis (10–15 min) — reason about complexity, hotspots, and micro‑optimizations (allocation patterns, object pooling, avoiding unnecessary copies, batching). Discuss concurrency model options (single‑threaded event loop vs. multi‑producer/single‑consumer with lock‑free queues), and how you’d scale to hundreds of thousands of messages per second. (d) Extensions and design trade‑offs (5–10 min) — persistence/replay strategy, snapshotting, handling symbol sharding, time synchronization, metrics/observability, and how you would validate against exchange feeds. What Citadel specifically evaluates: crisp problem decomposition, bias to measurable performance, attention to correctness under pressure, clear communication of trade‑offs, code quality and tests, and practical market intuition (just enough to reason about order lifecycle and risk). Expect pushback on design choices (e.g., trees vs. heaps vs. skip lists; float vs. fixed‑point; GC pauses vs. custom pools) and follow‑ups on how you’d profile in production and fail safely. Deliverable by the end: a working, readable core with tests plus a reasoned plan for productionizing (monitoring, replay, and scaling).