What Probability Interviews Test in Quantitative Research Hiring
Summary
The document discusses why quantitative research interviews often use elementary probability puzzles involving cards, dice, coins, and conditioning instead of direct financial modeling questions. One response criticizes this practice, arguing that research work should emphasize using established results to develop useful new ideas rather than recalling standard exercises. A second response offers a more practical explanation: interviewers use familiar probability problems to check whether candidates understand basic quantitative tools and can apply them to unfamiliar situations.
The second perspective treats the process of reasoning as the main signal. A candidate may know a formula by memory without understanding its mechanics, while a well-structured solution can reveal how they clarify assumptions, reason from fundamentals, and adapt when a problem changes. The analogy is to programming interviews, where simple tasks test problem-solving habits rather than reproduce ordinary job duties. The document presents differing views and does not establish that these interviews predict research performance; it also notes that some interviewers may use puzzles chiefly as a display of cleverness.
Key ideas
- Probability puzzles can test whether candidates know core quantitative methods and can apply them.
- Interviewers may value the candidate's reasoning process more than a polished final answer.
- Working from fundamentals can reveal understanding that memorizing a formula alone does not show.
- The document also raises the concern that some interviewers use puzzles as a display of status.
- It presents opinions rather than evidence that puzzle performance predicts research ability.
Tags
Full text
# Why do recruiters ask you to solve lots of basic, yet not simple, probability problems? # Why do recruiters ask you to solve lots of basic, yet not simple, probability problems? Why do recruiters in Quant Research ask you to solve lots of basic probability problems that have to do with uniform discrete random variables and cumbersome conditioning (cards, dices, coins)? Wouldn’t it be more relevant discussing financial modeling? ## Answer by Frido (score 5, accepted) https://quant.stackexchange.com/a/85170 Because most recruiters and sometimes even desk heads do not understand that when you do modelling / research what you need least is counting cards or tossing coins or coding (implementation / industrialization is the next step), but using various known results to arrive at something novel that can be used in practice. Last time I checked research means pushing the boundaries of knowledge, not remembering every single theorem learned at college and solving standard problems ad infinitum. ## Answer by D Stanley (score 1) https://quant.stackexchange.com/a/85167 The purpose is typically two-fold: 1) to understand if you know basic quantitative methods and how to apply them, and 2) to see how you go about solving a non-intuitive problem using those tools. One could memorize the black-scholes option pricing formula, for instance, without really understanding how the formula works. Plus, if you know how to apply probability methods in general, you will be better at solving problems that do not already have an intuitive solution. If you can't rely on a memorized formula, you have to think about the fundamental aspects of a problem, and think about how to apply what you know to solve it. It's often more about how you think than actually solving the problem, since in the real world you will have access to other experts to help you solve the parts that you don't know. There is a similar strategy when hiring software developers. Interviews often consist of writing programs to solve relatively simple problems or implement an algorithm, which very rarely comes up in "real" programming. But the questions are meant to see how well you understand a problem that is describes, see if you ask clarifying questions, see what your thought process is for solving it, how you adapt to changes in requirements, etc. If you know some basic tenets in programming you can apply them to the problem instead of memorizing how to implement a quicksort, for example. (There's also occasionally a "quiz" mentality for interviewers to show that they are smarter than the interviewee, but these can be easy to see through if you know what you're talking about)
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.