Before you speak to a single person at G-Research, you sit a timed quiz. Ten multiple-choice questions, five options each, ninety minutes on the clock. A few are quick. At least a couple want real work: find the value that minimizes a given cost function, then say how that minimum shifts as one parameter changes. Candidates who went through it in 2025 describe exactly this format, and it screens out most applicants before a human reads anything they wrote.
That quiz tells you what the rest of the process is about. G-Research is a quantitative research and technology firm in London, one of the largest quant employers in Europe, and it hires people who can do fundamentals quickly and correctly under time pressure. This is not a LeetCode grind, and it is not the trading-floor mental-math game that Optiver or SIG run. The bar is mathematics, probability, statistics, and code you can defend line by line.
What G-Research does, and why the interview looks the way it does
The firm builds systematic strategies driven by machine learning and statistical models. Researchers spend most of their day in Python, testing signals against decades of market data on an internal platform that other teams keep fast and correct in C++ and C#. Because the work is research first, the interview weights how you reason about data and uncertainty far more than whether you have memorized a dynamic-programming template.
Two main tracks run through the pipeline, and they share a spine. Quantitative researchers get pushed hardest on mathematics, probability, and machine learning. Quantitative developers and platform engineers get pushed on systems, C++, and software design, with enough statistics to show they understand what the researchers actually need from the platform. Both tracks open with a timed screen and both close in front of senior people who will ask you to think out loud while they watch.
| Stage | What it is | What they are checking | Rough length |
|---|---|---|---|
| CV screen | Recruiter and team review of your application | Strong academic signal in maths, CS, physics, or a quantitative field | Days to weeks |
| Online quiz | 10 multiple-choice questions, 5 options each, 90 minutes; a general quant version or an ML version depending on your background | Speed and accuracy on fundamentals under a hard clock | 90 minutes |
| Coding test | Separate timed programming assessment | Correct, readable code and clear algorithmic thinking | 1 to 2 hours |
| Technical screen | Call with a researcher or engineer | Your background, plus a few live technical questions | 45 to 60 minutes |
| Onsite rounds | Around four one-hour interviews for researchers; two ML-focused hours for ML profiles | Math depth, probability and stats, coding, brainteasers | Roughly 4 hours |
| Final conversation | Chat with a senior leader, often the head of research | Judgment, motivation, and whether you fit how the place works | 30 to 45 minutes |
The online quiz and the coding test
The quiz comes in two flavors. If your background points toward research and modeling, you get a general quantitative aptitude test. If it points toward machine learning, you get an ML-specific one. Either way the topics stay close to the ground: probability, statistics including ordinary least squares, linear algebra, calculus with a real emphasis on differential equations, some programming, and a little finance. The questions test whether you own these tools, not whether you have read a graduate textbook cover to cover.
Ninety minutes for ten questions sounds generous until you hit the two or three that need actual derivation. People run out of time because they treat every question as equal and grind the first hard one for twenty-five minutes. Triage. Bank the quick ones, flag the expensive ones, come back. You cannot cram your way to this in a week, but if your fundamentals were once solid and have gone rusty, a couple of weeks of focused review rebuilds the muscle.
The coding test is a separate obstacle and behaves like a standard timed assessment. Correctness first, then clarity. Handle the edge cases, name things sensibly, and do not show off with a clever one-liner that you cannot explain when someone asks in the next round.
The technical rounds for quantitative researchers
Clear the screens and you reach the onsite, usually about four one-hour interviews. One goes deep on mathematics. The others move across probability, statistics, coding, and brainteasers, and the interviewers care about the derivation, not the memorized result. Being able to state that the OLS estimator is the one that minimizes squared residuals earns nothing on its own. They want you to derive it, then explain what breaks when your predictors are collinear and why the variance of your coefficients blows up.
Optimal-betting questions show up often, usually a version of the Kelly criterion: you have an edge on a biased bet, so how much of your bankroll do you stake to maximize long-run growth. Probability brainteasers are standard, the expected-value and conditional-probability kind rather than riddles. Some interviewers open with a question about a recent market event to see whether you actually pay attention to finance or just want a hard math job that happens to pay well.
A few example questions in the shape they get asked:
- Derive the ordinary least squares estimator, then explain what collinear predictors do to it.
- You have a known edge on a biased coin with a fixed payout. What fraction of your bankroll do you bet, and why not more?
- Find the value of x that minimizes this cost function, and describe how the minimizer moves as the parameter changes.
- What is the expected number of fair-coin flips to see two heads in a row?
- You fit a model and get a great in-sample Sharpe ratio. Talk me through why I should not believe it.
The thing they are really testing is how you behave when you get stuck. Nobody sails through every question. The candidate who says “let me set up the simplest case and check it” and works forward from something true beats the one who freezes or bluffs. Narrate your reasoning, write down what you know, and correct yourself out loud when a step goes wrong. That is the signal they hire on.
The developer and platform track
If you are interviewing for a quantitative developer or platform engineering role, the center of gravity moves to C++ and software design. Expect questions on memory layout, move semantics, what a virtual function costs you at the vtable lookup, and when that cost matters against how much data you are pushing through the research platform. Design patterns come up repeatedly in candidate reports, so be ready to talk about where a strategy or observer pattern earns its keep and where it is just ceremony.
You still need statistics literacy. You are building the tools researchers run their models on, so an interviewer will check that you understand what a backtest is doing and why numerical stability matters when you are summing millions of small floating-point values. The reports that describe a two-hour written test on statistics, probability, and computer-science basics are usually from this track. You do not need to be a researcher, but you cannot be indifferent to what the research is.
The machine learning variant
ML profiles often take the ML quiz and then sit two one-hour interviews weighted toward machine learning, though mathematics, programming, and statistics still show up because they are inseparable from doing ML well. The questions favor understanding over tool names. Expect bias and variance, what regularization actually does to a model, how gradient descent behaves on an ill-conditioned surface, and the ways a model overfits on financial data where the signal-to-noise ratio is brutally low. If you can explain why a feature that looked predictive in backtest evaporates out of sample, you are speaking their language.
How to prepare without burning a month
Aim your prep at fundamentals rather than tricks. Rebuild OLS from scratch on paper. Get comfortable again with expected value, conditional probability, common distributions, and simple Markov chains. Refresh linear algebra and differential equations because both feed the quiz directly. Practice arithmetic at speed so the timed screen does not eat your clock on the easy questions. For the probability and brainteaser style, Xinfeng Zhou’s A Practical Guide To Quantitative Finance Interviews, the book everyone calls the Green Book, matches what G-Research asks more closely than any LeetCode list. Developers should shore up C++ fundamentals and be plain about what they have not touched recently, because inventing knowledge in a C++ round falls apart fast.
On compensation, G-Research has a reputation for graduate and intern packages that sit near the top of the London market, a competitive base plus a meaningful sign-on component. The exact figures move every hiring cycle, so pull a current number from levels.fyi or recent Glassdoor reports rather than trusting a stale one. The published G-Research career guides are also worth reading straight from the source, since the firm tells you a fair amount about what it wants.
The people who get offers are rarely the ones who knew every answer cold. They are the ones who could be wrong in front of a stranger, notice it, and reason their way back to something correct without losing composure. G-Research is buying that reflex more than any single result on the whiteboard.
