Citadel OA Interview Experience (2026) - Tree DP & MEX, Offer

• Root the tree at 0. Perform a DFS.
• At each node, track for each type: the earliest time this subtree could finish upgrading all nodes of this type.

More concretely, let finish[u][t] = earliest time at which all nodes of type t in the subtree of u (plus u itself if u 's type is t ) are fully upgraded. The node u must start after its parent finishes.

For each child c of u , its subtree's "earliest start for type t " is constrained by (1) u 's finish time, and (2) the finish time of any other sibling's nodes of type t . Because same-type nodes can't overlap, siblings need to be serialized per-type.

For each type t , merge the children's contributions by scheduling their type- t workloads serially (sum of per-child type-t durations). For different types, children run in parallel (max of per-child finish times).

I did not get this fully right in the OA. My recursive solution handled the "parent-before-child" constraint correctly but botched the "same-type cannot overlap across siblings" constraint, so the type-t bookkeeping across subtrees was off. Got partial credit, about 10 of 15 test cases.

In retrospect, the clean approach is to treat it as a DAG scheduling problem: build a dependency graph where each node has predecessors (ancestors, plus any earlier same-type node in a fixed ordering) and find the critical path. That's what I should have done, and the interviewer in a later round confirmed it.

Problem 2: Maximum MEX of a Memory Block

Problem: You have memory divided into blocks. A block is a contiguous sequence of integers. The "MEX-valid size" of a block is the smallest non-negative integer not present in the block. You can partition an array into multiple non-overlapping contiguous blocks. Maximize the sum of MEX-valid sizes across blocks.

This looked scary but was solvable with a clean DP.

Let dp[i] = maximum sum of MEXes using the prefix a[0..i] , partitioned however.

Transition: for each j <= i , dp[i] = max(dp[j-1] + mex(a[j..i])) . O(n²) partitions × O(n) for computing MEX = O(n³). Too slow for n = 10^4.

Observation: MEX of a set is bounded by the set size. For a block of length L , MEX <= L . Also, MEX(S) <= MEX(S ∪ {x}) for any x (adding elements can only keep MEX the same or increase it).

Second observation: if we extend a block to the right by one element, the MEX either stays the same or increases by 1 or more. We can maintain MEX incrementally using a frequency counter + a pointer to the current smallest missing value.

Still, the DP has O(n²) states. I got 60% credit on this problem with an O(n²) approach: for each ending index i , extend the block backwards, maintain the running MEX with a present set plus a pointer that only moves up, and take the best dp[j-1] + mex(a[j..i]) . The full-credit solution almost certainly uses an observation about adjacent MEX structures that I did not spot in time.

What I Learned From the OA

Citadel's problems reward algorithmic maturity more than pattern recognition. Both problems had a clear brute-force approach that passed most but not all test cases, and a clever observation that unlocked full credit. If you get partial credit on both, you're likely to pass — that's what happened to me.

Time management: 35 minutes per problem is the right budget. Don't let one problem consume 50 minutes and leave you 20 for the other. I made that mistake on Problem 1 and had to rush Problem 2.

Super Day Preview

Four rounds in one afternoon: two coding, one market/statistics-flavored, one behavioral. The coding rounds went closer to Jane Street style than FAANG style — expect probabilistic problems, expected-value calculations, and fast mental math. I will write a separate post on the Super Day if it seems useful.

Practice it: [[problem/187?company=33|Merge K Sorted Arrays with Cumulative Sum]]

Result

Offer came 6 business days after Super Day. SWE new grad at a Citadel Securities tech team in NYC. The comp package was higher than any FAANG offer in my cycle, as expected. The recruiter was upfront that the number was "best and final" — which is typical for Citadel.

Tips

1. Treat Citadel's OA like a coding contest, not a standard OA. Problems are harder than you'd expect for an entry-level screen. Prep on Codeforces Div 2 / HackerRank medium-hard before the OA.
2. Write the brute-force first, submit, then optimize. Partial credit is your friend. An O(n²) solution that passes 60% is better than an O(n log n) solution you never finish. Get something working early.
3. For tree DP problems, draw the tree before you code. Small example, maybe 6 nodes. Write out the recurrence on paper. Citadel loves problems where the recurrence has non-obvious constraints (like "siblings can't overlap per type" here), and catching them requires an example.
4. MEX problems have a canonical pattern. Maintain a set + a pointer to the current smallest missing value; advance the pointer when the set covers it. Almost every MEX problem you'll see uses this.
5. For Super Day, brush up on probability. Citadel likes expected-value questions embedded in coding problems — "what's the expected value of X given this random process?" Standard interview-prep-math-level: conditional probability, linearity of expectation, Markov chains.
6. Do not skip the behavioral. Citadel is small and culture-fit matters a lot. "Why Citadel" should not be "because of the money." Have a real answer about what attracts you to a quant/HFT-adjacent environment.

Citadel's process is intense but honest. The interviews are the best predictors of the actual work I've seen in any finance-adjacent company.