HackTheRounds Interview Experiences
Optiver SDE New Grad Interview Experience (2026) - Stock Dividend OA & Low-Latency Market Data Design, Offer
Optiver 2026 SDE NG campus loop: 3h20 OA with stock dividend prefix sums and worst PNL tracker, HR behavioral in English, two system design rounds on lock free
By Anonymous ยท 2026-04-10
Background
Just closed out Optiver's SDE New Grad campus loop with an offer, and the structure genuinely surprised me. The hardest gate is the OA at the front, not the onsite at the back. I leaned on OS and networking fundamentals instead of grinding LeetCode, and that paid off across the HR behavioral and the two system design sessions.
Timeline
- Campus event application: mid-February
- OA invite: 2 weeks after application, 5-day window
- OA attempted: day after receiving
- HR behavioral round: 8 days after OA
- System design round one: 2 weeks after HR
- System design round two (deeper): 5 days later
- Offer: 4 business days after the final round
- Total: ~8 weeks
Process Overview
The loop runs four stages. The OA is the longest single session at around three hours twenty minutes. HR behavioral is 45 minutes of English Q and A. The system design track splits into two rounds: a project-anchored discussion, then a deeper session on high-throughput low-latency trading constraints. No traditional coding onsite if the OA goes well.
OA (3 hr 20 min)
Two coding problems plus a set of reaction mini games. The games are cognitive-screen content and I will focus this writeup on the coding half, which is where the real grading happens.
OA Problem 1: Stock Dividend Price Calculator
Problem: Implement a class that supports two operations on a stock with future dividend payments. UpdateDividend(i, A, D) sets or overwrites the dividend at index i , with amount A paid on day D . CalculateFuturePrice(F) returns the stock's future price on day F , which is the current spot price minus the total of every dividend paid on or before day F . Constraints: up to 500 dividend updates, but up to 10^5 future price queries.
The asymmetry between update count and query count shapes the whole design. My clean solution stored dividends in a map from index to (amount, day) and maintained a sorted-by-day array that rebuilt lazily. On each query, a binary search located the last dividend paid by day F , and a prefix-sum array over amounts gave the cumulative deduction in one lookup. That is O(log n) per query.
I wasted eight minutes trying to maintain the prefix sums incrementally, which got tangled because updates can overwrite existing entries and change the sort order. Lazy rebuild on the first query after any update was cleaner. Lesson: when updates are rare and queries are dense, pay the update cost in a batch, never incrementally.
OA Problem 2: Worst Trade Tracker
Problem: Process a stream of trade events and price update events for a set of financial instruments. On a TRADE event, record the instrument id, direction (buy or sell), quantity, and execution price. On a PRICE event, update the current market price for the instrument. On a QUERY event, return the trade id currently showing the largest negative PNL for a given instrument. If no trade is currently at a loss, output the string NO BAD TRADES .
The PNL formula is (current market price - execution price) direction quantity , with direction being +1 for a buy and -1 for a sell. A naive recompute on every query is quadratic and fails the stress cases.
The clean structure is a per-instrument min heap keyed on PNL, but PNLs shift on every price update so the heap entries go stale. My approach stored trades per instrument in a flat list, computed PNLs lazily on query, and cached the worst trade until the next price update invalidated it.
That got me through most test cases but not all. The fully-optimized answer, which I worked out after the round, uses the observation that PNL ordering is a linear combination of two precomputable per-trade terms, which enables range-minimum queries under a shifting constant factor. I did not reach that inside the time limit.
HR Behavioral (45 min)
Fully in English. The recruiter ran through roughly fifteen short questions in sequence, focused on motivation, self-assessment of soft skills, and cultural fit with Optiver's pace. The questions that demanded structured answers were:
- Why Optiver specifically, versus Jane Street or Citadel.
- What is market making, in your own words.
- What are the three most important soft skills for an engineer, and which one are you weakest at.
- Describe a time a teammate disagreed with you on a technical decision.
- What are the three things you value most when picking a team.
My strongest answers were the market making definition (I used the spread and inventory risk framing rather than a textbook one) and the weakest soft skill question, where I named written communication specifically and gave a concrete example of a misread PR comment along with what I had changed since. The failure mode HR screens for is the generic answer. Specificity dominates.
System Design Round One (60 min)
Round one anchored on a past project. I picked a real-time analytics pipeline from an internship because it had an actual concurrency story. He pushed on three things: consumer lag SLO reasoning, Kafka versus Kinesis tradeoffs, and failure behavior if the downstream sink fell over at a traffic spike. The bar was defending decisions with numbers and constraints, not picking a theoretically optimal design.
The second half shifted to CS fundamentals: TCP sliding window, three-way handshake, SO REUSEADDR versus SO REUSEPORT , and comparing mutex, spinlock, and lock-free compare-and-swap. This is where the OS and networking prep paid off.
System Design Round Two (60 min)
The second round was about high-throughput low-latency trading system design specifically. The prompt was to design a market data feed handler that ingests tick-level updates from an exchange and fans them out to internal strategy processes with the lowest possible latency, while never dropping messages.
I opened with lock-free ring buffers between the network-facing receiver and the downstream consumers, so the producer never blocks on consumer contention. Fan-out was a broadcast pattern where each consumer keeps its own read cursor into the shared ring, and a per-message sequence number lets slow consumers detect gaps and fall back to snapshot-plus-replay. The hot path never takes a lock.
The three corners he pushed: overflow recovery, how to avoid backpressure propagating into the exchange connection, and kernel bypass. I answered with a bounded ring plus explicit overflow detection, a separate slow-path recovery channel, and strict decoupling between producer and consumer latency budgets. On kernel bypass I named solarflare-style user-space networking as the escape valve for the final microseconds.
Result
Offer came four business days after the second system design round. The recruiter called out the OS fundamentals as the strongest part of the system design rounds and the OA dividend problem as the strongest part of the written assessment.
Tips
- Treat the OA like a standalone exam, not a warm-up. Optiver's OA is where most candidates get cut. Block three full hours of uninterrupted time, use the scratch paper the platform provides, and attempt both coding problems before worrying about partial credit on the mini games.
- For the dividend problem, pay the update cost once, not per update. The ratio of updates to queries is the whole hint. Maintain a sorted array plus a prefix-sum array, and rebuild them lazily the first time a query fires after any dividend update. Trying to maintain incrementally is a trap.
- Study OS concurrency and TCP internals, not just algorithms. The system design rounds include pointed questions on TCP windowing, SYN-ACK, spinlock versus mutex, and when compare-and-swap beats locking. I hit all of these and the interviewer's reaction was clearly stronger than on the architecture half.
- Prepare two market-making sentences before the HR round. You will be asked what market making is. Have a two-sentence answer ready that mentions spread, inventory risk, and the market maker's role in providing liquidity. Vague answers get marked down hard.
- Pick one real project to defend under pressure, not several shallow ones. The first system design round anchors on a project from your resume. Pick the one with actual architectural depth, and prep three likely follow-up questions plus the numbers that back up each decision. Shallow coverage across many projects is worse than deep coverage of one.
- For the deep system design round, lead with lock-free structures and latency budgets. The second round is specifically about low-latency trading. If you open with a generic three-tier web architecture, the interviewer has already graded you down. Lead with ring buffers, per-consumer cursors, and kernel bypass as the vocabulary.
Optiver's loop rewards depth and specificity. If you can explain TCP's three-way handshake from memory and defend a real project with numbers, you will do better than a candidate who has solved three hundred LeetCode problems but cannot articulate why a spinlock might beat a mutex under contention.