Jane Street Coding Interview Questions: Probability, Markets & OCaml

Most people search for "Jane Street coding interview questions" expecting a list of algorithm problems. That expectation is the trap. Jane Street is a quantitative trading firm, and the interview reflects what the business actually does: price uncertainty, update on new information, and reason carefully in a language that makes mistakes hard to hide. Candidates typically describe loops full of probability, expected value, mental arithmetic, estimation, and live trading games - with far less weight on the LeetCode grind that dominates big-tech prep.

That does not mean code is irrelevant. Software engineering candidates do write and reason about programs. But the code you write is judged on modelling and correctness, not on whether you recalled the right template. This guide describes the types of problems and the skills behind them rather than inventing specific prompts, because formats rotate, accounts age quickly, and pattern fluency is the only thing that transfers. Processes also change - confirm the shape of your own loop with your recruiter.

Why LeetCode is the wrong prep here

LeetCode preparation optimises for a specific skill: recognising a known problem shape fast and reproducing a known solution cleanly. That is genuinely valuable at product companies, where the interview is a proxy for writing correct production code under time pressure.

Jane Street's interview is optimising for something different - judgement under uncertainty. The questions often have no single lookup-able answer. You are being watched for how you build a model from nothing, which assumptions you flag, how you react when the interviewer tells you something that contradicts your estimate, and whether you can hold a number and a confidence interval in your head at the same time.

A reasonable floor still exists on the engineering side. You should be able to write clean, correct code in your language of choice and reason about basic complexity. If you are starting from zero there, our LeetCode patterns guide gets you to that floor quickly - then stop and move on to the material below.

The shape of the loop

Candidates typically describe a process along these lines. Stage names, ordering, and the number of rounds vary by role, office, and year, so treat this as a map rather than a schedule.

Stage	What candidates commonly describe	What it is probing
Online assessment	Timed quantitative and/or programming test, sometimes including a mental-math or estimation component	Raw speed and numerical fluency
Phone / first round	Conversational problem solving - probability puzzles, or a coding discussion for engineering roles	Can you think out loud coherently
Technical rounds	Deeper probability and EV, combinatorics, sometimes a programming exercise or code reading	Modelling quality and rigour
Final / on-site	Multiple interviewers, interactive trading and estimation games, more open-ended discussion	Judgement, risk sense, fit

The consistent thread reported across stages is interactivity. These are conversations, not submissions. Silence while you think is far more costly here than a wrong first guess that you then correct out loud.

Probability and expected value: the real core

If you prepare one thing, prepare this. You need first-principles probability that you can deploy in seconds, not graduate measure theory. The working set:

• Expected value and linearity. Linearity of expectation is the single highest-leverage tool in this interview - it lets you decompose horrifying-looking problems into a sum of trivial indicator variables without worrying about dependence.
• Conditional probability and Bayes. Updating a belief when the interviewer hands you evidence is the whole job. Practise until the update feels mechanical.
• Symmetry arguments. Many problems collapse to one line if you spot the symmetry. Train yourself to ask "is there a reason these outcomes are interchangeable?" before computing.
• States, recursion, and random walks. Set up E[state] equations and solve the system. Gambler's-ruin-flavoured problems, absorbing states, and expected hitting times recur constantly in this genre.
• Variance and independence. Not just the mean - how confident are you, and what would change that?
• Combinatorics. Counting arrangements, inclusion-exclusion, and the difference between ordered and unordered selection, done quickly and without error.

Here is the shape of a state-equation setup, written as code purely to make the reasoning explicit - the point is the recurrence, not the implementation.

# Expected number of fair-coin flips to first see two heads in a row.
# States: 0 = no trailing head, 1 = one trailing head.
# E0 = 1 + 0.5*E1 + 0.5*E0
# E1 = 1 + 0.5*0  + 0.5*E0
# Solve: E0 = 6, E1 = 4  ->  answer 6 flips.

def expected_flips_to_hh():
    # E0 = 2 + E1 ; substitute E1 = 1 + 0.5*E0
    # E0 = 2 + 1 + 0.5*E0  ->  0.5*E0 = 3  ->  E0 = 6
    return 6

A strong answer states the state space first, writes the equations, solves, and then sanity-checks: six is bigger than the four you would need for a single head-tail pair, which is the right direction. That final sanity check is scored.

Market-making games: what they are actually measuring

The distinctive Jane Street round is the interactive trading game. The interviewer asks you to make a market on some uncertain quantity - you quote a bid and an ask - and then trades against you, drip-feeding information as you go. The mechanics vary; the skills being measured are consistent:

• Can you produce a number at all? Refusing to quote because you lack information is the failure mode. You will never have enough information. Quote, then widen your spread to reflect how uncertain you are.
• Does your spread encode your uncertainty? A tight spread on a quantity you barely understand is overconfidence; an absurdly wide one is a refusal in disguise. The spread is your stated confidence interval.
• Do you update when traded against? If the interviewer keeps lifting your offer, that is information - someone is happy to buy at your price. Candidates who never move their quote are signalling that they do not process adverse selection.
• Do you track your position? After several trades you own something. Knowing what you are long or short, and what your profit and loss looks like under different outcomes, is part of the exercise.
• Do you stay composed when wrong? Being shown you mispriced something and calmly re-pricing is a pass. Getting flustered, or defending a number you no longer believe, is not.

Practise this with a friend on anything numeric: the number of windows in a building, the length of a coastline, the population of a mid-sized city. Quote, get traded against, update. The domain does not matter; the loop does.

Estimation and mental math

Fermi estimation shows up throughout the loop, and it is trainable in a way probability theory is not. The method is always the same: decompose the unknown into factors you can bound, estimate each to within an order of magnitude, multiply, then state your confidence.

• Decompose out loud. "Total = number of X times rate per X times fraction that apply." Show the skeleton before any arithmetic.
• Anchor on things you actually know. Population figures, seconds in a year, rough unit costs. Build a small stock of these.
• Do the arithmetic in your head, but narrate it. Round aggressively and say that you are rounding.
• State the bounds. "I would be surprised if it were below X or above Y" is worth as much as the point estimate.

Separately, drill plain mental arithmetic - two-digit multiplication, percentages, fractions to decimals, powers of two, and comparing ratios without a calculator. Five focused minutes a day for two weeks measurably changes how you come across in a timed round.

The functional-programming angle

Jane Street is well known for building its systems in OCaml, and that culture leaks into how engineering candidates are evaluated. You are generally not expected to arrive knowing the language - candidates commonly report interviewing in whatever language they are strongest in - but the habits of mind pay off:

• Model the domain with types. Algebraic data types and pattern matching push you to enumerate every case. Saying "these are the only three states this value can be in" is exactly the kind of precision the interview rewards.
• Make illegal states unrepresentable. Rather than validating defensively everywhere, structure the data so bad inputs cannot be constructed.
• Prefer immutability and pure functions. Easier to reason about, easier to explain, and much easier to argue correctness for out loud.
• Recursion over loops when it clarifies. Many of these problems have naturally recursive structure that mirrors the probability recurrences above.
• Read code, not just write it. Some rounds involve reasoning about a snippet you did not write. Practise narrating what unfamiliar code does and where it would break.

A weekend of small programs in OCaml, Haskell, or F# is worth more as a thinking exercise than as syntax practice. If you have only ever written Python or Java, the shift in how you decompose a problem is the actual takeaway.

Representative problem types

Described as categories, so you prepare the pattern rather than a single prompt:

• Dice, coins, and cards. Expected values, conditional setups, and "what is the probability that..." questions with a twist that breaks the obvious symmetry.
• Random-walk and absorbing-state problems. Expected time to reach a boundary, probability of reaching one boundary before another.
• Optimal-stopping flavoured questions. You see values one at a time and must decide when to commit - what strategy maximises expected value?
• Bet-sizing and fair-value questions. Given a gamble, what would you pay for it, and how does the answer change with risk?
• Interactive market making. Quote two-sided on an uncertain quantity and manage the resulting position as information arrives.
• Fermi estimation. Size an unknown quantity from first principles with stated bounds.
• Combinatorial counting. Arrangements and selections with constraints, often where inclusion-exclusion or complementary counting is the clean route.
• Programming exercises with a modelling core. Implement or reason about a small simulation, a data transformation, or a state machine - judged on clarity and correctness rather than exotic algorithms.

What interviewers are actually scoring

• Thinking out loud. An unspoken correct answer is nearly worthless here; a narrated wrong turn that you catch yourself is valuable.
• Calibration. Knowing how sure you are, and saying so, separates strong candidates from confident guessers.
• Updating gracefully. New information should visibly move your answer. Rigidity reads as a failure to process evidence.
• Precision of assumption. Naming what you are assuming, and flagging where the answer would change if the assumption broke.
• Arithmetic you can trust. Small numerical errors compound into a bad impression even when the model was right.
• Intellectual honesty. Saying "I don't know, here is how I'd find out" is a genuine pass. Reciting a memorised solution to a problem you don't understand falls apart on the first follow-up question, and interviewers here ask follow-up questions relentlessly.

A focused two-week prep plan

1. Days 1-3: Probability foundations. Expected value, linearity, conditional probability, Bayes. Work problems on paper and say every step out loud, even alone.
2. Days 4-6: States and recursion. Random walks, expected hitting times, gambler's ruin, simple Markov chains. Write the equations before touching arithmetic.
3. Days 7-8: Combinatorics and mental math. Counting with constraints, inclusion-exclusion, plus daily arithmetic drills.
4. Days 9-10: Estimation and market making. Quote two-sided prices on ten arbitrary quantities with a friend; have them trade against you and feed you information.
5. Days 11-12: Functional-flavoured programming. Small OCaml or Haskell programs; re-solve two or three problems you already know using immutable data and pattern matching.
6. Days 13-14: Integration. Run a timed solo mock mixing probability, an estimation question, and a trading game back to back, and brush up on system design fundamentals if your target role includes an infrastructure round.

How Jane Street compares to other quant shops

If you are interviewing across several firms, the preparation overlaps but the centre of gravity differs. Jane Street is commonly described as leaning hardest into interactive trading judgement and functional-programming culture. Other quant firms weight statistical research or low-latency systems engineering more heavily - our guides to the Citadel interview and the Two Sigma interview cover those differences, and they are worth reading side by side if you are running a multi-firm process.

The practical implication: do not prepare one generic "quant loop". The probability and mental-math base transfers everywhere, but the trading games and functional emphasis are where Jane Street specifically will separate you from candidates who only ground algorithms.

FAQ

Is the Jane Street interview a LeetCode interview?

Mostly no, and this is the single biggest preparation mistake candidates make. Jane Street is a quantitative trading firm, and candidates typically describe interviews built around probability, expected value, mental arithmetic, estimation, and live trading games rather than a queue of algorithm puzzles. Software engineering candidates do write code and reason about data structures, but even there the emphasis is on clear modelling and correctness rather than memorised LeetCode patterns. Grinding two hundred algorithm problems is the wrong allocation of your prep time here.

What kind of probability do I need for Jane Street?

Fluent, fast, first-principles probability rather than graduate measure theory. Be comfortable with conditional probability and Bayes, expected value and linearity of expectation, variance, independence, symmetry arguments, states and recursion for random walks, and simple Markov chains. The bar is less about knowing exotic distributions and more about setting up a clean model quickly, computing an answer you can defend, and sanity-checking it against intuition.

What is a market-making game in a Jane Street interview?

It is an interactive exercise where the interviewer asks you to quote a two-sided price - a bid and an ask - on some uncertain quantity, then trades against you and feeds you new information. You update your estimate, widen or tighten your spread, and manage the position you have accumulated. It is testing whether you can price uncertainty, react to information that suggests you were wrong, and size risk sensibly, not whether you guess the true value on the first try.

Do I need to know OCaml to interview at Jane Street?

You are generally not required to already know OCaml - candidates commonly report being allowed to interview in a language they are comfortable with. What helps is the functional habit of mind the firm's tooling encourages: immutable data, pattern matching, algebraic data types, recursion, and making illegal states unrepresentable. Spending a weekend writing small programs in OCaml, Haskell, or F# is useful less as syntax practice and more as a way to think about modelling problems the way the team does.

How is Jane Street different from other quant firms?

Compared with quant shops that lean heavily on statistics research or low-latency C++ systems, Jane Street is commonly described as leaning further toward interactive trading judgement and functional programming. Expect more live games, estimation, and thinking out loud under uncertainty, and relatively less emphasis on rote algorithm speed. Processes evolve, so confirm the specific format of your loop with your recruiter rather than assuming any public account still matches.