Quantitative Analyst interview questions and practice.
Builds mathematical and statistical models for pricing, trading, risk and investment decisions in financial markets.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
This page is still being written: no authored question bank for this competency family. The role is fully supported in the interview itself; only the published question bank is outstanding.
What interviewers for Quantitative Analyst actually ask
The question bank for this role is still being written. These are the first three competencies in the model the interview is scored against.
Converts a business objective into a well-defined analytical or predictive problem, chooses the simplest method that could work, and defines success in terms of the decision it supports.
Designs and analyses experiments and observational studies correctly: power, randomisation, multiple comparisons, confounding and causal inference where experiments are impossible.
Builds predictive models with honest validation, understands their failure modes through error analysis, and prevents leakage and overfitting.
What they are really assessing
Interviewers rarely score whether you seemed nice. They score against a model like this one, usually without telling you it exists. Each competency has a weak, adequate and strong shape, and the difference is almost always the level of specific detail you volunteer without being asked.
Formulating the problem & choosing the approach
Converts a business objective into a well-defined analytical or predictive problem, chooses the simplest method that could work, and defines success in terms of the decision it supports.
- Weak
- Jumps to a model type before defining the target or the decision; success is a model metric with no link to business value; cannot describe rejecting a complex approach for a simple one.
- Adequate
- Defines the target, unit of analysis and metric sensibly and starts with a baseline, but the link between model metric and business outcome is assumed rather than tested.
- Strong
- Explains a real project: the decision it served, why the target was defined that way, the baseline or heuristic it had to beat, how offline and business metrics related, and a case where a simple method or no model was the answer.
Statistical inference & experimentation
Designs and analyses experiments and observational studies correctly: power, randomisation, multiple comparisons, confounding and causal inference where experiments are impossible.
- Weak
- Runs tests until something is significant; cannot explain power, peeking or confounding; treats observational correlations as causal.
- Adequate
- Designs A/B tests with pre-registered metrics and sample sizes, and is aware of confounders, but has limited experience with quasi-experimental or causal methods.
- Strong
- Describes an experiment with power calculation and guardrails and a surprising result they diagnosed, plus a causal analysis (diff-in-diff, matching, instrument) where an experiment was not possible, with its limitations stated.
Modelling, validation & error analysis
Builds predictive models with honest validation, understands their failure modes through error analysis, and prevents leakage and overfitting.
- Weak
- Model selection is trial and error on a random split; cannot describe leakage, a model that failed in practice, or what the model gets wrong and for whom.
- Adequate
- Uses appropriate cross-validation or time-based splits, compares against baselines and does error analysis, but hyperparameter and feature decisions are weakly justified.
- Strong
- Gives a specific leakage or overfitting problem they caught, the error analysis that changed the approach, calibration and slice-level performance checks, and the experiment tracking that makes results reproducible.
Data understanding & feature engineering
Investigates how data was generated before using it, engineers features grounded in domain knowledge, and writes reproducible data preparation code.
- Weak
- Uses the dataset as given; cannot explain how the data was generated, a label quality problem or why a feature works; preparation lives in an unrepeatable notebook.
- Adequate
- Profiles data, questions label definitions and builds features from domain knowledge, with pipelines that can be re-run, but data lineage and drift are not tracked.
- Strong
- Describes a data generation quirk (selection effect, logging change, label delay) that would have invalidated results, how they found it, and features derived from domain insight with measured lift.
Taking models from prototype to production
Works with engineering to deploy and monitor models, writes code others can maintain, and understands the operational constraints of the systems that consume predictions.
- Weak
- Work ends at a notebook handed to engineers; cannot describe how a model was served, monitored or retrained, or a production issue with a model.
- Adequate
- Has packaged models for deployment and monitored basic performance, but retraining and drift handling are manual and they were not involved when the model degraded.
- Strong
- Describes a model in production with its monitoring, a degradation incident (drift, upstream change) they diagnosed, and how they made the pipeline reproducible and testable for the engineering team.
Communicating insight & uncertainty
Explains findings, model behaviour and limitations to decision-makers so they act appropriately, and resists overstating certainty.
- Weak
- Presents point estimates as facts; cannot explain a model's limitation or confidence to a non-technical audience; recommendations are missing or over-confident.
- Adequate
- Presents results with intervals and caveats and has changed a decision with analysis, but tends to lead with method rather than the finding.
- Strong
- Gives a case where explaining uncertainty or a failure mode changed a decision, how they framed it for the audience, and how they handled a stakeholder who wanted a more certain answer than the data supported.
Ethics, privacy & fairness
Considers bias, fairness and lawful use of personal data (POPIA/GDPR) in analyses and models, and raises concerns even when inconvenient.
- Weak
- Has not checked performance across groups or considered whether personal data use was lawful; treats these as compliance's problem.
- Adequate
- Checks slice-level performance and anonymises data, but mitigation and documentation were ad hoc and they have not raised a concern that changed a project.
- Strong
- Describes a fairness or privacy issue they found, how they quantified it, the mitigation applied, and a case where they escalated a concern that delayed or changed a project.
Scientific ownership & intellectual honesty
Owns the correctness of their work: seeks disconfirming evidence, admits when results do not hold, and follows a project through to real impact rather than a slide.
- Weak
- Cannot name a result that turned out wrong; projects end at a presentation; impact is asserted with no measurement.
- Adequate
- Has retracted or revised a finding when challenged and tracks whether models were adopted, but impact is only partly quantified.
- Strong
- Describes a result they proactively disproved before it shipped, a project with measured business impact, and one that failed with what they learned about their own process.
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level Quantitative Analyst and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns data science projects end to end from framing to deployed impact for a business area; accountable for correctness and outcome.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: defining the target variable and success metric for a business problem, designing an A/B test: power, duration, guardrails and interpreting a surprising result and causal inference without an experiment: difference-in-differences, matching, instruments, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns analyses and models for defined problems with review; expected to validate data and write reproducible code. | Owns data science projects end to end from framing to deployed impact for a business area; accountable for correctness and outcome. | Owns a data science domain or platform and its roadmap; accountable for methodology standards and outcomes across projects. |
| Tolerance for ambiguity | Handles a defined problem with data gaps; escalates unclear targets rather than guessing. | Formulates problems from business goals, chooses methods, and challenges the ask when analysis will not change a decision. | Defines what problems are worth solving from strategy; makes method and investment decisions with incomplete evidence. |
| People leadership | No formal leadership. | Mentors juniors, reviews analyses, may lead a small project. | Technical lead for scientists, sets review standards, mentors across teams. |
| Who they deal with | Own team, data engineers, an internal requester. | Product and business managers, engineers, analytics and data engineering teams. | Executives, product and data leadership, legal and privacy, engineering platform teams. |
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong Quantitative Analyst would have said them.
- Gives a specific leakage or overfitting problem they caught, the error analysis that changed the approach, calibration and slice-level performance checks, and the experiment tracking that makes results reproducible.
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report