Optiver vs Jane Street Software Engineer Interviews: Two Very Different Tests
- The Optiver 80 in 8 is 80 arithmetic questions in 8 minutes with a -2 penalty for wrong answers; start practicing at least 6 weeks out.
- Optiver tests speed and precision under pressure; Jane Street tests reasoning quality and collaborative problem decomposition.
- Jane Street's coding rounds evolve as the conversation goes: implement, extend, then discuss design changes under new constraints.
- Expect probability questions at Jane Street even for pure SWE roles; read their probability guide and practice narrating expected value reasoning out loud.
- Optiver's system design round is domain-specific: low-latency pipelines, lock-free data structures, and cache hierarchy tradeoffs.
- Both firms are worth applying to simultaneously if your DSA and probability foundations are solid; the 80 in 8 is the only hard early divergence.
- Jane Street's collaborative format is harder to prepare for than the content; voice-based mock interviews that force you to narrate while coding build exactly that muscle.
Two of the most technically demanding firms in the world. Both market makers. Both obsessed with fast, precise thinking. Both the kind of place where the intern is solving problems you'd see in a grad-level textbook. And their interviews feel almost nothing alike.
Training for the wrong one is a real mistake. If you're applying to both, the surface similarities will fool you. This Optiver vs Jane Street interview guide maps each process end to end and tells you how to prepare without duplicating effort.
Both Firms Make Markets. Their Interviews Don't.
Optiver and Jane Street sit on exchanges and continuously quote bid and ask prices, capturing the spread while managing the risk of the inventory they accumulate. The job is making fast, accurate decisions under uncertainty, at scale, with real money on the line.
That philosophy bleeds directly into how they hire. Optiver treats speed and precision as first-class signals. Jane Street treats reasoning quality as the product. One test asks: can you be fast and accurate under pressure? The other asks: can you think clearly and deeply about genuinely hard problems?
Neither is easier. They're just testing different things. Training for the wrong one is essentially showing up to a sprint in marathon shoes.
The Optiver Interview Process: Speed First, Then Depth
The 80 in 8 Filter
Before you write a line of code, Optiver routes every candidate through one of the most notorious assessments in quantitative finance: 80 arithmetic questions in 8 minutes. No calculator. No scratch paper on the digital version.
The scoring is asymmetric. Correct answer: +1 point. Wrong answer: -2 points. Minimum to advance: 56. Competitive score: 70 or above.
That penalty for wrong answers is doing a lot of work. Three wrong guesses erase six correct answers. Optiver is deliberately testing whether you know what you don't know. Skipping costs nothing. Guessing costs you three points net. The questions are not hard in the abstract. They're hard because the clock makes accuracy collapse.
Problems include things like converting 3/153 to a decimal, or computing 1/8 × 560, or dividing decimals in your head while the timer ticks. Most candidates who fail aren't incapable of answering the questions. They're too slow, or they guess wrong and dig a hole they can't escape.
Preparation is mechanical. Use Zetamac or a dedicated Optiver simulator. Practice daily for four to six weeks. Start at a comfortable pace, ratchet up the speed, and track your accuracy separately from your score. Do not skip this. Candidates who treat the 80 in 8 as a box to check at the last minute routinely fail a filter they could have passed with consistent preparation.
The 80 in 8 is Optiver's way of verifying this chart is accurate for their candidate pool.
The Online Programming Assessment and Technology Screen
Two coding problems, two hours. One tests algorithmic thinking, one leans toward object-oriented design or a systems-flavored problem. Expect LeetCode medium difficulty. Optiver's problems often carry a quantitative context: process a stream of trade events, implement a data structure that supports efficient bid/ask lookup, rank orders by price and time priority.
After that, 20 multiple-choice computer science questions in 20 minutes. OS fundamentals, networking basics, memory management, concurrency primitives. Not designed to trick you. Designed to confirm you know how systems actually work below your framework of choice.
The Onsite Loop
Four to five rounds:
| Round | What They're Testing |
|---|---|
| Coding (x2-3) | Standard DSA, live, with complexity follow-ups and load analysis |
| System design | Low-latency architecture, market data pipelines, concurrency |
| Behavioral | Project depth, what you chose to optimize and why |
| Market simulation (some tracks) | Real-time decision-making under uncertainty |
The system design round is where Optiver diverges most sharply from a standard FAANG loop. Questions are domain-specific: "Design a market data feed that ingests and processes option prices in real time." You'll be expected to discuss failover strategies, cache hierarchies, lock-free data structures, and what happens to your latency when your L3 cache saturates. Low-latency programming isn't a bonus topic. It's the frame for every design conversation.
Some SWE candidates, particularly those interviewing for trading infrastructure roles, encounter a market making simulation: a card-based exercise where new information is revealed progressively and you quote bid/ask prices while updating your fair value estimate. What they watch is how you handle uncertainty. Do you freeze? Overreact? Widen your spreads when you should narrow them?
The Jane Street Interview Process: Reasoning Is the Product
Jane Street's engineering interview is covered in more depth in the Jane Street software engineer interview guide, but the comparison with Optiver is worth making explicitly.
The Phone Screen and Online Assessment
A recruiter screen followed by a technical round. The coding problems tend to be recursive or combinatorial: tree traversals, subset generation, parser-like state machines. The bar is a working implementation. Not pseudocode. Not "here's my approach." Something that actually runs correctly.
Jane Street's official interview prep page is unusually candid and worth reading before you apply. Their blog post on what an engineering interview looks like is even more useful. Both are primary sources.
The Onsite Super-Day
Five to six hours, five rounds. This is where Jane Street's process diverges completely from Optiver.
Coding rounds at Jane Street feel more like collaborative problem-solving sessions than assessments. The interviewer is genuinely engaged. When you're stuck, they nudge you. When you have an insight, they follow the thread. The goal is not to see whether you can recall BFS. It's to see how you decompose unfamiliar problems in real time.
A common structure: implement a basic version of something, then extend it, then discuss how the design changes if a new constraint is added. The problem evolves as the conversation evolves. Candidates who treat it like a LeetCode timer situation tend to miss the collaborative frame entirely and wonder why they "got everything right" but didn't advance.
Engaging with the interviewer's logic instead of just reciting a memorized answer. Jane Street loves this energy.
The Probability and Expected Value Layer
Even for pure engineering roles, expect at least one probability question. Examples:
- "You roll a die and can reroll once. What's your optimal strategy and expected payout?"
- "What is the expected value of a d6 given the outcome is at least 4?"
- "How would you price a bet that pays $10 if the S&P 500 closes up today?"
Jane Street publishes a Probability and Markets guide that is genuinely useful and not a PR document. They want candidates who have thought carefully about expected value. Reading it before your interview is not optional.
Behavioral
Jane Street's behavioral questions probe intellectual honesty. "Tell me about a time you changed your mind on something technical." "Describe a design decision you made that you later regretted." They want evidence that you update on new information and can articulate why. Candidates who project false certainty tend to get tripped up here, which is a bit ironic given how much the rest of the process rewards confidence.
What Each Firm Is Actually Measuring
| Dimension | Optiver | Jane Street |
|---|---|---|
| Math bar | Arithmetic speed and accuracy (80 in 8) | Probability reasoning, expected value |
| Coding style | Standard DSA with performance awareness | Recursive, structural, functional decomposition |
| Systems emphasis | High (low-latency, concurrency, memory) | Lower for SWE roles |
| Domain knowledge | Market making mechanics help significantly | Helpful but not required |
| Interview feel | Structured, time-boxed, parallel tracks | Conversational, collaborative, evolving |
| Primary language | C++, Python | Any language (OCaml internally, not required) |
| Differentiator | Speed and precision under pressure | Reasoning quality under ambiguity |
How to Prepare for Each
Preparing for Optiver
Start with the 80 in 8, and start early. Six weeks of daily arithmetic practice is a realistic timeline for most candidates who aren't already doing mental math regularly. Zetamac is the standard tool. Track your score at the end of each session and aim for consistency above 70 before the real assessment.
For coding, standard LeetCode medium preparation works, but add a performance lens. Know why a hash map lookup costs more than an array access in practice. Know what false sharing is and when it matters. Understand lock-free programming at a conceptual level.
If you can explain why an array traversal is faster than a linked list traversal not just asymptotically but physically, because of cache line behavior and the prefetcher, you're speaking Optiver's language. Candidates who understand computer architecture alongside their algorithms stand out in the system design round.
Read Optiver's interview tips for software engineers. They're unusually specific about what they care about.
For the market simulation, study basic market making mechanics. Understand bid-ask spread, position limits, and how new information should change your fair value estimate. You don't need quant finance depth. You need enough fluency to not look confused when the simulation starts.
Preparing for Jane Street
Build your probability foundation first. Work through basic expected value problems, Bayes' theorem, and conditional probability until you can solve clean versions quickly and narrate your reasoning while solving. Jane Street's probability guide covers the territory they care about.
For coding, focus on recursive and structural problems rather than volume. Before writing a single line, practice articulating what invariant your recursive function maintains and what the base case is. These are the questions they'll ask, and training the habit of answering them proactively changes how the interview feels.
Do not try to learn OCaml to impress them. They say this explicitly, and they mean it. Most engineers they hire come in without functional programming experience. Seriously, don't. Use the language you're most fluent in and let your reasoning carry the conversation. (If you're currently weighing "learn OCaml for two weeks" as a strategy, I'm asking you to step away from that.)
The hardest thing to prepare for at Jane Street isn't the content. It's the conversational format. If you've only practiced LeetCode in silence, you'll find the collaborative interview harder than the technical material warrants. Practice thinking out loud with feedback. SpaceComplexity runs voice-based mock interviews where you're required to narrate your reasoning continuously, not just produce code, which is exactly the muscle Jane Street is testing.
The competitive programming vs coding interviews breakdown is worth reading for context on why math-heavy problem-solving skills transfer differently than raw LeetCode volume.
Which to Target First
If your strengths are raw quantitative speed and systems-level programming, Optiver is the more natural entry point. The filter is early and brutal, but once you're through it the process is structured and predictable.
If your strengths are mathematical depth, recursive thinking, and collaborative problem-solving, Jane Street's process rewards you more directly. The bar for advancing is reasoning quality, not arithmetic speed.
Both are worth applying to simultaneously. The preparation overlaps significantly: strong DSA fundamentals, probability fluency, and the ability to explain your thinking clearly.
Most candidates who are competitive at one are worth interviewing at the other. The exception is the 80 in 8. If your arithmetic is slow, Optiver will screen you out before you reach the rounds where your reasoning matters. Fix that first.