Jane Street Phone Screen Interview: What It Covers and How to Pass It

Jane Street doesn't run the same interview as every other tech company. The Jane Street phone screen interview is where that becomes obvious. No LeetCode pattern-matching, no leaderboard tactics, no memorized solutions. What they're actually testing is whether you can think, communicate, and write real code under light pressure with another engineer watching. The process rewards candidates who narrate their thinking, not just candidates who land the right answer.

If you've prepped for Google or Meta and assumed this would feel similar: you're in for a surprise. Put the sliding window away. This is different.

Where the Phone Screen Fits

The full process for a software engineering role:

Stage	Format	Length
Application	Resume review	N/A
Recruiter call	Phone / video	30 min
Online assessment	Async coding (some roles)	60 min
Technical phone screen	Live Zoom coding	45 to 60 min
Onsite (Super-Day)	In-person, multiple rounds	Full day

The phone screen is the first live technical gate. Pass it and you're invited to the Super-Day, a full day of in-person coding rounds at one of their offices (New York, London, Amsterdam, or Hong Kong). If you make it that far, the trip is worth it regardless of outcome. Probably.

Most candidates go through one technical phone screen. Some see two, particularly for senior roles or when the first call leaves open questions. You'll typically hear back within a week at each stage. The whole process averages about four weeks from first contact to offer, though they can move faster if you have competing offers and say so.

The Recruiter Call: Non-Technical

The first call is with a recruiter. About 30 minutes, entirely non-technical. They want to know why you're interested in Jane Street specifically, what you're looking for next, and whether your background is a reasonable fit.

Be honest about what you've actually built. Jane Street's engineering team writes serious systems software and cares deeply about correctness. Generic answers about "impact" don't land well here. Have a real answer for "why Jane Street" ready, because it will come up and a shrug won't do.

This call won't determine whether you're technically strong enough. It's a fit screen and logistics conversation.

Online Assessment: Not Always Required

For some cohorts, especially new graduates and interns, there's a 60-minute async coding assessment before any live interviews. The format varies but tends toward algorithmic or logic-based problems, occasionally with a functional flavor given Jane Street's internal use of OCaml.

If you're applying as an experienced engineer, you may skip it entirely and go straight to the phone screen. Confirm the stages with your recruiter early before spending time prepping for a round that may not be in your process. This sounds obvious. People routinely don't ask anyway.

The Technical Phone Screen Interview

This is a 45 to 60 minute live coding session over Zoom with a shared editor. You get one problem, but it almost always has two or three parts, each building on the previous. Part one establishes a working solution. Part two introduces a new constraint or harder requirement that stress-tests your design choices from part one.

The feel is closer to pair programming than an adversarial exam. Nobody is sitting behind a one-way mirror with a clipboard. Your interviewer will actually talk to you, engage with your thinking, and push back when you're heading somewhere unproductive. If you go quiet, they'll probe. This is deliberate: they want to see how you think with someone else in the room, not how quickly you can recall a memorized algorithm.

Write real, compilable code. They're explicit about this. Pseudocode doesn't tell them what they need to know. Use whatever language you know best, write it like production code, and mentally trace through it before declaring done.

What They're Actually Evaluating

Jane Street publishes their criteria clearly on their official prep page. Four things:

Communication. Can you explain your reasoning while coding? Do you ask the right clarifying questions up front?
Problem decomposition. Can you break a complex problem into manageable pieces without being told how?
Code quality. Is your code clean, correct, and thoughtful? Not clever-for-its-own-sake, just well-organized.
Complexity awareness. Do you know the time and space cost of what you're building, and can you reason about tradeoffs?

Candidates who code silently and produce a correct solution often score worse than candidates who think out loud and catch their own mistakes. Read that slowly. Silent and correct loses to verbal and slightly wrong. This is not a typo. Silence costs real points. A wrong answer with good process costs less than a right answer with no narration.

Your LeetCode practice didn't train you for this. LeetCode has no idea whether you talked through your approach.

See the technical interview communication guide for how to build this habit before the call.

What the Problems Look Like

Jane Street writes their own questions. No LeetCode bank. No "I've seen this one before" moments. Here's what shows up:

Recursion-heavy problems. Tree operations, list processing, generating subsets or combinations. They want clean recursive thinking, solid base cases, and awareness of when memoization applies.

Problems that extend. Part one asks you to implement a function. Part two asks you to make it lazy, memoize it, or handle streaming input. The problem grows. Your design choices in part one determine how hard part two gets. This is a good reason to resist the urge to be clever in part one.

State machine problems. Simulating systems with well-defined state transitions shows up regularly. Careful abstraction matters more than fast typing.

Nothing that requires trick knowledge. Worth pausing on this. Jane Street is the company that hires people who calculate expected values for fun and moves markets with probabilistic models. For the software engineering phone screen, none of that math appears. No probability puzzles, no mental math, no competition math. Those are for trading and research roles. You will not be asked to compute expected values. Just write good code.

A concrete example of the kind of problem they've discussed publicly: write a function that takes an expensive function f: int -> int and returns a new function g with the same signature that caches results so f is only called once per unique input. Then extend it to handle thread safety, or generalize the key type, or handle expiring cache entries. That's the shape. Start concrete, layer complexity.

OCaml: Use It or Don't?

Jane Street is famous for using OCaml. They write essentially all of their systems in it. This causes candidates to panic-learn OCaml before the interview.

The logic is understandable: Jane Street equals OCaml, OCaml is on the job posting, better spend the next two weeks learning pattern matching and sum types. Right?

Wrong. Jane Street explicitly says not to use OCaml just to impress them. No bonus points. If you try it under pressure and struggle with the syntax, you've made everything harder while demonstrating nothing. You've spent your prep time studying the wrong material for a test you could have passed with tools you already had.

Use Python, Java, C++, TypeScript, Go, or whatever you're genuinely fluent in. They can evaluate your reasoning in any of these. Write idiomatic code in the language you know, not awkward code in a language you learned last week because of a blog post.

That said, if you already know OCaml, certain recursive or functional patterns are more natural to express. That's a bonus, not a requirement.

How to Prep

Practice coding out loud. This is the skill most engineers underinvest in. Solving problems silently at home trains you to solve problems silently. That's a different skill. Pair up with a friend, use a mock interview service, or at minimum talk yourself through every problem you work on. Jane Street offers a free mock interview on their website with two engineers demonstrating the format and giving real-time feedback.

Study recursion deeply. Not "know how recursion works," but actually practice writing clean recursive solutions to tree problems, list problems, and combinatorial problems. Know when memoization applies. Know the space cost of your call stack. The recursion time complexity guide covers the analysis you'll need.

Ask clarifying questions before you code. Underspecified problems are intentional. Jane Street wants to see whether you identify ambiguity or bulldoze through it. Ask what the input constraints are. Ask whether the input is guaranteed valid. Ask whether to optimize for time or space. See the clarifying questions guide for a practical framework.

Know your complexity. State the time and space cost of every solution you write, without being asked. If you know a better approach but didn't implement it, say so. Interviewers probe this directly.

If you get stuck, say so. Jane Street interviewers are not looking for candidates who never struggle. Narrate your reasoning, name the obstacle, ask whether a hint would help. Interviewers who offer hints are probing coachability, not being charitable. See the coding interview hints guide.

SpaceComplexity offers voice-based mock interviews that simulate exactly this dynamic: a live problem, real-time narration scoring, and feedback on communication alongside code. Building the habit of thinking out loud before the Jane Street call is the single highest-ROI thing you can do.

Common Mistakes

Going silent. The most common reason candidates fail the phone screen despite having the right solution in their head. You can solve the problem perfectly in your mind and still bomb the interview if nobody can see it happening. Narrate everything.

Trying OCaml. Already covered. Twice now. That's how much this mistake happens.

Skipping edge cases. Walk through a small example after you code. Catch your own bugs before being asked. Part of code quality is self-verification.

Over-engineering part one. If part one is simple, solve it simply. Elaborate abstractions for a straightforward problem leave you less time and flexibility for part two, and they signal that you might be more interested in looking clever than solving the actual problem.

Treating the interview as a performance. You're working with the interviewer, not performing for them. Jane Street's blog post on what the interview is like uses the word "collaborative" repeatedly. They mean it. The moment you start trying to impress rather than communicate, you've lost the thread.