How to prepare for a quant interview: a role-specific study plan

Prepare for a quant interview by identifying the role, diagnosing your current gaps, practising worked problems, and then solving unfamiliar variations aloud. Combine probability, statistics, coding and relevant financial reasoning in proportions that match the vacancy. Use a study cycle with evidence of progress rather than treating a fixed number of questions or weeks as a guarantee of readiness.

It is easy to spend every evening reading solutions and feel familiar with the material. The more useful test comes the next day: can you solve a changed problem without the solution, explain the assumptions, and respond when the interviewer alters one of them?

Step 1: identify the actual interview target

Read the vacancy and the employer's current preparation material. Record the role, required skills, assessment format if stated, and deadline. Separate explicit information from your assumptions.

Step 2: run a short diagnostic

Try the following without looking at solutions. Write down the reasoning, not just a number.

Classify each failure: concept gap, modelling error, algebra, implementation, interpretation or communication. The same wrong answer can arise from different causes and require different practice.

Avoid treating this small diagnostic as a hiring assessment. Its purpose is to choose your next study action.

Step 3: choose a role-specific emphasis

These are recommendations for allocating study effort. Actual roles may combine several rows or assess other subjects. If a required topic is missing, add it from the vacancy rather than assuming the table is exhaustive.

Step 4: use an eight-week preparation cycle

The template below assumes six planned hours per week, giving 48 hours in total. It is an arithmetic study budget, not an estimate of the time every candidate needs. Extend a phase when its checkpoint is incomplete.

For a six-hour week, one possible allocation is two hours solving unfamiliar questions, ninety minutes repairing concepts, ninety minutes doing changed re-attempts, and one hour on a mock or project discussion. Include review and debugging within those blocks.

Step 5: make every reviewed solution produce another attempt

Use a three-part loop. First attempt the problem without notes. Then compare the reasoning and repair the specific gap. Later, solve a variation without the original solution in view.

For conditioning, change the reporting rule. For expectation, change dependence or the state transition. For statistics, change the sampling structure. For coding, change timestamps, missing values or the required complexity.

Keep a concise record: question, decisive assumption, failure, repair, variation and outcome. Do not record only solved-question counts. Ten copied solutions and one independently solved unfamiliar variation are different kinds of evidence.

Avoid a rigid time limit before you understand the method. Once you can solve accurately, use time constraints to practise prioritising and communicating the important steps.

Step 6: practise an interactive mock session

Here is a suggested 30-minute practice format. It is not an employer's interview schedule.

Ask the practice partner to provide a hint when needed and observe how you use it. Explain a mistake and correct it plainly. Continuing to defend a contradicted assumption makes it harder to demonstrate the reasoning you actually have.

If practising alone, record a spoken explanation and review whether someone could reconstruct the model from your words. Follow applicable platform and employer rules in an actual assessment; independent practice is not permission to use outside assistance during a restricted interview.

Step 7: prepare a project you can defend

Choose a project you understand deeply rather than presenting a long list of shallow implementations. Explain the decision or hypothesis, data provenance, information timing, method, benchmark, strongest check and main limitation.

For a backtest, be ready to trace one signal into a feasible position and cost. For a pricer, explain the contract, inputs and numerical benchmark. For a software tool, describe a failure case and how you tested it.

A failed result can be useful evidence if you can show what it ruled out. Do not replace an honest limitation with a performance claim you cannot support.

How to judge progress

Look for changed behaviour: you define the conditioning event before counting; you include dependence in uncertainty; you test information timing before interpreting a model score; you choose a benchmark before optimising code. Those are meaningful improvements even before your solution speed increases.

Use mock feedback to select the next question, then confirm the repair with an independent attempt. No single private score or checklist can establish how an employer will assess you.

What if the interview is next week?

Inspect the stated scope, repair the largest gaps and practise explaining a small number of methods and projects. Keep time for rest and setup. A compressed schedule cannot create missing foundations instantly; choose the highest-value work that is feasible now.

Should I study only brainteasers?

How many questions should I finish?

There is no universal number. Measure whether you can solve unfamiliar variations and explain assumptions independently. Use question counts as a record of activity, not as a substitute for evidence of learning.

Start the next practice session

Download the accompanying Python examples