A Four-Week Quant Interview Study Plan

A useful quant interview plan starts with your target role and current gaps. Four weeks is a planning window, not a promise that every candidate can become interview-ready in a month. If you are still learning probability or programming fundamentals, give yourself more time.

Start with the free diagnostic. For each problem, record your answer, reasoning, time, and whether you used a hint. Getting a familiar answer right from memory is different from explaining a new variant.

Choose a role before choosing a syllabus

Trading: emphasize arithmetic, probability, expected value, decisions under uncertainty, and clear explanations. Add coding if your target role calls for it.

Quantitative research: emphasize statistics, experiment design, coding, time-series validation, and explaining a research project. Probability still matters, but research interviews can go well beyond puzzles.

Quant development: emphasize algorithms, data structures, testing, and the systems relevant to the job description. A low-latency C++ role and a Python research-engineering role need different preparation.

The employer's role description and invitation should determine the balance. For an example of research requirements, Jane Street's research role describes experiment design, model building, Python, and collaboration. Do not assume every interview is a mental-math test.

Decide what four weeks can realistically change

Use four weeks to fix a defined interview bottleneck, not to learn every quant skill from scratch. Before setting a schedule, attempt an unfamiliar probability problem, implement a small function with tests, and explain a project in three minutes. Judge the reasoning as well as the final answer.

Jane Street's official interview guidance distinguishes trading, research and engineering preparation, and describes research interviews as overlapping trading and software engineering. That is a useful reason to keep role selection ahead of a universal question list.

Worked diagnostic: an answer can be right for the wrong reason

A bag contains three red and two blue counters. Draw two without replacement. What is the probability both are red?

The answer is 3/5 × 2/4 = 3/10. The second probability is conditional on the first red draw. Multiplying 3/5 by 3/5 assumes replacement and gives 9/25 instead. Now ask the candidate to explain the difference without using the formula. If they cannot, spend the next session on conditional sample spaces rather than on speed.

For a coding follow-up, simulate the experiment and compare the estimate with 0.30. Check that the code removes the first counter; sampling independently would simulate a different problem. This small exercise tests whether your mathematics and implementation describe the same process.

If the interview is in seven days

Use day one for the diagnostic and invitation rules, days two through four for the two largest gaps, day five for a fresh mock, day six for corrections, and day seven for light review and logistics. Put project explanation first for a research interview and implementation first for an engineering interview. This is an editorial planning example; your recruiter's instructions determine the actual interview requirements.

Week 1: build a baseline you can explain

Use five sessions of 60–90 minutes, adjusted to your schedule.

1. Take the diagnostic and categorize the errors.
2. Practice conditional probability with a tree or explicit sample space.
3. Work on expected value, including costs and conditional decisions.
4. Complete one coding exercise and test its edge cases.
5. Re-solve every missed problem without the answer visible.

Deliverable: a short error log and a prioritized topic list. Put your weakest recurring concept first, even if practicing your strongest topic feels more rewarding.

Week 2: add role-specific practice

For trading, use the SIG practice guide and Optiver practice guide. Explain the assumptions in each solution rather than collecting tricks.

For research, choose a project you can discuss in detail. Explain the dataset, prediction target, baseline, training/evaluation split, leakage controls, and why you trust the result. Use the research project review checklist.

For development, alternate problem-solving with implementation. State complexity, test empty inputs and boundary values, and explain the design tradeoffs. Use the languages and topics in the actual job description.

Use the quant developer interview guide for a worked coding task and systems discussion. Research candidates can practice explaining uncertainty with the statistics interview cases. Trading candidates can work through the market-making exercises, keeping a cash and inventory ledger as they go.

Deliverable: three problems solved clearly, one technical project explanation, and a list of follow-up questions you cannot yet answer.

Week 3: practice under a constraint

Introduce a timer to a mixed set you could solve untimed. Compare the types of mistakes you make, not just the score. Keep a short warm-up separate from the mock so you do not confuse practice with assessment.

For a practice session that changes the kind of reasoning, try the trading decision games or estimation exercises. Use the behavioral interview worksheet to prepare truthful examples of decisions, mistakes and feedback alongside technical work.

Use this response structure when speaking aloud:

• Restate the task and assumptions.
• Choose the sample space, model, or data structure.
• Work through the calculation or implementation.
• Check an edge case or limiting case.
• Explain how the answer changes if one assumption changes.

Illustrative feedback: “The numerical answer is correct, but you multiplied probabilities without explaining independence. State the relationship between the events before calculating.” This is an example of useful feedback, not a quotation from a student's session.

Deliverable: one recorded self-mock or practice with a partner, reviewed for both reasoning and communication.

Week 4: target the remaining bottleneck

Review the employer's instructions and your error log. Spend most of your time on errors that recur across topics: confusing independence, not accounting for costs, silently changing assumptions, or failing to test code.

Practice one mock at the beginning of the week and one after addressing the biggest gap. Use different questions; repeating a memorized set inflates confidence without testing transfer.

Leave time for logistics, sleep, and reviewing your own projects. An extra late-night problem set is not always the most useful preparation.

Deliverable: a one-page readiness note listing what you can explain, what still needs work, and how you will approach an unfamiliar problem.

Keep this error log

When to get help

If you are still organizing applications, use the quant internship application guide to track role requirements and deadlines. The annotated quant résumé examples show how to explain the work you can defend in an interview.

If you can identify mistakes but cannot explain why they recur, feedback may be more useful than another question bank. If the fundamentals are missing, a structured course or textbook can help. If your main gap is execution, keep practicing with a timer and a review loop.

Read bootcamp versus self-study to choose the level of support you need, or explore Quant Blueprint's preparation program. Book a free quant consultation to discuss your target roles, timeline and preparation priorities. Mock interviews and coaching are part of the program.