Coding OA Patterns at Citadel, HRT, and Jane Street: 2026 Prep Playbook

Coding Online Assessment (OA) Patterns at Citadel, HRT, and Jane Street: 2026 Prep Playbook

The coding online assessment is the most-feared filter in quant interview funnels. At Citadel Securities, Hudson River Trading (HRT), Jane Street, and several peer firms (Two Sigma, Optiver, Jump), the OA is timed, monitored, and unforgiving — bombing it ends the process before you talk to a human. The good news: OAs across these firms share recognizable patterns. Strong preparation closes the gap between candidates with similar academic backgrounds. This guide covers what each firm’s OA actually looks like in 2026, the question patterns that recur, and the prep approach that converts.

What’s the OA Format at Each Firm

Jane Street

Jane Street is the lightest-OA shop of the top three. Most candidates start with a recruiter call and a take-home thinking exercise rather than a strict timed coding test. Some candidates encounter:

• An OCaml-flavored functional reasoning problem (the firm uses OCaml internally, but you can solve in any language)
• A short coding exercise emphasizing clean correctness over algorithmic gymnastics
• For SWE / quant developer roles: a HackerRank-style 60–90 min OA with 2–3 problems

Jane Street emphasizes mental math separately (in person or video) and tests probability conceptually. The coding OA is less the gating round here than at Citadel Securities or HRT.

Citadel Securities (and Citadel)

Citadel uses HackerRank for most coding OAs. Format varies by role and team but typically:

• 70–90 minutes, 2 problems
• Difficulty: 1 medium + 1 hard (LeetCode equivalent: medium-hard to hard)
• Languages allowed: most major languages (C++, Python, Java, JavaScript, Go, etc.)
• Problems mix data structure / algorithm classics with quant-flavored variations (signal processing, probability sequences, market data parsing)
• For quant roles: an additional probability / statistics OA may be administered separately

Citadel Securities is more rigorous than Citadel (the hedge fund) on the coding OA — the market-making business demands strong real-time engineering, so coding bar is higher.

Hudson River Trading (HRT)

HRT’s OA is one of the toughest in the industry:

• 90 minutes, 1–2 problems on HackerRank or similar platform
• Difficulty: hard to very hard (LeetCode hard equivalent or beyond)
• Strong emphasis on C++ specific behavior, performance, low-level details — though most languages are allowed
• Problems often have 5–10 sub-tasks with progressively harder constraints
• For software engineer roles: substantial focus on systems / performance reasoning
• For quant researcher roles: probability / statistics OA in addition to coding

HRT’s OA pass rate is reportedly very low (5–10% of candidates). Strong CS-Olympiad-trained candidates clear it; average Big Tech candidates often don’t.

Two Sigma, Jump, Optiver, IMC, SIG

Each has its own variation but generally mirror the Citadel pattern: 60–90 minutes, 2–3 medium-to-hard problems on a HackerRank-style platform. SIG and Akuna emphasize game / probability questions more (as expected from options market makers); Optiver emphasizes mental math separately.

The Question Patterns That Recur

Pattern 1: Array / sequence manipulation under time pressure

Classic LeetCode patterns appear in OAs:

• Two-pointer / sliding window (substring problems, max subarray) — know when the window is fixed-size versus grow-and-shrink, and keep the window’s state updatable in O(1) as the pointers move. The canonical test is “longest substring without repeating characters,” where a hash set tracks the current window and the left pointer advances on a collision.
• Sorting + post-processing (merge intervals, partition problems) — sort first, then a single linear pass does the real work, so the scoring hinges on picking the right sort key. For merge intervals, sort by start time and merge whenever the next interval’s start falls at or before the running end.
• Hash-map counting (frequency questions, anagrams) — almost always O(n) with a dictionary of counts; the actual difficulty is choosing the key. For grouping anagrams, the key is the sorted string or a 26-length letter-count tuple, and getting that key right solves the whole problem.

Why they appear: solid filter for “can you code at all” without requiring deep finance domain knowledge. Most OAs include at least one problem in this bucket.

Pattern 2: Dynamic programming with twist

Classic DP problems with an unusual constraint or modification:

• Coin change variants (minimum coins, count ways, with restrictions) — fix the base cases first: minimum-coins fills the table with infinity and count-ways sets the empty amount to 1. Interviewers check loop order, since putting coins on the outer loop counts combinations while putting amount outside counts permutations.
• Edit distance variants (minimum operations, with special operations) — the 2D table over the two strings is standard, and the twist is usually a new allowed move (a swap, a wildcard match) that adds one transition. Be ready to name each branch — insert, delete, replace — and show where the extra operation fits.
• Knapsack variants (bounded knapsack, multi-dimensional knapsack) — know the loop directions cold: 0/1 iterates capacity in reverse, unbounded iterates forward. The multi-dimensional version just adds a table axis for the second constraint, but memory can blow up, so watch for a rolling-array optimization.
• Sequence alignment / longest common subsequence variations — LCS is the base template; variants change the scoring or ask for the subsequence itself rather than its length. Practice reconstructing the answer by walking backward through the filled table, since that reconstruction is a common follow-up.

Citadel and HRT particularly love DP problems where the recurrence is non-obvious. Strong candidates recognize the DP structure quickly; weak candidates flounder.

Pattern 3: Order book / market data parsing

Increasingly common at trading firms (Citadel Securities, HRT, Jump):

• Parse a stream of order book updates and answer questions about state at time T
• Process trades and compute statistics (VWAP, time-weighted average price, profit / loss given a sequence)
• Handle order matching with limit orders, market orders, cancellations

The pattern: read input carefully, maintain a data structure (often a priority queue or sorted data structure), update it efficiently. Tests data structure choice plus careful state management.

Pattern 4: Probability and expectation simulation

Asked at firms with quant emphasis (Two Sigma, Citadel, HRT, SIG):

• Simulate a stochastic process and report expected value
• Implement Monte Carlo for a problem with no closed form
• Compute probabilities of compound events

The trap: candidates with weak probability fundamentals write inefficient simulations or fail to reason about variance / convergence.

Pattern 5: Graph / tree algorithms with constraints

Classic graph problems with unusual constraints:

• Shortest path with edge weight modifications (Dijkstra variants) — Dijkstra with a priority queue is the workhorse, and the twist is usually an extra state dimension like remaining fuel or a cap on stops. If any edge weight can go negative, switch to Bellman-Ford, and expect to explain why Dijkstra fails there.
• Minimum spanning tree with constraints (must include / exclude edges) — Kruskal with union-find or Prim with a heap; forcing an edge in means adding it before the main loop and merging its endpoints, forcing one out means skipping it entirely. A common follow-up asks how total weight shifts when a mandatory edge isn’t the cheapest choice.
• Strongly connected components, topological sort with multiple valid orderings — build the graph, run Kahn’s algorithm or DFS post-order, and treat a detected cycle as the failure case. When several valid orderings exist, interviewers often want the lexicographically smallest, which means swapping the plain queue for a min-heap.
• Tree problems: lowest common ancestor, tree DP, path queries — lowest common ancestor by binary lifting or Euler tour is a frequent gate, and tree DP combines each node’s children in one post-order pass. A concrete example is computing a tree’s diameter in a single traversal by tracking the two longest downward paths at every node.

HRT particularly loves these. The pattern: standard algorithm + clever data structure choice.

Pattern 6: Bit manipulation and number theory

Less common but appears occasionally:

• Bit manipulation tricks (XOR sums, popcount, bit DP) — memorize the core identities: x ^ x = 0 isolates an unpaired element, x & (x – 1) clears the lowest set bit, and a bitmask encodes a subset as one integer for DP over subsets. The “single number” family, where every value repeats except one, is the standard XOR warm-up.
• Modular arithmetic (Fermat’s little theorem, modular inverse) — when the answer is returned modulo a large prime, division needs the modular inverse, which Fermat’s little theorem gives as a^(p-2) mod p via fast exponentiation. Reduce at every multiplication to avoid overflow in intermediate products.
• Prime sieving and applications — the Sieve of Eratosthenes lists primes up to n in near-linear time, and a smallest-prime-factor sieve then factorizes any number in that range fast. These usually appear as a preprocessing step, so spot the tell whenever a problem loops “for each number up to N.”

These are signaling questions — candidates who clear them quickly have stronger fundamentals than the average.

Pattern 7: Implementation-heavy with no clever trick

Some OAs include a long, careful-implementation problem with no algorithmic insight required — just thorough coding, edge cases, and careful state management. Tests whether you can write production-quality code under pressure.

Prep Approach That Converts

Months 1–2: Fundamentals

• Solve 100–150 LeetCode mediums across all the major topics: arrays, strings, linked lists, trees, graphs, DP, greedy, two-pointer, sliding window, hash maps
• Goal: solid recognition of common patterns and ability to implement standard algorithms in your chosen language at speed
• Practice in HackerRank-style timed mode for at least 30–50 of these

Months 2–3: Hard problems and pattern recognition

• Solve 30–50 LeetCode hards, focusing on DP and graph problems
• Read editorial / discussion solutions to learn alternative approaches
• Time yourself — at this stage you should clear most LeetCode hards in under 45 minutes

Months 3–4: Firm-specific patterns

• Practice on HackerRank’s “Interview Preparation Kit” tracks specific to your target firms
• For trading firms: practice market data / order book problems (some are on HackerRank’s “Hourrank” archive)
• Take 5–10 timed mock OAs under real conditions (90 min, no breaks, no IDE assistance, no AI)

Final 2 weeks: Rest and review

• Stop solving new problems. Review your weak spots.
• Revisit your saved solutions to LeetCode hards in your weak topic areas.
• Take one final timed mock OA 3–5 days before the real one.
• Sleep well the night before.

What to Do During the OA

The first 5 minutes: read everything

Before writing any code, read both problems carefully. Understand what’s being asked, what the input format is, what the constraints are. Many OAs have a “trap” — a problem that looks like it needs a complicated algorithm but actually has a simple greedy solution if you read carefully.

Solve the easier problem first

If problem 1 is medium and problem 2 is hard, solve problem 1 first to lock in the points. Then attempt problem 2. Attempting the hard problem first risks running out of time having scored zero on either.

Test as you go

Run sample test cases as you write. Don’t write the entire solution and then run it — test incrementally. Each minute spent debugging at the end is a minute not spent on the second problem.

Watch the time

Set a mental checkpoint: if you’re 30 minutes in and haven’t started problem 2, move on. Partial credit for problem 2 likely beats perfect on problem 1 alone.

Don’t optimize prematurely

If you have a working O(n²) solution and the constraints suggest O(n log n) is needed, submit the O(n²) first to get partial credit on small test cases, then optimize. Don’t let perfect be the enemy of done.

Common Mistakes

• Skipping the constraints section. Constraints tell you the time complexity needed and what edge cases matter.
• Writing 100 lines of code without testing. Test after every 10–15 lines.
• Choosing the wrong language. Use whichever language you’re fastest in. Don’t use C++ to “look impressive” if Python is your best language.
• Panicking on a hard problem. Step back. Often there’s a small insight you’re missing. If 10 minutes pass with no progress, move on or simplify your approach.
• Ignoring partial credit. If you can’t solve the full problem, at least handle the simple cases for partial points.

Frequently Asked Questions

See also: Jane Street Interview Guide • C++ for Quant Interviews • Breaking Into Quant Finance