[cover: cover-source.svg]

Optiver Onsite: You Thought It Was LeetCode, But It's Cache Lines

The Optiver onsite is not a FAANG loop with a snappier dress code. It is a half-day at one of the world's fastest trading firms, run by people who genuinely care whether your code fits in a cache line. Four rounds, each testing something the previous one did not. Show up expecting a LeetCode marathon and you will be surprised in ways that do not help your offer chances.

How You Even Get Here

Before the onsite, you cleared two gates: the online assessment and a phone screen.

The OA has four parts: a two-hour coding section with one quantitative and one object-oriented design problem, a 20-question technology multiple-choice on networking, OS, and system design, the Zap-N cognitive battery (nine mini-games testing reflexes and working memory), and the Zap-Q personality assessment. Optiver does not allow Python on the coding portion. C++, Java, C#, C, and Ruby only. Yes, really. Put down the list comprehension.

The phone screen is an hour. You walk through your OA solutions, do a fresh live coding problem, and sketch a system design. Think Uber or Zoom at a high level, with questions about TCP vs UDP. Pass that and you are in for the superday.

What the Day Actually Looks Like

The superday runs four consecutive rounds. They do not get easier as the day goes on.

Round	Name	Length	Core test
1	HR + SWE Chat	~45 min	Fit, motivation, ownership
2	Technology Fundamentals	~45 min	CS depth, systems knowledge
3	System Design and Architecture	~60 min	Scalability, low-latency trade-offs
4	Project Deep Dive	~60 min	Engineering judgment, live demonstration

Round 1: They're Deciding If They Like You (and Whether You Know Why You're There)

This round is conversational, but it is not soft. A recruiter and a software engineer sit with you together, and the engineer is listening carefully to how you describe your work.

This round tests whether you can explain what you have actually built, and whether your reasons for choosing Optiver are real. "I like trading" does not clear the bar. "I have been following market making mechanics since I came across Optiver's Chicago conference talks and I want to build systems where microseconds matter" is getting closer.

Common questions:

Tell me about yourself
Why Optiver specifically, and not a hedge fund or a tech firm
What kind of environment do you do your best work in
Tell me about a time you disagreed with your team's technical direction

Prepare a tight two-minute version of your career arc. Know Optiver's business: they are a market maker, profiting by providing liquidity and managing inventory risk, not by taking directional bets. That distinction matters when someone asks why you chose them over a quant fund.

Use STAR for behavioral questions, but keep Situation and Task short. The Action is what the interviewer is actually evaluating.

Round 2: No LeetCode. Just Questions About Things You Thought You'd Never Need Again.

No live coding. No whiteboarding. An engineer asks questions across a wide range of CS topics and drills down wherever they find a gap.

Topics that come up:

Language mechanics: compiled vs interpreted, static vs dynamic typing, how a C++ binary is produced from source
Memory: heap vs stack, how malloc works, what a cache miss costs, NUMA topology basics
Concurrency: mutex vs spinlock, lock-free data structures, memory ordering, the C++ memory model
Networking: TCP vs UDP, what happens during connection establishment, why market data feeds often prefer UDP
OS basics: how a context switch works, what a thread costs versus a process, what kernel bypass means

The gap Optiver is probing is between "knows the concept" and "knows why it matters in production." If you say "mutex for thread safety," be ready to explain when a spinlock beats it. "Spinlocks win when the critical section is short and contention is low, so the thread avoids a context switch" is a concrete answer. "Spinlocks are faster sometimes" is not a concrete answer.

The 20-question technology MCQ from the OA previews exactly what this round covers. If that section made you uncomfortable, that discomfort was a gift. Spend real time on systems fundamentals before the superday.

A developer confidently saying they studied trees and graphs, then being asked to explain cache coherence protocols

The Optiver Technology Fundamentals round, summarized.

Round 3: The Design Round Where Offers Go to Die

This is the hardest round for most candidates, and where offers are most often lost.

The prompt will be some variant of a low-latency, high-throughput system: a real-time order management system, a market data distribution pipeline, a risk calculation engine that needs to evaluate positions in under a millisecond. You design it end to end, then defend every choice.

What gets evaluated:

Scoping before designing. Clarifying questions about throughput targets, acceptable latency, consistency requirements, and failure modes are expected. Jumping straight to architecture is a red flag.
Performance reasoning. "Use Kafka" is fine if you can explain what Kafka's commit log does to tail latency, and when you would swap it for a single-producer single-consumer ring buffer in shared memory.
Back-of-the-envelope math. "If we have 10,000 messages per second at 200 bytes each, that is 2 MB/s, well within a single NIC at 10 Gbps" is the kind of quantitative instinct that impresses here.
Failure modes without prompting. Network partition, hot shard, slow consumer, disk full. Bring these up yourself before anyone asks.

The design Optiver wants is not the most sophisticated one. It is the one that meets the stated requirements with the fewest moving parts.

Prepare by designing at least three systems from scratch with a latency lens, not just a scalability one. The tradeoffs in low-latency systems (kernel bypass, busy-waiting, co-location, CPU pinning) are different from the tradeoffs in web-scale systems. Know both registers and be able to explain which one applies to the problem in front of you.

For general system design structure, system design interview tips covers how to run a 45-minute session without losing the thread.

Round 4: Bring Your Best Project and Watch It Get Disassembled

This is the round candidates most often underestimate.

You pick a project you have built. You explain it. You demonstrate it if you can. Then the interviewer takes apart every assumption you made.

An engineer proudly presenting their project while the interviewer asks increasingly pointed questions about every architectural decision

"I'm proud of this." "Cool. What breaks first at 10x load?"

The interviewer is not impressed by what you built. They are impressed by how clearly you understand every decision you made while building it. Those are very different things.

Be ready for:

Why did you pick this data structure over the obvious alternative?
What was the biggest bottleneck you found in production, or in testing under load?
If you rebuilt it tomorrow, what would change?
Walk me through how you diagnosed the hardest bug this system produced.
What would break first if traffic increased 10x?

Pick a project where you made genuinely hard decisions, not one where you followed a tutorial. If your best project was an academic assignment that worked fine on a sample dataset, build something with real constraints before the superday.

Bring something you can actually run. A working CLI demo is worth more than a polished slide deck. Interviewers can ask questions about a running system that they cannot ask about a diagram.

What Optiver Is Actually Evaluating Across All Four Rounds

Reading each round in isolation misses the thread running through the whole day.

Optiver is a market maker. Systems fail in microseconds. The firm values engineers who default to precision: precise complexity analysis, precise language about tradeoffs, precise debugging processes. Every round is testing whether you are precise under pressure, which is a different skill than being correct with unlimited time.

There is a behavioral subtext across all four rounds: can you push back when you disagree? Optiver is collaborative but opinionated. If an interviewer asks why you used a mutex and you think a spinlock was the right call, defend it. "I can see both sides" when you have a real opinion reads as hedging, and hedging reads as uncertainty about your own work.

Optiver does not use trick problems. The expectation is not that you memorize solutions. It is that you engage with every problem as an engineering problem, explaining what you are thinking and why, in real time. That verbal reasoning component is something the Optiver vs Jane Street comparison covers in more depth if you are deciding between the two.

How to Actually Prepare

Work backwards from the four rounds.

For the HR chat, know Optiver's business model well enough to answer "why here and not FAANG" with something specific. Optiver's official interview tips recommend STAR and out-loud practice. Both are genuinely useful.

For Technology Fundamentals, review CS fundamentals you have not touched since a systems programming course: memory model, concurrency primitives, the networking stack. A week with "Computer Systems: A Programmer's Perspective" and the cppreference pages on atomics will go further than grinding more algorithm problems.

For System Design, practice latency-sensitive systems. Know what a ring buffer is and when it beats a queue. Know what kernel bypass means and when the operational complexity is worth it. Know when vertical scaling is the correct answer at trading-system scale.

For the Project Deep Dive, pick your project now. Write out every significant decision, every alternative you considered, and what you would change today. Do a dry run where someone unfamiliar with the system asks adversarial questions for 30 minutes. If that dry run is uncomfortable, good. The actual round will be more comfortable by comparison.

Optiver's format demands verbal reasoning under pressure across all four rounds. SpaceComplexity runs timed voice-based mock interviews with rubric feedback, which matches the on-your-feet communication Optiver expects better than silent LeetCode practice does.

For new grads, the full process from OA to offer typically takes three to four weeks. The superday is a half day and feedback comes back within a week. For experienced hires, system design expectations are higher and production systems you have built under real constraints carry more weight than academic projects.

For more context on how Optiver compares to other quant firms, FAANG vs quant firm interviews covers the mindset shift and the Optiver software engineer interview overview walks through the full pipeline from application to offer.

Optiver Onsite Interview: Every Round, What It Tests, and How to Prepare