Citadel Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Citadel.

• They are not hiring a coder. They are hiring someone who is right.
• A subtle bug or a wrong probability estimate costs real money fast: a mispriced quote that trades thousands of times before anyone notices.
• They would rather pass on a smart person than hire one who guesses confidently and is wrong.
• That single fact explains almost every scoring decision below. Keep it in your head through every round.

2Getting the call (the part most guides skip)#

Citadel gets flooded. The OA funnel is wide, so the real edge is getting pulled to the top of the pile before it.

Referrals matter, but not the way you think.

• A referral does not skip you past the OA.
• What it does: gets a recruiter to actually look at your profile and route you to the right team (QR vs QD vs core SWE).
• Routing matters because the three tracks score different skills. Land in the wrong one and you get judged on things you didn't prep.
• If you know anyone there, even loosely, ask them to refer and to tell you which team fits your background. That routing is half the battle.

Your resume needs numbers that imply you understand performance and scale. Quant and trading-infra teams care about latency, throughput, and correctness, in that order. Compare these two bullets:

• Weak: "Built a data pipeline in Python for analytics."
• Strong: "Built a C++/Python pipeline processing 2M market events/sec, cut p99 latency from 40ms to 6ms by replacing locks with a lock-free ring buffer."

Why the second bullet stops a 10-second skim:

• It says you've touched real performance work.
• It says you measure p99, not just the average.
• It says you know locks are often the hot-path bottleneck.
• That is the language they speak. A recruiter stops on it and keeps walking past the first.

ATS keywords worth having when they're true: C++, low-latency, multithreading, data structures, probability, statistics, time series, Python, Linux, and any real competitive-programming rating (Codeforces, USACO, ICPC, Putnam, IMO).

• A high Codeforces rating (say 2000+, Candidate Master and up) or an ICPC regional finish is a genuine shortcut.
• They respect it because it correlates with the exact skill they test: correct code, fast, under a clock.

How people actually get shortlisted:

• Strong school or strong competitive track.
• A clean one-page resume with one or two performance-flavored projects.
• A non-zero signal that you like hard math (a probability course, a Kaggle finish, a Putnam score, anything).
• New grads: the fastest path is their campus pipeline and the OA. Do the OA well and the rest opens up.

3The loop at a glance#

Not everyone gets every round. The track decides the mix:

• QR: heavy probability and the market-making game.
• Core SWE: more coding, concurrency, and low-latency C++.
• QD: in between, roughly half coding and half systems, with a probability question thrown in to check you can reason about randomness.

Here is the shape of it end to end.

4The coding or technical rounds#

The honest truth about Citadel coding: the problems are not exotic. They are well-known patterns. What's hard is the speed, the correctness bar, and someone sharp watching you reason. You feel the clock in a way you never do practicing alone at home.

Patterns they reuse constantly (roughly 80 percent of what shows up):

• Arrays and two pointers, sliding window.
• Hash maps for counting and lookup.
• Heaps and priority queues (top-K, streaming median).
• Binary search, including binary search on the answer.
• Intervals (merge, insert, overlap).
• Graphs and BFS/DFS, shortest path.
• Dynamic programming, the standard families (knapsack, LIS, interval DP).
• Stacks and monotonic stacks.

Difficulty and tempo:

• Roughly LeetCode medium with a few hards.
• The clock is tighter than most, and the follow-ups go deep.
• They love "now what's the time complexity, and can you do better?" the instant you finish.
• Have the answer ready before they ask. Fumbling complexity after writing correct code still drops your score.

A concrete example of the streaming-median flavor they like. It hits heaps and forces you to maintain an invariant online:

import heapq

class MedianStream:
    def __init__(self):
        self.low = []   # max heap, negated
        self.high = []  # min heap

    def add(self, x):
        heapq.heappush(self.low, -x)
        heapq.heappush(self.high, -heapq.heappop(self.low))
        if len(self.high) > len(self.low):
            heapq.heappush(self.low, -heapq.heappop(self.high))

    def median(self):
        if len(self.low) > len(self.high):
            return -self.low[0]
        return (-self.low[0] + self.high[0]) / 2

Say the shape out loud as you write it:

• Each add is O(log n), median is O(1).
• The interviewer will immediately follow with "what if values arrive faster than you can process them" or "what if you only care about the median of the last 1000 ticks."
• Have the sliding-window answer loaded before they ask.

How to actually win the coding round. This is the part that separates offers from rejections.

Clarify first.

• Restate the problem.
• Ask about input size, duplicates, empty inputs, negative numbers, integer overflow.
• When I watch a candidate clarify edge cases up front, I trust them more immediately.
• Interrupting yourself later with "oh wait, what about empty input" reads as sloppy and burns time you do not have.

Talk while you think.

• Narrate the plan before you type: "when I run a loop here, what I'm really checking is whether this window is still valid."
• Silence kills you. I can't give credit for an idea I can't hear.
• A three-minute silence followed by perfect code scores below a running commentary with one small bug.

State complexity out loud, early.

• Before you code: "this is O(n log n) time, O(n) space, I think we can get to O(n)."
• That one sentence tells me you think like an engineer and won't brute-force something that trades millions of times a day.

Test your own code.

• Dry-run a small example by hand. Walk the pointers.
• Catching your own bug before I point it out is a massive signal.
• Shipping buggy code and shrugging is the opposite, and at their correctness bar it is close to a hard fail.

For the probability and brainteaser side (QR and most quant tracks), expect:

• Expected value problems. Dice, coins, card draws. "Expected number of rolls to see all six faces" is a classic, the answer is 6 times the sixth harmonic number, which is 14.7.
• Conditional probability and Bayes. The classic "two kids, one is a boy, probability both are boys" family. The answer is 1/3, and they want to see you enumerate the sample space BB, BG, GB and condition correctly.
• Combinatorics and counting.
• Simple martingale/random walk reasoning. "You're at 0, random walk, probability you hit +3 before -2." For a symmetric walk this is 2/5, by the gambler's ruin formula, and you should set up the linear equations rather than recall the number.
• Pure logic puzzles. 100 prisoners and light switches, poisoned wine bottles, that genre.

How to earn the probability round, not just answer it:

• Practice out loud with a timer. The firm cares as much about how cleanly you decompose the problem as about the final number.
• Set up the sample space, name your random variable, write the recurrence. Don't blurt.
• Sanity-check every number: "that's 0.4, which feels right because it should be a bit less than a half."
• That instinct is exactly what they want. A trader who cannot smell when a number is wrong is dangerous.

Mental math:

• You should do 17 x 24, estimate 1/7 as a decimal, or compute a quick percentage in your head in a couple seconds. (17 x 24 is 408; 1/7 is about 0.143.)
• Drill it. Zetamac is the standard tool everyone uses. Set it to the default addition/subtraction/multiplication/division config and aim for 40+ before you walk in.
• Get comfortable being fast and loose without a calculator.

5The market-making game and low-latency round#

This is the Citadel-flavored round people are least ready for, and it's where quant/trading candidates win or lose. You cannot cram it the night before, so start practicing in week one.

The market-making game.

• The interviewer picks something with an uncertain value: number of countries in the world, sum of two dice they'll roll, something estimable.
• You make a market: quote a bid and an ask, "I'll buy at 180, sell at 195."
• They can hit your bid or lift your offer, and the true value gets revealed over several rounds.
• The point is not to know the answer. It is to show judgment.

What they are actually scoring:

• Set a reasonable fair value and a sensible spread.
• Update your quote as information arrives.
• Manage your position and do not panic.
• Stay calm and keep reasoning out loud when they lean on you.

A simple framework that works:

• Anchor on a rough estimate.
• Quote a spread wide enough to protect you but tight enough to be competitive. Think fair value is about 190? Maybe 185 bid, 195 ask to start, then tighten as you learn more.
• When they trade against you repeatedly in one direction, ask "do they know something?" and widen or shift your market toward where they keep trading.
• If they keep lifting your offer at 195, your fair value is probably too low, so raise both sides.
• Explain your logic the whole time. They're testing judgment under uncertainty and whether you tilt emotionally after a bad fill.

The low-latency / systems round (core SWE and QD). For the engineering tracks, expect C++ and performance. Topics that come up:

• Concurrency: threads, locks, lock-free structures, data races, memory ordering (acquire/release, and why std::memory_order_seq_cst is the safe default but not the fast one).
• Memory: cache lines (64 bytes on x86), false sharing, allocation on the hot path, why std::vector beats std::list for cache locality because the elements sit contiguously instead of chasing pointers.
• C++ specifics: move semantics, RAII, virtual dispatch cost (the vtable indirection you pay per call), templates.
• Latency thinking: "where's the hot path, what allocates, what blocks?"

What the round usually looks like:

• Not always a full distributed-system design. More often "design a thread-safe order book" or "how would you make this message handler faster?"
• Frame your answer around the hot path: avoid allocations and locks where you can (pre-allocate buffers, use a single-producer single-consumer ring buffer, pin threads to cores), and measure.
• Say "I'd profile it first before guessing" and you sound like someone who has shipped real low-latency code, because that is exactly what people who ship it do.

6Behavioral and culture fit#

Citadel's culture is intense, meritocratic, and allergic to politics. The values that actually show up:

• Being right matters more than being liked.
• Ownership.
• High standards.
• Intellectual honesty. They respect "I was wrong, here's how I caught it" far more than someone who was never wrong because they never took a risk.

Prepare 4 or 5 STAR stories (Situation, Task, Action, Result) with real numbers in the results.

• They'll probe: a time you were wrong, a time you disagreed with someone senior, a hard technical call you made, how you handle pressure.
• Vague stories with no numbers read as fiction. Anchor every one to a measurable outcome.

One full worked example:

• Situation: During a release, our trading service's p99 latency spiked from 8ms to 45ms under load, and nobody could reproduce it locally.
• Task: I owned the latency SLA for that service, so I had to find and fix it before the next market open.
• Action: I pulled production flame graphs instead of guessing. The time was going into lock contention on a shared counter hit by every thread on the hot path. I replaced it with a per-thread counter aggregated lazily, then load-tested the change against a replay of the prior day's traffic.
• Result: p99 dropped back to 7ms, actually a hair better than before, and we shipped the next morning with zero missed opens. I also added a latency regression check to CI so it couldn't silently come back.

Why that story lands:

• It has a number, a concrete action, and a bit of "I made it not happen again."
• That last part is the ownership they want.
• The "I was wrong about where the time was going until I looked at the flame graph" admission is the intellectual honesty they reward.

7Your prep plan#

4-week plan:

• Week 1: 40 LeetCode mediums across arrays, hashing, two pointers, intervals. Start daily Zetamac. Play your first market-making game with a friend so the format is not new later.
• Week 2: Heaps, binary search, graphs, DP. Add one hard every other day. Start a probability problem set (aim for 5 EV and Bayes problems a day).
• Week 3: Daily probability and brainteasers out loud with a timer. Practice market-making games with a friend. For SWE, drill C++ concurrency and cache questions.
• Week 4: Full mock onsites. Simulate the OA under time. Polish 5 STAR stories. Keep Zetamac daily and hold your 40+ score.

2-week plan:

• Days 1 to 5: Mediums at speed plus Zetamac daily. Cover the core patterns in section 4.
• Days 6 to 9: Probability, EV, Bayes, combinatorics out loud. One market-making mock.
• Days 10 to 12: Hards, DP, and (SWE) low-latency C++.
• Days 13 to 14: Two mock interviews, STAR stories, timed OA simulation.

2-day crash plan:

• Day 1: Re-solve 15 classic mediums you already know cold, for speed. Do 10 EV/Bayes problems. 3 Zetamac sessions.
• Day 2: 5 brainteasers, one market-making game out loud, review complexity analysis, write 3 STAR stories. Sleep, because a tired brain fumbles 23 x 7 and that alone can sink a quant round.

Speed is a skill you rehearse, not a trait you're born with. Drill under a clock until the clock stops mattering.

8Why people get rejected at Citadel#

1. Silent thinking. They can't score reasoning they can't hear. Candidates who go quiet for three minutes then write perfect code still score lower than someone who narrates a slightly messier path.
2. Hand-wavy probability. Blurting a number with no sample space, no setup, no sanity check. If you can't show the structure, they assume you got lucky, and lucky does not survive a live trading desk.
3. Untested code. Submitting without dry-running an example, then having the interviewer find an off-by-one. That's an automatic ding at their correctness bar.
4. Tilting in the market-making game. Panicking, quoting wild spreads after one bad trade, or going silent. They read that as how you'd behave with real risk, and real risk is the whole job.
5. Slow or shaky mental math. Fumbling 23 x 7 (it's 161) in a quant round undercuts everything else. It's basic and they expect it fast.
6. Arrogance without correctness. Confidently wrong is the worst combination here. Being humble about uncertainty and precise about what you know beats swagger every time.

9The offer, comp and negotiation#

Realistic ranges. These move with market and team:

• US new grad: base often $150k to $200k, meaningful sign-on, first-year total frequently $300k to $450k+ for QR and strong SWE/QD.
• US experienced: $400k to $900k+ all-in is common for strong mid to senior, and top quant researchers go well beyond that with performance.
• London: juniors roughly GBP 90k to 150k base with large bonuses; seniors into strong six figures plus bonus.
• APAC (HK/Singapore): competitive local packages for quant/SWE; India presence is limited and more tech/support-oriented, so calibrate expectations and don't anchor on US numbers.

Negotiation tips specific to Citadel:

1. Bring a competing offer if you have one. A real, comparable offer (Jane Street, Two Sigma, HRT, a top tech L5) is the single strongest lever. They move for it because they are competing with exactly those firms for the same people.
2. Negotiate the sign-on and the bonus framing, not just base. Base is somewhat banded, especially for new grads. Sign-on and the bonus/guarantee structure have more give, so put your pressure there.
3. Be precise and unemotional, like you'd expect them to be. State your number, your reasoning, and your timeline once. Don't over-negotiate a firm that prizes directness. One clean, well-justified ask lands better than a drawn-out back-and-forth, and a sloppy emotional ask can actually cost you goodwill at a firm that reads it as a signal.

10FAQ#

Want this turned into a dated, day-by-day plan built around your own timeline and target track? Map it out and start today.