Quant interview preparation

Prop market making and quantitative research, weighted the way the interviews actually are: probability and expected value, statistics and machine learning, market making logic, programming and options. Every question is either traced to a named firm from a public candidate report, or tagged at desk level when we could not trace it, and every probability answer shows the reasoning path rather than just the number.

Jump to the question bank
Question bank

100 questions, mapped to the firms that asked them

Questions
100
Traced to a firm
53
Firms
15
Updated
September 2026
Asked at
All firmsOld Mission Capital12Tower Research Capital10Jump Trading7Akuna Capital5Citadel4D.E. Shaw3Jane Street3AQR Capital Management2DRW2Millennium Management2Schonfeld2Squarepoint Capital2Susquehanna International Group2Belvedere Trading1Optiver1
Topic
All topicsProbability10Coins, cards and games6Expected value8Statistics11Market making15Estimation and mental maths4Stochastic processes4Regression5Machine learning6Time series6Programming10Options and derivatives8Fit and motivation7
Level
AnyCoreIntermediateHard
Type
AnyBrainteaserTechnicalCaseMarket viewFit
Showing 1–1 of 1 · filtered from 100Clear filters
  1. 079How would you store key-value pairs, and what are the tradeoffs between the implementations?ProgrammingIntermediatetechnicalJump TradingEngineering · Cambridge · 2019

    Say this

    Hash table for O(1) average lookup with no ordering, balanced tree for O(log n) with ordered iteration and range queries, and a flat sorted array if the data is static and you care about cache behaviour. The choice is driven by whether you need ordering and what your access pattern looks like in memory.

    Then walk it

    1. Hash table: O(1) average, O(n) worst case on collisions, no ordering, and rehashing causes an occasional large latency spike. That spike is a real problem on a trading hot path and it is why people pre-size their maps.
    2. Balanced tree, red-black or B-tree: O(log n) guaranteed, ordered traversal, range queries, and predictable latency. Worse constants and worse cache locality because of pointer chasing.
    3. The tradeoff that matters most in practice is memory layout, not big-O. C++ unordered_map uses separate chaining with nodes scattered across the heap, so every lookup is potentially a cache miss. An open-addressing flat hash map keeps everything in one array and is commonly two to three times faster in real workloads at the same asymptotic complexity.
    4. For a mostly-static table, a sorted array with binary search beats both: contiguous memory, no pointers, and for small n a linear scan beats binary search because it is branch-predictable and prefetchable. Under about 16 to 32 entries, linear wins.
    5. And on disk the answer changes completely: B-trees for read-heavy workloads because of the branching factor against block size, LSM trees for write-heavy because they turn random writes into sequential ones. I would want to know the read-write ratio and whether the working set fits in cache before choosing anything.

    Where candidates lose it

    Answering hash map, O(1), done. The question says tradeoffs, so it is a systems question and the interviewer at a trading firm cares about tail latency and cache behaviour more than asymptotic complexity. Mention rehashing spikes and pointer chasing, and ask what the access pattern is.

    Expect next

    • Why is std::unordered_map often slow in practice?
    • How would you avoid latency spikes from rehashing?
    • What changes if the data lives on disk?

    Reported by candidates at Jump Trading (Engineering, Cambridge, 2019). Source: Wall Street Oasis.

Firm tags come from public, anonymous candidate reports on Wall Street Oasis: strong signal, not sworn testimony. Firms are named as the places a question was reported, not as partners of Fin Maverick. Answers are written for this page to show how to think out loud; they are not scripts to recite.