The model is the easy half.
It still has to run.
A quant screen is two interviews wearing one badge. The first asks whether you understand the maths; the second asks whether you can say what your code costs, choose the structure that makes the operation you repeat cheap, reach the right complexity class before you write a line, and keep a number true after ten million floating-point operations. Runtime Row is that second interview, taught end to end with the finance objects you already know — order books, tick streams, price series and signal ranks — as the worked examples.
Before you can choose an algorithm you have to be able to say what one costs. This world builds that vocabulary honestly: counting operations under the model everyone silently assumes, asymptotic notation and what it deliberately throws away, the handful of growth classes you will actually meet, the difference between worst, average and amortised cost, and the memory hierarchy that decides whether two algorithms with the same big-O run at the same speed.
-
Level 1 · ▶ NEXT What a Line of Code Costs ★★★ ◆
-
Level 2 Big-O and Its Relatives ★★★ ◆◆ 🧩 Builds on L01
-
Level 3 The Complexity Zoo ★★★ ◆◆ 🧩 Builds on L02
-
Level 4 Worst, Average and Amortised ★★★ ◆◆◆ 🧩 Builds on L03
-
Level 5 The Memory Hierarchy ★★★ ◆◆◆ 🧩 Builds on L04
-
👑Level 6 · REVIEW The Cost Audit ★★★ ◆◆◆ 🧩 Builds on L05
A data structure is a bet about which operation you will repeat. This world takes the four that matter — the array, the hash map, the heap and the balanced tree — and asks of each what it makes cheap, what it makes expensive, and where its stated complexity is a promise rather than a guarantee. It ends by assembling them into a limit order book, which is the structure question quant interviews actually ask.
-
Level 7 Arrays and the Cost of Growing ★★★ ◆◆ 🧩 Builds on L06
-
Level 8 Hash Maps ★★★ ◆◆ 🧩 Builds on L07
-
Level 9 Heaps and Priority Queues ★★★ ◆◆◆ 🧩 Builds on L08
-
Level 10 Balanced Trees and Ordered Containers ★★★ ◆◆◆ 🧩 Builds on L09
-
Level 11 Designing a Limit Order Book ★★★ ◆◆◆ 🧩 Builds on L10
-
👑Level 12 · REVIEW The Design Review ★★★ ◆◆◆ 🧩 Builds on L11
Five patterns cover most of what a quant screen throws at you: sorting and the times you should not, binary search including the version that searches over the answer rather than the array, the one-pass sliding-window family that turns a quadratic statistic linear, divide and conquer, and dynamic programming. Each is taught as a recognisable shape with the trading problem it usually arrives dressed as.
-
Level 13 Sorting, and When Not To ★★★ ◆◆ 🧩 Builds on L12
-
Level 14 Binary Search Over the Answer ★★★ ◆◆◆ 🧩 Builds on L13
-
Level 15 One Pass: Two Pointers and Windows ★★★ ◆◆ 🧩 Builds on L14
-
Level 16 Divide and Conquer ★★★ ◆◆◆ 🧩 Builds on L15
-
Level 17 Dynamic Programming ★★★ ◆◆◆ 🧩 Builds on L16
-
👑Level 18 · REVIEW The Screen ★★★ ◆◆◆ 🧩 Builds on L17
The part of programming that quietly ruins research. What a double actually is and where its precision goes; why summing a long series left to right loses accuracy and what to do instead; what vectorising buys you and when it costs you; the language semantics that produce bugs which look like bad data; and the concurrency question that is really a question about one cache line.
-
Level 19 What a Double Actually Is ★★★ ◆◆ 🧩 Builds on L18
-
Level 20 Summation and Cancellation ★★★ ◆◆◆ 🧩 Builds on L19
-
Level 21 Vectorising, and When Not To ★★★ ◆◆◆ 🧩 Builds on L20
-
Level 22 The Semantics That Bite ★★★ ◆◆ 🧩 Builds on L21
-
Level 23 Concurrency and One Cache Line ★★★ ◆◆◆ 🧩 Builds on L22
-
👑Level 24 · REVIEW The Final Review ★★★ ◆◆◆ 🧩 Builds on L23
Own the Hot Path
Clear all 24 levels and the four reviews and you will be able to do the thing the technical half of a quant interview is really testing: look at a problem, name the operations it repeats, reach the right complexity class out loud, choose the structure and the algorithm that fit it, and then write code whose numbers are still true at the end. You will be able to design a limit order book and defend every choice in it, spot the difference between an average case and a guarantee, and explain why a result changed when nothing about the model did. Then you will take a seat on a live system with a latency budget and find out whether the choices hold up.
View Achievements 🏅