Jane Street Onsite Interview: Every Round, What It Tests

You passed the phone screen. Jane Street flew you out. You're heading to one of their offices (New York, London, or Hong Kong) to compete for a spot at a firm where the acceptance rate makes FAANG look like a participation trophy. The onsite is a full day. Here's every round, what it actually tests, and how to avoid discovering this stuff mid-interview.

What You're Walking Into

Jane Street hires a tiny fraction of the engineers who apply. The onsite is the final gate, and it's nothing like a standard FAANG loop. No behavioral marathon. No 45-minute LeetCode grind. No system design whiteboard where you draw boxes, label them "database," and feel confident about your life choices.

The onsite is a full-day collaborative coding session. Jane Street says so themselves on their interviewing page: final-round interviews are "mostly, if not exclusively, focused on collaborating on a series of coding problems." That's the whole frame. Keep it in mind.

The Day at a Glance

The onsite runs five to six hours across four rounds. Travel and accommodation are covered by Jane Street. You interview at one of three offices: New York, London, or Hong Kong.

Round	Duration	Format
Coding Round 1	~70 min (60 + 10 Q&A)	2 interviewers, CoderPad
Coding Round 2	~70 min	2 interviewers, CoderPad
Lunch	30 to 60 min	Informal, with engineers
Coding Round 3	~70 min	2 interviewers, CoderPad
Coding Round 4 or Project Deep Dive	~70 min	2 interviewers

Lunch is informal. It is not a break. The engineers eating with you are not your friends yet. They're curious colleagues who will form impressions. Be yourself, but be the version of yourself who doesn't complain about traffic for fifteen minutes.

Most candidates get four coding rounds. Senior candidates typically swap Round 4 for a project deep dive (more on that below). Each round has two interviewers: one leads the conversation, one takes notes. The second interviewer is there so the first can stay focused on you rather than furiously transcribing.

You use your own laptop and your preferred programming language. If you're bringing Python, bring Python. Jane Street explicitly does not want you to switch to OCaml to seem like a better fit. "Most of the software engineers we hire come in without any OCaml or even functional programming experience," they write. The OCaml anxiety is a you problem, not a them problem.

What a Coding Round Actually Looks Like

Each coding round opens with a problem that's intentionally underspecified. Your first job is to ask questions.

Jane Street avoids what they call "algorithm bingo." These are problems with a clever aha moment where you either know the trick or you don't. Instead, they give you open-ended, multi-part problems with several plausible angles. There's often no single right answer. The problem evolves across the round.

Jane Street published a worked example on their developer blog to show exactly what this looks like. The problem is about memoization. Here's the progression:

Part 1. Implement a memoized wrapper that caches the results of an expensive function using a hash table. Basic data structure usage, working code, no bugs. Every candidate who passes should finish this in the first 15-20 minutes.

Part 2. Memory is finite. Bound the cache size. Implement FIFO eviction in O(1). Most candidates who get offers complete this. It requires a queue paired with the hash table and careful reasoning about when to evict.

Part 3. FIFO isn't the best eviction policy. Switch to LRU. Most candidates start this but don't finish, and that's fine. The discussion around trade-offs matters as much as the implementation. (If you want to study LRU before the interview, here's a full breakdown.)

That's the arc: accessible entry point, escalating complexity, never fully resolved. The interviewer is active throughout. They'll ask questions, offer nudges if you're stuck, and redirect if you're heading somewhere that won't work.

Other problems candidates have reported: implementing a Connect Four game state class, designing a Tetris game, building a video player API, tree data structures with custom hash functions. The pattern holds. You're building something functional from scratch, incrementally, with a partner.

What Each Round Actually Evaluates

Jane Street published their own rubric in four words: be nice, be clear, know your language, know what you don't know.

Each phrase has teeth.

Be nice. Collaboration is real, not performative. If the interviewer gives you a hint and you argue against it, that's logged. If you get visibly frustrated when you're stuck, that's logged. Jane Street interviewers are simulating what it would feel like to work with you every day. Turns out "do I want to sit next to this person for three years" is a real evaluation criterion.

Be clear. This doesn't mean "talk constantly." It means your thinking is legible. When you make a trade-off, say it out loud. When you're unsure about something, name it. The biggest failure mode in Jane Street interviews is candidates who write code in silence and only explain their reasoning once they're done. By then, the interviewer has nothing useful to write. A filled notebook beats a surprised one.

Know your language. You don't need to know every obscure API. But you should be fluent enough in your chosen language that you're not burning cognitive load on syntax. If you're interviewing in Python and you're not sure how to use defaultdict, slow down and say so. Using a simpler approach cleanly beats fumbling with a "better" one.

Know what you don't know. This is the subtlest one, and the one that separates candidates who feel confident from candidates who deserve to be. Jane Street values intellectual honesty over false confidence. Declaring "this is O(n log n)" and being wrong hurts more than saying "I think this is O(n log n), let me verify." One is a mistake. The other is a lie you told yourself loudly.

The process matters more than the outcome. Jane Street's own description is direct: "The journey through the interview is a lot more important than the snapshot of the solution at the end." Not finishing Part 3 doesn't automatically get you rejected. Finishing Part 3 with no communication and a buggy Part 1 will.

One Round You Build, Not Solve (Senior Candidates)

Senior candidates typically spend one round on a technical project deep dive instead of a fourth coding problem. This round is conversational. You steer it by picking a project, but the interviewers are active: they'll probe the decisions you made, the trade-offs you accepted, and what you'd do differently.

Pick a project where you made the real technical decisions, not one where you executed someone else's design. This is the trap. "We built a distributed queue and I contributed to the consumer side" is a different answer than "I chose the data model, designed the API, and argued we shouldn't use Kafka yet." The interview tests whether you can reconstruct your own reasoning under pressure.

Don't over-rehearse a script. The conversation will go somewhere you didn't expect. The goal is to demonstrate you understand the system deeply enough to answer questions you haven't practiced.

What They Actually Don't Test

Jane Street does not ask software engineers to do mental math. No probability puzzles. No logic brainteasers. No "how many golf balls fit in a 747." Those appear in trading and quant research interviews, not SWE. They don't expect you to know OCaml. They don't ask questions about finance or markets.

SWE interviews at Jane Street are about programming. Full stop.

How to Actually Prepare

The problem types cluster around a handful of areas. Study these with depth, not breadth.

Data structures: Hash maps, trees, queues, doubly linked lists. Not just conceptually. You should be able to implement them from scratch with correct APIs.
Memoization and caching: The Memo example is a real past question. Understand LRU, FIFO, LFU trade-offs.
Recursive structures: Tree traversal, building parsers, working with recursive type definitions.
OOP: Designing classes with clean interfaces. Connect Four, Tetris, and video players are all object-oriented problems at their core.

Practice building functional things from scratch in your interview language. Not solving a problem by calling sorted(). Building the mechanism. You won't have access to external libraries for the interesting parts.

Practice clarifying questions. Asking the right clarifying questions is scored as its own skill. When you see an underspecified problem, your first instinct should be to write down what you don't know, not to start coding.

Practice communicating while you code. This is the thing that kills candidates who are technically strong. If you normally code in silence and explain afterward, that habit will hurt you here. Narrating your process while maintaining code quality takes reps to build. A voice-based mock interview on SpaceComplexity is a practical way to get those reps before the real thing, because narrating your reasoning out loud while solving a problem is genuinely hard until you've done it twenty times.

How to Lose an Offer You Already Had

Starting to code without clarifying. The problems are underspecified on purpose. Diving in without questions makes it look like you don't know how to scope a problem. It's also a fast way to build something correct for the wrong requirements.

Going silent when stuck. Silence gives the interviewer nothing to write. Say what you're thinking even if it's "I'm not sure. Let me try a different approach." Interviewers offer hints when they see a useful path. They can only do that if they know where you are.

Refusing hints. Some candidates hear a hint as criticism and push back or ignore it. That's exactly backwards. Jane Street interviewers are grading your coachability alongside your coding. Taking a hint well is a signal. Arguing against it is a louder one.

Optimizing prematurely. Part 1 of a problem is usually solvable with simple, clear code. Candidates who skip to a fancy solution before getting the basics right end up with something partially correct and hard to reason about. Start clean, then get clever.

Treating the Q&A as filler. The ten minutes of questions at the end of each round and the project deep dive round are not formalities. They are scored. Questions you ask reveal how you think about engineering. "What's your biggest technical challenge right now?" gets you more signal than "What's the team culture like?"

After You Walk Out

Jane Street usually gives feedback within one week of the onsite. They say so explicitly, and it's consistent with candidate reports. If you haven't heard within ten business days, following up is appropriate.

The hiring process is centralized. You don't interview for a specific team. If you pass, you get matched to an available team based on your interests and their needs. The offer conversation happens after the match.