# How XTX Markets screens quant researchers and developers

Source: https://www.techinterview.org/post/3233476791/xtx-markets-interview-process/
Updated: 2026-07-20 · techinterview.org

XTX Markets cuts something like 90 to 95 percent of applicants at the online assessment, before a human has read a single line of your code. That first screen decides most outcomes at a firm this lean: roughly 250 to 300 people run a trading operation that pushes around $250 billion of volume a day across FX, equities, fixed income, and commodities. When the headcount is that small and the P&L that large (2023 revenue came in near £2.0 billion with about £835 million of net profit), the cost of a bad hire is enormous, and the process is built to reject aggressively rather than to make you feel welcome.

## Why the loop looks nothing like a big-tech interview

XTX is fully systematic. There are no discretionary traders taking positions on a hunch; models decide, and people build and improve the models. Alexander Gerko founded the firm in 2015 and still runs it as co-CEO. The edge is machine learning applied to market microstructure, trained on order-book, tick, and alternative data across one of the largest privately held GPU clusters in the industry, more than 25,000 accelerators at last public count. That shapes who gets hired. They want quant researchers who can reason about statistics and ML at a level most applied-ML jobs never demand, and developers who can turn a signal into an order at microsecond latency without a cache miss or an allocation ruining the trade.

Two tracks run in parallel. Quant researchers own the models: feature design, training, validation, and the statistics behind why a model should generalize to tomorrow's market. Quant developers, sometimes posted as software engineers, own the systems: the low-latency C++ that ingests market data, prices, and sends orders. The interviews diverge early, so figure out which track you're in before you prep for the wrong one.

## The online assessment is the real filter

For developers, the OA is two or three hard algorithmic problems in 90 to 120 minutes. The problems sit near the top of the hard bucket, with tight time limits that punish anyone who hasn't drilled the patterns until they're automatic. For researchers, it's a combined machine-learning and probability test of similar length, often with a small data-analysis piece where you're handed a dataset and asked to fit something and defend it. People who've been through both rounds tend to describe XTX's OA as one of the meanest in the business, and the reported pass rate sits somewhere around 5 to 10 percent.

The practical read: you don't clear this by being generally strong. You clear it by being fast and exact. For the dev OA, that means dynamic programming, graphs, and greedy problems solved cold, plus the discipline to not burn 40 minutes on the second question. For the research OA, it means probability you can compute under time pressure and ML judgment you can apply without a notebook to lean on.

## The technical call and the London onsite

Clear the OA and you get a 60-minute call with a working researcher or engineer, not a recruiter. Developers do live coding. Researchers get pushed on ML and statistics, sometimes on a problem loosely tied to something they've published or listed on their CV. It's conversational, but the person on the other end writes production models or trading systems for a living and will notice if you're reciting rather than reasoning.

The onsite is five or six back-to-back interviews in a single day at the London office, each 45 minutes to an hour. Working researchers and engineers run every one; HR barely touches the technical content. For engineering candidates one of those sessions is system design aimed at low-latency, distributed problems rather than the usual "design Twitter" fare. At least one round on either track is behavioral, and it's less about scripted stories than about whether you can be wrong in front of smart people without getting defensive.

| Stage | Format and length | What it screens for | Who runs it |
| --- | --- | --- | --- |
| Online assessment | Timed, 90 to 120 min. Devs: 2 to 3 hard algorithm problems. Researchers: ML plus probability, sometimes a data-analysis task | Raw problem-solving speed and depth; reported pass rate roughly 5 to 10 percent | Automated, graded offline |
| Technical phone screen | About 60 min. Live coding (dev) or ML and statistics discussion (research) | Real coding ability or genuine ML reasoning, not memorized answers | A working engineer or researcher |
| Onsite loop | 5 to 6 back-to-back interviews in one day at the London office, 45 to 60 min each | Depth across coding, mathematics, ML, and problem-solving under pressure | Working engineers and researchers |
| System design (engineering) | One onsite session, 45 to 60 min | Low-latency, distributed design: market-data fanout, hot-path discipline, tail latency | A senior engineer |
| Behavioral and fit | One onsite session, 45 to 60 min | Collaboration and intellectual humility; being wrong without getting defensive | Researcher or engineer, minimal HR |

## What quant researchers actually get asked

The probability questions are Green Book territory, computed out loud. A few that match the flavor:

- "I flip a fair coin until I get two heads in a row. What's the expected number of flips?" (It's 6, and they want the recurrence, not the memorized answer.)

- "Two players take turns rolling a die; first to roll a six wins. What's the probability the player who goes first wins?"

- "You fit a linear model and the out-of-sample R-squared comes back negative. What's happening, and what do you check first?"

- "How would you detect that the relationship between your features and the target has drifted since you trained?"

The ML questions go deeper than "which model would you use." Expect to derive the bias-variance decomposition and say exactly where regularization sits in it, to explain why ordinary cross-validation leaks information in time-series data and what you'd do instead, and to defend a modeling choice against distribution shift, since a market that's changed regime is the whole problem in trading. Vague answers about trying a few models and picking the best AUC get taken apart. They're testing whether you understand why a model works, because in live trading a model you don't understand is a model you can't fix when it starts losing money.

## What developers actually get asked

C++ at depth is the whole game. The questions probe the parts of the language most people happily ignore:

- "Write a single-producer, single-consumer lock-free queue. Now tell me where false sharing hides and how you'd pad around it."

- "What does std::vector do on reallocation, and why is that a problem in a hot path?"

- "Here's a struct. Reorder the fields for the cache and explain what you saved."

- "This function is slow. Profile it in your head and tell me the first change you'd make."

Template metaprogramming, move semantics, memory ordering, and the cost of a cache miss all come up because they matter to the job, not because they're trivia. The system-design round tends toward the shape of a real trading stack: how market data fans out to many consumers, how you keep a hot path allocation-free, where you'd place a sequencer, and how you reason about tail latency when the mean looks fine. Concrete tradeoffs beat buzzwords every time.

## Compensation, and how to read the numbers

XTX pays at or near the top of the market, and senior packages are broadly comparable to Citadel Securities. New-grad total comp for a quant researcher at this tier generally lands in the low-to-mid six figures, with a base in the low six figures and a bonus that can rival or exceed it in a strong year. Senior researchers and engineers reach seven figures when the firm performs, which, on £835 million of net profit spread across a few hundred people, it has. Those numbers move a lot with firm P&L and with your level, and public data on a shop this private is thin, so treat any single figure with suspicion and cross-check current ranges on levels.fyi, Blind, and Glassdoor before you anchor an expectation. What stays stable is the shape: modest base, much larger variable comp, and total packages that assume you're one of a small number of people directly moving the P&L.

## If you've got a month to prepare

For the research track, rebuild your probability from the ground up until expected-value and Markov-chain setups are reflexes, and make sure you can derive the ML results you'd normally cite, because they'll ask you to. Practice defending model choices under regime change and get comfortable with time-series validation done properly. For the dev track, live in C++: lock-free structures, the memory model, cache-aware layout, and profiling instinct, then add enough low-latency system design to talk through a market-data pipeline without hand-waving. On both tracks, do timed OA-style problems until speed stops being the thing that kills you, because for most applicants the OA is exactly the thing that kills them, and it does it before anyone at the firm ever learns your name.