# What Jane Street’s software engineer interview really tests

Source: https://www.techinterview.org/post/3233476389/jane-street-software-engineer-interview/
Updated: 2026-07-15 · techinterview.org

People prep for the wrong Jane Street interview. They see the firm's name, assume it's a trading shop, and spend weeks on mental-math drills and probability brainteasers. Then the software engineer screen opens with an interviewer sharing a coding problem and saying, in effect, "start wherever you want." The math gauntlet belongs to the trading and research loops. The developer loop is a different animal.

Jane Street says this outright: its software engineering interviews don't include mental math, math-olympiad questions, or logic puzzles. What they do include is a lot of collaborative coding, where the problem grows under you as the round goes on, and the interviewer cares more about how you think than about what you finally land on.

## The loop, and how long it takes

The process runs in two real parts. First a remote technical screen, usually about 60 minutes over Zoom, one interviewer, one coding problem in whatever language you're strongest in. If that goes well, you get a full onsite, historically in person at one of Jane Street's offices, most often New York or London, built around several coding rounds. Start to finish, candidates report roughly three to four weeks, though it stretches when scheduling an in-person day is hard.

| Stage | What happens | Rough length | What they're grading |
| --- | --- | --- | --- |
| Recruiter call | Background, role and team fit, logistics and timeline | About 30 minutes | Whether there's a match and which team fits |
| Technical phone screen | One interviewer, one coding problem in your strongest language, over Zoom | About 60 minutes | How you structure, extend, and reason about a single problem |
| Onsite | Several collaborative coding rounds, in person at a Jane Street office | Most of a day | Design sense, handling of corner cases, what you're like to work with |
| Team and offer conversations | Less technical talks about the work and your background | Varies | Communication, motivation, and team match |

Notice what's missing. There's no standalone system design round of the "design Twitter" variety. Jane Street folds design thinking into the coding rounds instead, so you'll define your own types, decide how to represent state, and pick between two reasonable approaches while you build. The design signal is real. It just doesn't get its own whiteboard hour.

## The rounds build on themselves

The format that trips people up is the layered problem. You start with something small, maybe an interval scheduler or a function that walks a tree, get it working, and then the interviewer adds a requirement. Now the intervals can overlap. Now the tree can be cyclic. Now you need removal, not just insertion. Each addition tests whether your first design was flexible or whether you painted yourself into a corner.

That is why a clean, extensible first cut beats a clever one-liner. If you hardcode assumptions to get the initial version passing fast, you pay for it three requirements later, rewriting instead of extending. Interviewers notice who reaches for the right abstraction early and who has to tear things down and start over.

## What the problems actually look like

Expect classic computer-science fundamentals in practical clothing rather than LeetCode-hard trivia. A few shapes come up again and again:

- Recursive traversal of a tree or nested structure, then a twist that breaks naive recursion

- Graph search under a constraint, like reachability with a budget or a path where some edges are blocked

- Simulating a small state machine or a game, one tick at a time

- Interval and scheduling logic: merging, allocating, detecting conflicts

- A dynamic-programming variant where the recurrence isn't obvious until you sketch it

These reward recursion and functional thinking, and they reward defining a small vocabulary of types before you write the algorithm. Corner cases carry real weight. Empty input, a single element, a cycle where you assumed a DAG, an off-by-one at a boundary. Finding those yourself, before the interviewer points at them, is one of the strongest signals you can send.

## OCaml matters less than you've heard

Jane Street is famous for running production OCaml, so candidates assume they need it. They don't. The firm states plainly that it gives no bonus for using OCaml, and it tells candidates not to reach for it just to look eager. Most of the software engineers it hires arrive with no OCaml or functional-programming background and pick it up on the job. Use Python, C++, or whatever language lets you move fastest and think clearest under mild pressure.

Where the functional flavor does show up is in the kind of thinking the problems reward. Immutable data and recursion over loops, plus modeling a problem with a well-chosen type, tend to produce cleaner solutions here than a pile of mutable flags. You can write that style in any language. If your Python leans on small helper functions and clear data types instead of a 60-line function with six booleans, you already speak the dialect.

## What the interviewer is actually grading

The line Jane Street repeats most in its own guidance is that how you get to an answer matters more than the final snapshot. They want to know what it is like to work with you on a hard problem, because that is the job. So thinking out loud is not a nicety here. It is what the interviewer is scoring. When you say "I could use a hash map for O(1) lookup but it costs memory, or keep it sorted and binary-search it, which do you care about," you are showing the exact judgment they hire for.

Silence is the real risk. A candidate who goes quiet for four minutes and emerges with correct code still scores below one who talks through a wrong first idea, catches the flaw, and fixes it out loud. Interviewers often nudge with "let's explore that further" or "what happens if the input is empty." Treat those as collaboration, not traps. Pushing back with a reason is welcome. Ignoring the hint is not.

## New grad versus experienced

The shape is similar whether you're a new grad or a senior hire, but the weighting shifts. New grads see more pure algorithmic rounds and get more slack on system-level judgment. Experienced candidates get pushed harder on design choices, on why they chose one representation over another, and sometimes on a real system they've built. Nobody skips the collaborative coding, though. There's no track that jumps straight to architecture talk.

## How to prep so the format works for you

Grinding 300 LeetCode problems alone is close to the wrong preparation, because it trains the opposite muscle: heads-down, silent, optimize-for-the-final-answer. Do fewer problems and narrate every one out loud to a friend or a rubber duck, false starts included. Practice taking a working solution and extending it when someone changes the spec on you, since that is the actual round. Get comfortable defining a type or an interface before you write any logic.

Read a little OCaml even if you'll interview in Python, not to use it but because skimming Jane Street's public blog and their Real World OCaml book shows how they represent a problem, and that representation is what the rounds reward. Know your own language cold, especially its standard containers and their costs, so you're never fumbling syntax while also trying to design.

The people who do well here usually aren't the fastest coders in the room. They're the ones you would actually want next to you when a problem gets weird and the requirements keep moving. That isn't an accident. It's the whole thing the loop was built to find.