Quant Interview Problem Solving Framework
A repeatable framework for solving unfamiliar quant interview problems: clarify, model, choose a method, compute, sanity-check, and handle follow-ups.
Candidates who know quant interview topics but struggle when a prompt looks unfamiliar.
Clarify the target
Before calculating, say out loud what the problem asks for: a probability, an expectation, a fair price, an optimal decision, an estimate, or an algorithm. That one sentence prevents the most common interview failure, where the candidate solves a nearby problem - the probability of exactly one six instead of at least one, or the expected number of draws instead of the probability of success - and only notices after several minutes of algebra. It also gives the interviewer an early chance to correct you while the correction is still cheap.
Build the model
Name the assumptions, the sample space, the state variables, and the stopping condition. For cards, decide whether order matters and whether draws happen with replacement, because that single choice fixes every denominator that follows. For games, define the payoff, the constraints, and who moves on information. For random walks, write the boundaries and the step distribution before anything else. The model is where most interviews are won or lost - the arithmetic afterwards is rarely the hard part.
Choose the smallest method that fits
Each method has a trigger you can hear in the prompt. "At least one" means take the complement. A sum of things you can count means linearity of expectation with indicator variables, which holds even when those indicators are dependent. A process that keeps returning to similar situations means state recursion or first-step analysis. A base rate plus a test result means a Bayes table written in counts rather than percentages. Interchangeable objects mean symmetry, which often removes the calculation entirely. Simulation is a last resort, and only when the interviewer allows approximation. A clean simple method beats a long formula that hides the reasoning.
Compute visibly and check scale
Narrate the choices, not every digit - the interviewer needs to see why you took the complement, not hear you multiply. Then check the result four ways: is the probability between 0 and 1, do the units match what was asked, does an extreme case behave correctly as a parameter goes to its limit, and does a fair price sit inside the payoff range. If a probability exceeds one or a fair price ignores a possible loss, repair the model rather than the arithmetic.
Concrete example
Take "what is the chance at least one six appears in four rolls of a fair die." Target: a probability. Model: four independent rolls, each with probability 1/6 of a six. Method: "at least one" triggers the complement, so count the ways to avoid a six entirely. Compute: 1 - (5/6)^4 = 1 - 625/1296 = 671/1296, about 0.518. Check: it must exceed the single-roll 1/6 and fall below the union bound of 4 x 1/6 = 2/3, and it does. If the interviewer then asks for the expected number of sixes, linearity answers instantly with 4 x 1/6 = 2/3 - and the gap between 0.518 and 0.667 is a useful reminder that the union bound is loose precisely because it double-counts the outcomes with more than one six.
Common mistakes
Candidates jump into computation before defining the event, go silent when stuck so the interviewer cannot help, or resist a hint because accepting it feels like a loss. All three are avoidable with the same move: when you stall, restate the model and say exactly where the uncertainty sits - "I know I want the complement, I am unsure whether the draws are independent." That converts a silence into a collaboration, and it usually produces the hint you needed anyway.
Practice the pattern
Use the LeetQuidity curriculum and calibration to turn this topic into a focused practice plan.