A practical roundup of firsthand reports about Optiver’s SWE intern system-design, fundamentals, and live-coding interviews.

Coverage: Software Engineer Intern · Technical screens, system design, coding, and final rounds · Amsterdam and London · 2020–2026.

Good luck!

The short version

The clearest Amsterdam pattern is a broad engineering loop: core CS fundamentals, an open-ended design discussion, and a coding round. London candidates also report system design in the later technical stages, but the public London question bank is still thin.

1. Expect separate technical skills to be tested. Several Amsterdam candidates described distinct fundamentals, system-design, and coding interviews rather than one generic LeetCode round.
2. The design round is interactive. Candidates were expected to clarify the problem, keep the design simple, explain trade-offs, and react when the interviewer changed or refined the requirements.
3. “System design” does not always mean designing a giant web product. Reported Amsterdam exercises included designing Skype and designing a stock-trading application across two locations with a constrained data link.
4. Fundamentals can shape the whole discussion. Reported topics include Python versus C++, Java/Python/C runtime differences, TCP versus UDP, peer-to-peer versus client-server communication, and floating-point representation.
5. Live coding varies considerably. One Amsterdam candidate implemented a trie. Another described a long, domain-heavy prompt whose real solution was only a small amount of code. A third was asked to calculate the size of a linked list.
6. London-specific detail is limited. One recent London candidate confirmed a recruiter call, a technical interview, and additional technical rounds containing system design, but did not preserve the actual design or live-coding prompt.

A practical preparation formula: review core CS fundamentals → practice one open-ended system design aloud → implement a small data structure cleanly → write tests → explain every trade-off while coding.

Amsterdam technical-loop shape

AMS 01: Fundamentals, design, and coding are separate skills

Evidence window: 2024–2026 · Role: Software Engineer Intern · Location: Amsterdam

Across four independent recent Amsterdam reports, candidates encountered some combination of:

1. A behavioral or recruiter interview.
2. A technical-fundamentals discussion.
3. An open-ended system-design exercise.
4. A separate coding or live-coding round.

The exact order was not identical in every report. The stronger pattern is the breadth of the loop, not one guaranteed sequence.

Amsterdam reported topics and tasks

The public reports preserve several concrete tasks, but not enough to reconstruct a complete question bank.

System design

1. Design Skype. Discuss how calls are established and compare TCP with UDP and peer-to-peer communication with a client-server or relay-based design.
2. Design a stock-trading application across two locations. The reported scenario connected a Frankfurt-side trading system with clients and traders in Amsterdam. The interviewer pushed on how much data crossed the link and expected the candidate to consider compression.
3. Solve an open-ended design problem without overengineering it. One successful Amsterdam intern described the round as primarily common-sense problem solving: ask the right questions, find the simplest workable design, and avoid adding unnecessary complexity.
4. Complete a vaguely specified system-design round. A 2026 Amsterdam report did not preserve the prompt, but emphasized working with the interviewer rather than waiting for a perfectly defined specification.

Relevant practice:

• Global One-to-One Voice Calling
• Cross-Site Stock Trading Application

Live coding and data structures

1. Implement a trie. The source does not preserve the exact API or operation set.
2. Calculate the size of a linked list. This appeared as one part of a broader technical interview.
3. Solve a long, descriptive coding problem with a small algorithmic core. The candidate characterized it as LeetCode-like after stripping away the Optiver-style narrative, but did not disclose the complete prompt.

Relevant practice:

• Implement a Trie

CS fundamentals

1. Compare Python and C++.
2. Compare Java, Python, and C, including compiled and interpreted execution.
3. Explain TCP versus UDP.
4. Compare peer-to-peer and client-server communication.
5. Explain floating-point representation and work through floating-point addition.

The evidence does not justify claiming that every candidate receives all five topics. Treat them as concrete examples of the level and style of follow-up.

5 detailed Amsterdam candidate timelines

01: A clearly separated Amsterdam technical loop

Report date: April 24, 2026 · Role: Software Engineer Intern · Location: Amsterdam · Result: No offer

Early stages

1. A long online assessment containing three tests.
2. A short behavioral conversation with HR.

Technical interviews

1. Technical interview one covered core CS fundamentals.
2. Technical interview two was system design. The prompt was described as vague, and the candidate’s advice was to work through it collaboratively.
3. Technical interview three was live coding. The question had a long descriptive setup, but the candidate felt its essential solution could be reduced to only a few lines.

The account is useful for process structure, but it does not disclose either technical prompt in enough detail to recreate them.

02: Open-ended design followed by a trie

Report date: August 25, 2025 · Role: Software Engineer Intern · Location: Amsterdam · Result: Joined and completed the internship

Technical round one: system design

1. The question was deliberately open-ended.
2. The candidate said there was no single correct solution.
3. Deep specialist knowledge was not the main requirement.
4. The goal was to find a simple approach and avoid overcomplicating it.

Technical round two: coding

1. Implement a trie.
2. The candidate described the coding round as manageable rather than unusually difficult.

HR round

The conversation covered interests, hobbies, and questions connected to details on the candidate’s résumé.

This is the strongest recent Amsterdam account because it preserves both a design-round expectation and a concrete coding task.

03: Fundamentals, system design, and coding after a difficult assessment

Report date: July 8, 2025 · Role: Software Engineer Intern · Location: Amsterdam · Result: No offer

Initial assessment

1. Two difficult LeetCode-style or object-oriented programming questions.
2. A separate set of decision-making and cognitive games.

Interview loop

1. HR interview.
2. Technical interview on IT fundamentals.
3. System-design interview.
4. Coding interview.

The candidate reported performing poorly in system design and being rejected. One preserved fundamentals question asked them to compare Python and C++.

The source confirms the round structure but does not reveal the system-design or coding prompt.

04: A three-part technical screen

Report date: October 23, 2024 · Interview month: September 2024 · Role: Software Engineer Intern · Location: Amsterdam · Result: No offer

Behavioral interview

The candidate received standard motivation and behavioral questions, including “Why Optiver?”

Technical interview

1. Calculate the size of a linked list.
2. Compare two programming languages.
3. Work through a system-design question.

The candidate did not advance to the three later technical interviews, so those rounds remain unknown.

This account suggests that even an early Amsterdam technical screen can mix a small coding task, language fundamentals, and design reasoning.

05: Historical Amsterdam design questions with networking depth

Report date: May 8, 2020 · Updated: 2022 · Role: Summer Software Engineering Internship · Location: Amsterdam · Result: No offer

Initial stages

1. A take-home HackerRank assessment with a 48-hour window.
2. An HR interview focused on motivation and basic knowledge of Optiver and market making.

First technical interview

1. Compare Java, Python, and C.
2. Discuss compiled and interpreted languages.
3. Design Skype.
4. Explain TCP versus UDP and peer-to-peer versus client-server networking.

Later technical day

1. Discuss floating-point representation and perform floating-point addition.
2. Design a stock-trading application connecting a Frankfurt-side system with clients and traders in Amsterdam.
3. Estimate the amount of data crossing the link.
4. Consider reducing that traffic through compression.

A CTO conversation and project presentation would have followed.

This is unusually detailed, but it is also the oldest report in the set. Use its networking and design questions as valuable practice, not proof that the 2026 loop is unchanged.

What we know about London (sadge that I still know nothing about Amsterdam...

One day I’ll get to Amsterdam too...

London 01: Later technical rounds include system design

Report date: September 11, 2026 · Interview month: September 2025 · Role: Software Engineer Intern · Location: London · Result: No offer

1. The candidate completed the online assessments.
2. A recruiter call followed.
3. The process continued with a technical interview.
4. The candidate was told that subsequent technical interviews also included system design.
5. They exited in round three, so the later prompts were not recorded.

The candidate described the process as difficult but the interviewers as friendly and helpful. This is useful evidence that London also tests design, but one account is not enough to claim a standard London question format. Amsterdam questions are useful preparation, but they should not be presented as a confirmed London question pool.

What repeated often enough to prioritize

1: Practice until automatic

1. Explain the behavior and trade-offs of small data structures while implementing them.
2. Write readable code and test basic operations without being prompted.
3. Compare languages at the runtime, memory, and performance level—not only by syntax.

2: Be ready to explain deeply

1. Clarify an open-ended design problem before drawing components.
2. Separate authoritative state from caches, projections, or client views.
3. Discuss networking choices in terms of reliability, ordering, latency, bandwidth, and failure behavior.
4. Keep a simple design simple, but be ready to extend it when the interviewer changes a requirement.

3: Higher-level differentiators

1. Estimate data volume before proposing infrastructure.
2. Explain when filtering, conflation, batching, or compression is appropriate.
3. Connect technical choices to a trading system without assuming unexplained finance knowledge.
4. Present one of your own projects clearly enough for a deep technical follow-up.

Final checklist

CS fundamentals

☐ Explain meaningful differences among C++, Java, and Python.

☐ Review process memory, concurrency basics, networking, and floating-point representation.

☐ Compare TCP and UDP using concrete latency, ordering, and loss requirements.

System design

☐ Practice designing one communication system and one trading-data system aloud.

☐ Start with actors, requirements, data volume, latency, and the source of truth.

☐ Describe normal flow, overload behavior, disconnection, recovery, and observability.

☐ Ask clarifying questions before committing to an architecture.

Live coding

☐ Implement a trie and a queue without library shortcuts.

☐ Rehearse linked-list traversal and basic stateful data structures.

☐ Narrate the data-structure choice and complexity while coding.

☐ Write normal, boundary, and failure tests before declaring the solution finished.

Amsterdam and London

☐ Treat the Amsterdam evidence as design-heavy preparation, not a guaranteed script.

☐ Ask the London recruiter whether “technical interview” means coding, fundamentals, design, or a mixture.

☐ Do not assume that an OA implementation problem is the same as the later live-coding round.

Sources: anywhere online with reliable and useful interview info.