The Quant Researcher Interview Process

Nearly every researcher process runs four to six stages, typically stretching over a month or more:

1. 1
   CV and recruiter screen. Background, motivation, and for PhD candidates an early conversation about your research.
2. 2
   Timed online assessment. Probability and statistics, often with a coding or data component. At the faster firms, this is where reported rejections concentrate.
3. 3
   Technical interviews. One to three rounds: probability, statistics and regression, coding in Python, and for many firms a discussion of your own projects.
4. 4
   Take-home or case exercise. At systematic funds, a data challenge lasting anywhere from 6 to 48 hours. Not universal, but where it exists it is the core evaluation.
5. 5
   Final round. A superday or virtual onsite mixing deeper technicals, research discussion and fit.

The stages themselves look similar everywhere. How much each one counts, and what it contains, differs sharply by firm type.

The speed-driven process: HFT and market making

Prop trading firms and market makers run researchers through a quicker, probability-heavy process that overlaps substantially with their trader interviews. Expect rapid-fire expected value, combinatorics with cards and dice, mental math under time pressure, and interviewers who change the assumptions mid-problem to see how you adapt. Coding appears, but probability speed is the filter. If this is your target, the preparation looks a lot like trader interview preparation with a statistics layer on top.

The project-driven process: systematic funds

Funds running slower systematic strategies test depth over speed. The process features statistics and regression done properly (assumptions, pitfalls, inference), machine learning methodology, Python with numpy and pandas, and above all your own research: take-home data challenges, case studies, and rounds that are effectively a defence of work you claim as yours. One fund's reported superday is a six-hour data exercise followed by an hour presenting your model to a researcher. Another sends an open-ended statistical problem and then runs a round that is a code review of your own submission.

The pod-driven process: multi-manager platforms

Multi-manager platforms such as Millennium and Point72 are organised as dozens of autonomous teams, called pods, each running its own book under its own portfolio manager, and each hiring for itself. You interview with a pod, not with the firm, so process variance is the defining feature. Reported formats range from 24-hour Jupyter-notebook assessments to six-hour cases that involve parsing filings, cleaning data and building an analysis end to end, followed by conversations with the portfolio manager whose book you would join. Prepare for the general toolkit, then expect the specifics to be whatever that pod wants.

The middle three stages carry the technical evaluation, and each one filters for something different.

Stage 2: the online assessment

The timed assessment leans on probability, statistics and light coding. Speed matters most in the speed-driven process; at systematic funds the OA is more likely to include a small data-analysis exercise, and one large fund's researcher OA famously asks candidates to implement linear regression efficiently in numpy. Our coding problems cover the reported implementation tasks, from OLS and bootstrap confidence intervals to purged cross-validation.

Stage 3: the technical rounds

These split by process type: probability puzzles and market games in the speed-driven process (the same material as our brainteaser bank), statistics, regression pitfalls and ML methodology in the project-driven process. A consistent theme across systematic funds is model-validation reasoning: why a backtest can look brilliant and lose money live, why you cannot shuffle time-series data into random cross-validation folds, what survivorship and look-ahead bias do to results. That territory is under-prepared enough that we built a dedicated course around it.

Stages 4 and 5: the take-home and its defence

The take-home and the follow-up round are two halves of the same test. The take-home checks whether you can do research; the follow-up round checks whether you understand what you did, follow-up by follow-up, until the interviewer finds an assumption you cannot defend. Candidates who volunteer their own work's weaknesses, with fixes, tend to outperform candidates who defend everything. For PhD candidates the same drill runs on your thesis: expect "why this method and not that one" several layers deep.

The three quant roles share a surprising amount of interview surface, which is exactly why candidates mis-prepare: the probability round looks the same from the outside, but what each process is filtering for underneath is different.

The trader interview and developer interview each get their own guide. The researcher process borrows probability from one side and coding from the other, then adds the layer neither tests: whether you can tell a real result from an artifact of how it was produced. That is why the model-validation material shows up in researcher processes and almost nowhere else.

The boundaries are also genuinely blurry at some firms. At least one major firm describes its researcher interviews as an explicit mix of its trader and developer tracks.