Fundamentals,
calibrated by depth.
Six topics, each pushed down to the level where the "why" questions run out. The depth badge on every section tells you how hard to push: some of this needs a mechanism you can rebuild on the spot, some needs recognition, and some needs one sentence so you do not look blank. None of it is firm-specific — the same mechanisms get probed whether the round is DRW's 45 minutes or Jump's 60. The seventh page is different: it is your own resume project taken apart, because that is the one topic in the room where you cannot fall back on general knowledge.
pandas
The biggest gap and the most reps. Alignment, Copy-on-Write under pandas 3.0, the agg and transform split, what a merge does to duplicate keys, and the time series cluster this desk actually runs on.
They are probing: whether you have handled real time series, or only tidy CSV files.
Python runtime
Where a quant dev screen really probes. Why threads do nothing for a numeric loop and everything for a socket, what the escape hatches cost, and where the memory goes for a million small objects.
They are probing: whether you know what the machine is doing under your code.
Python semantics
Verification, an evening at most. Hashability, dict internals, generators, copies, mutable defaults, closures, plus the complexity numbers as a reflex.
NumPy
Rebuild from zero. An array is a pointer, a dtype, a shape and a strides tuple, and views, broadcasting, axis semantics and the whole speed argument fall straight out of those four fields.
They are probing: whether you can predict a shape and a copy without running anything.
Operating systems
Recall refresh at conversational depth, except cache locality, which goes deep because it is the payoff line in a sequencer answer.
Networking
Recall refresh, with one exception. The receive window is your strongest asset in that room, so it is written as a sentence to deliver rather than a thing to reconstruct.
They are probing: whether you understand why the desk uses two transports at once.
Your resume project
The maritime fleet optimizer, reverse engineered. What each stage of the pipeline computes, why the average-safety constraint had to be rewritten before a solver would take it, and the four places the code is wrong. The point is to be able to name the flaws before the interviewer does.
They are probing: whether the project on the page is something you built or something you ran.
Reading the depth badges
| Badge | What it asks of you | How you know you are done |
|---|---|---|
| Mechanism | Rebuild the explanation from a lower-level fact, without leaning on the vocabulary | You can answer the follow-up "but why does that happen" two more times |
| Predict | State the output, the shape or the row count before running the code | You get the predict-and-reveal blocks right without hedging |
| Fluent | Write it from memory at a normal typing speed | You reach for the right tool without pausing to consider three |
| Name only | One sentence, then move the conversation on | You do not look blank, and you do not overclaim |
The interactive widgets are the part worth slowing down for.
Reading that a boundary tick changes bin when you flip
closed is forgettable. Flipping it and watching two
bars change their open and close is not.
When you answer, give the mechanism before the conclusion. "A hash table files a key at a position computed once at insert time, so a key whose hash can change becomes unfindable" is a much stronger answer than "lists are mutable so they are unhashable", even though the second one is shorter and also correct. The first shows you could have derived it. The second shows you remembered it.
The checklist
Every line links to the section that covers it. Ticks are saved in this browser, so you can come back to it.