Quantitative Data Scientist Interview Questions: Probability, Markets, and Coding

PracHub does not currently have a dedicated Quant target role, so this page is classified under Data Scientist. That taxonomy is imperfect. The guide is written for a quantitative Data Scientist candidate whose role may combine probability, statistics, coding, market reasoning, or research judgment. A pure trading or quantitative developer role may weight those skills differently.

Do not infer a standard interview loop from the word "quant." Read the current job description and invitation, then practice the capabilities they name. The durable skill is turning an ambiguous prompt into a small mathematical or computational model and defending every assumption.

Map the role before choosing questions

Quantitative titles overlap, but their day-to-day decisions can differ. Use the posting to identify the dominant work rather than preparing equally for every possible topic.

Ask recruiting which capabilities will be assessed and what tools are allowed. Do not ask for exact questions. A useful clarification is: "Should I expect implementation in a runnable environment, mathematical problem solving, or both?" That answer changes whether you should spend the next practice session on proofs, code, or communication.

The Data Scientist interview question guide is useful for adjacent statistics and modeling practice. It does not cover every trading-specific topic, which is part of the taxonomy limitation noted above.

Solve probability with states and conditioning

Probability answers become reliable when you name the state before doing arithmetic. A state should contain exactly the information that affects the future.

Consider a fair coin flipped until HH appears. Let E0 be the expected remaining flips when no useful suffix is present, and EH the expected remaining flips when the latest flip is H.

• From E0, one flip is consumed. A head moves to EH; a tail returns to E0. Therefore E0 = 1 + 0.5 EH + 0.5 E0.
• From EH, one flip is consumed. A head finishes; a tail loses the prefix and returns to E0. Therefore EH = 1 + 0.5(0) + 0.5 E0.

Solving gives E0 = 6. The important step is not the final number. It is recognizing that a failed HH attempt can erase the useful suffix.

Now change the target to HT. In state EH, another head leaves you in EH rather than resetting progress. That single transition changes the expectation to 4. Comparing the state diagrams is more useful than memorizing either result.

Conditioning matters just as much. Suppose a condition affects 1% of a population, a test detects 90% of true cases, and 5% of unaffected people test positive. Out of 10,000 people, expect 90 true positives and 495 false positives. The probability of the condition after a positive result is 90 / (90 + 495), about 15.4%, not 90%. State the population table before applying Bayes' rule and base-rate errors become much harder to make.

Use a short checklist for probability prompts:

1. define the random variables and sample space;
2. identify independence or conditional dependence;
3. choose states that preserve only future-relevant information;
4. write the recurrence or conditional probability;
5. check bounds and a simple limiting case;
6. report precision justified by the inputs.

Make estimates and markets explicit decisions

An estimation answer is a model with visible assumptions. Break the quantity into factors, attach units, calculate at a defensible precision, and name the assumption that contributes the most uncertainty.

For "How many transactions can a service process in a day?", a useful decomposition is:

requests per day = active users x sessions per user x requests per session

Then convert the daily estimate into an average and peak per-second load. Do not report seven significant figures when every input is a range. A sensitivity interval is stronger than false precision.

Market-making exercises add a decision. A quote contains a bid, an ask, size, and a reason for the spread. Start with a fair-value estimate, then account for uncertainty, inventory exposure, and the possibility that the counterparty has information you do not.

For the sum of two fair six-sided dice, expected value is 7. A sample educational quote might be 6.5 bid, 7.5 ask for a small size, but that spread is not a universal correct answer. Widening or shifting it can be reasonable when size, risk, information, or inventory changes. Explain which input changed your quote.

Do not treat interviewer skepticism as proof that your answer is wrong or as a contest of stubbornness. Recheck the least certain step, state what you verified, and revise only when the reasoning changes. Calibration means knowing which assumption is fragile.

The same discipline appears in Data Scientist work. A model threshold, experiment decision, or forecast range should move when evidence changes, not when somebody merely asks for more confidence. The data science case study guide covers that decision framing outside a market context.

Translate domain language into code and complexity

Quantitative coding prompts often hide a standard computational structure behind domain language. Translate nouns into state and verbs into operations before selecting an algorithm.

For currency conversion with positive rates, maximizing a product along a path can be transformed by assigning edge weight -log(rate). The product becomes a sum, so a maximum-rate path becomes a shortest-path problem. Rates greater than one create negative edge weights, which means Dijkstra's assumptions may fail. A reachable negative cycle that can still reach the target corresponds to an arbitrage cycle and makes the transformed optimum unbounded.

For a k-displaced array, every element is at most k positions from its sorted location. The smallest remaining output must therefore be among the next k + 1 items. Maintain those candidates in a min-heap, giving O(n log(k + 1)) time and O(k) space. If k is unknown or comparable to n, the advantage over a standard comparison sort disappears. The Python heap guide covers the relevant heap operations.

For a longer build, prefer a simple end-to-end implementation before an elaborate architecture. Add indexing or abstraction when a follow-up creates a demonstrated need. The database indexing guide explains the read-write tradeoff when a small table design grows beyond a linear scan.

FAQ

Why is this Quant page labeled Data Scientist?

PracHub currently has no dedicated Quant role in its target-role taxonomy. Data Scientist is the closest available label for quantitative research, probability, statistics, and modeling content. The page states the mismatch because trading and quantitative engineering roles are not interchangeable with Data Scientist roles.

Are all Quant interviews heavy on probability?

No. Topic weight varies by role and employer. A research seat may emphasize statistics, a trading seat may emphasize mental models and market decisions, and a quantitative developer seat may emphasize implementation. Confirm the current role's capability areas.

How should I answer when I am unsure?

State the model, provide a range if exactness is not justified, and identify the assumption driving uncertainty. If the problem has an exact answer, verify the least certain step rather than adding unsupported confidence.

Should I memorize probability puzzles?

Memorize reusable tools: states, conditioning, symmetry, linearity of expectation, Bayes' rule, and backward induction. A changed condition can invalidate a memorized numeric answer while leaving the method useful.

How much finance knowledge do I need?

Use the job description as the guide. At minimum, understand any domain terms named in the role and be able to translate them into quantities, states, and risks. Do not substitute finance vocabulary for a mathematical argument.