HackTheRounds Interview Experiences

Jane Street Quant Developer Interview Experience (2026) - Offer

Jane Street quant developer loop: probability puzzles, a trading game round, OCaml style coding, and a mental math sprint. Four onsite rounds heavy on first pri

By Anonymous ยท 2026-01-08

Background

Jane Street was the loop I spent the most time preparing for and still walked out of every round feeling like I had been sprinting uphill. I am a software engineer with a math-heavy undergrad and two years at a mid-size systematic hedge fund where I worked on execution tooling. I applied cold through their careers page in late autumn, got a response about a week later, and the full process ran about seven weeks end to end. The target role was Quant Developer on a trading desk, which at Jane Street sits somewhere between a pure SWE and a trading-adjacent researcher. The bar is different from normal tech company loops. Probability, mental math, and first-principles reasoning count as much as coding.

Timeline

Total: about 7 weeks.

Phone Screen 1 (45 min)

The first call was with a trader and a developer together. No code editor, just a shared whiteboard. They opened with a warmup: expected number of flips of a fair coin until you see two heads in a row. I walked through the recurrence with states, got 6, and they asked me to re-derive it if the coin were biased with probability p of heads. I set up the same state machine, solved for the expected value in terms of p, and talked through the limit behavior as p approaches 0 and 1 as a sanity check.

The second question was a pricing puzzle. You have a fair 6-sided die. You roll once and can either take the value as your payoff, or reroll up to two more times. What is the value of the game, and what is your strategy? The right move is to solve it backward. With one roll left, expected value is 3.5. So on the second-to-last roll, you take anything greater than 3.5, giving an expected value around 4.25. Working backward again, on the first roll you take anything strictly greater than 4.25, so any roll of 5 or 6. Final value comes out near 4.67. They pushed on why the threshold is not simply the mean, and I talked through the option-value intuition.

Phone Screen 2 (60 min)

This one leaned engineering. The interviewer shared a tiny editor and asked me to implement a simple limit order book that supports add order, cancel order, and best bid or ask queries. I reached for a pair of sorted structures keyed by price, with a hash map from order ID to the containing node, so that cancel is constant time after the map lookup. We talked about why a balanced BST keyed on price beats a naive sorted list, and he asked me to reason about what happens when price ticks are bounded and small. I pitched a direct-indexed array of price levels with a doubly linked list per level, which is the classic production shape.

[[problem/564?company=34|Simple Order Book]] is almost exactly the shape of this question, and building it cold a few times before the loop was the single most useful prep I did.

After the coding piece we spent the last fifteen minutes on a Bayesian warmup. Two boxes, one with two white balls, one with one white and one black. You pick a box at random, draw a white ball. What is the probability the ball came from the two-white box. I wrote Bayes out cleanly and got 2/3. He asked the natural follow-up: suppose you now draw a second ball from the same box without replacement, what is the probability it is white. I conditioned on the posterior and got 2/3 as well, and we talked briefly about why the answer matches the first draw here but not in general.

Virtual Onsite (4 rounds)

Round 1: Probability and Strategy - Dice Threshold Game

Problem: You have a 20-sided die. You can roll up to 100 times. After any roll you may stop and take the current face value as your payoff, otherwise you roll again. Design a strategy to maximize expected payoff.

This is the classic optimal stopping setup and the phone screen warmup was clearly a gateway to it. I set up backward induction. With 1 roll left, expected value is 10.5. With k rolls left, the threshold is the expected value of the k-1 game, and you take any face that beats it. I worked out the first few values by hand and showed that the thresholds converge quickly. By the time you have more than a handful of rolls remaining, you only take 15 or higher, then tighten to 18 or higher near the end of the horizon.

The interviewer then flipped it. Suppose there is an adversary who can force one of your accepts to be rerolled at a cost to them. How does the strategy change. I pivoted to a game-theoretic framing, sketched a payoff matrix for a simplified 2-round version, and reasoned through the mixed-strategy equilibrium. Getting to a clean numeric answer was not the point; showing I could move between expectation algebra and game theory was.

Round 2: Market Making and Python

Problem: You are quoting a two-sided market on a single instrument. Given a stream of trades and your current inventory, design a quoting logic that manages inventory risk and adapts to volatility.

This was live coding in Python. I sketched a class with a midprice estimator, a rolling volatility estimator, and an inventory-adjusted skew. The core idea I wrote out: fair value estimate minus a skew proportional to inventory, with a half-spread that widens as volatility rises. I kept the volatility estimator as a simple exponentially weighted moving variance because anything fancier was not the point. We then talked about what happens during a regime change, and I added a circuit breaker that widens the spread sharply when realized volatility jumps above a rolling quantile.

[[problem/547?company=34|ETF Fair Value Calculator]] is in the same spirit, especially the part where you weight a basket and think about staleness of constituent prices.

Round 3: Data Structures - Order Book Plus Offsets

Problem: Design a data structure that supports insert, delete, get-by-rank, and a bulk offset operation that adds a constant to every element in a range.

I started with an order-statistics tree and walked through the insert, delete, and rank operations in O(log n). For the bulk offset, I added a lazy propagation field at each subtree root, similar to a segment tree with range updates. The interviewer pushed on what happens when offsets can overlap in ways that break the ordering invariant. I admitted the structure only works cleanly when the bulk offset is applied to a contiguous rank range, and we worked through why that is sufficient for the problem he had in mind.

[[problem/563?company=34|Data Structure with Ordering and Offsets]] is effectively this problem and I wish I had drilled it before the loop rather than after.

He followed up with a warmer: given an unsorted array, find all pairs that sum to zero. I wrote the hash-set one pass, talked about handling the zero-itself case carefully, and we moved on.

[[problem/562?company=34|Find All Pairs That Sum to Zero]] captures the warmup.

Round 4: Mental Math and Trading Intuition

Problem: A mix of arithmetic sprints, fraction-to-decimal conversions, and quick expected-value estimations, followed by a longer cointegration question.

The first twenty minutes were a verbal mental math sprint. Things like 17 times 23, 1 divided by 7 to four decimals, what is 1.05 to the 12th roughly. I survived by leaning on tricks I had drilled: difference of squares for the multiplications, memorized fractions for the divisions, and the rule-of-72 variants for the compounding questions.

The back half moved to a pairs-trading scenario. Two stocks with historically high correlation have diverged over the last day. Walk me through how you would decide whether to trade the spread. I sketched the process. Test for cointegration with an Engle-Granger style regression on recent history. Compute the spread, normalize by its rolling standard deviation. Set entry when the z-score crosses some threshold and exit when it mean-reverts past a smaller threshold. Size the position against a realistic estimate of transaction costs and slippage, and cap the position with a stop-loss based on cumulative drawdown. The interviewer asked the sharpest follow-up of the day: what if the cointegration relationship is real but slowly drifting. I talked through a Kalman-filter framing of the hedge ratio and rolling re-estimation.

[[problem/548?company=34|Hash Table vs BST Analysis]] came up as a tangent when he asked why I had used an order-statistics tree in the earlier round instead of a hash-based structure, and I walked through the tradeoff around ordered access.

Result

Offer call came thirteen days after the onsite. The compensation structure is different from standard tech company packages, weighted heavily toward annual bonus rather than equity, and the sign-on was modest. I accepted after a lot of back and forth. The culture at Jane Street is real; people do spend hours on whiteboards arguing about expected values, and the bar is as high internally as it feels in the loop.

Tips

  1. Drill backward induction until it is automatic. Optimal stopping shows up in some form in almost every Jane Street loop. Practice until you can set up the recurrence, solve it, and explain why the threshold is what it is, without pausing.
  2. Build a toy order book from scratch before the onsite. Insert, cancel, query best bid or ask, and walk a price level. If you have written one under time pressure, the data structures round stops being scary.
  3. Mental math is a hireable skill at Jane Street. Unlike most firms, they actually test it. Spend ten minutes a day on multiplication tricks, fraction memorization, and rough exponentiation. Compounding drills pay off.
  4. Explain your reasoning out loud even for easy problems. The interviewers are mostly evaluating how you think, not whether you land the exact number. A clean setup and a wrong arithmetic answer beats a lucky guess with no scaffolding.
  5. Have one real trading story ready. Not a markets opinion. A specific thing you have built, studied, or debugged near real market data. The behavioral passes went much better once I had a concrete anecdote to anchor.
  6. Be comfortable saying you do not know. When pushed past your depth, the right move is to say so and then start building toward an answer from first principles. They reward honesty plus reasoning over handwaves.