Courses

Programming for Quantitative Developers

IntermediatePremium7 sections · 33 lessons · 79 questionsLog in to track progress

Almost every quantitative developer application starts the same way: an auto-graded online assessment, two to four problems, sixty to a hundred and twenty minutes, on HackerRank or Codility or CodeSignal. Nobody reads your code at that stage. A test harness runs it against inputs you never see and returns a number.

That format decides what is worth practising, and it is not what a generic algorithms course teaches. It rewards a solution that is correct on the empty input and the single-element input, that holds its complexity bound when the input is a hundred times larger than the example, and that can be written in twenty minutes rather than sketched in an hour. Later rounds invert the emphasis completely: a human reads the same code and asks what happens when a requirement changes.

This course covers the Python side of that pipeline. It opens with what the hiring funnel actually looks like at the top trading firms, including which of them ban Python outright, then works through the material the assessments keep returning to: the data structures you are expected to implement rather than import, the parsing and data-hygiene problems that generic platforms never set, algorithms chosen against an explicit complexity bound, the numerical Python that survives a review, and finally order books and matching, which is the one domain problem these firms ask and nobody else does.

Its companion, Systems Programming for Trading, covers the C++ half: internals, concurrency, and compile-time programming. Start here if you are preparing for an assessment in the next month, and there if the role says C++ on the hot path.

Every lesson ends with the problems from our coding catalogue that drill it, so the theory and the keyboard stay in the same session.

The Online Assessment FunnelWhat the developer pipeline looks like at top trading firms, and why the first stage is a machine rather than a person.Free previewWhat the Graders Actually CheckHidden tests, complexity bounds and the phrase 'suboptimal solutions fail': what an auto-grader measures, and what it cannot see.Free previewThe Take-Home AssignmentOne problem, an evening or a few days, and an engineer who reads your code after the tests pass: how take-homes are marked and what to hand in.Defending a Project You BuiltThe project deep dive: how interviewers follow one decision down until they reach the edge of what you know, and how to prepare so they find depth there.The Extension RoundOne problem, extended requirement by requirement for an hour: how to write the first version so that each new requirement touches as little code as possible.
Writing Code Someone Else Will ReadWhy the fastest route through an assessment is also the readable one, and what interviewers mean when they say they read your code after the tests pass.The Shape of a Good SolutionA repeatable order of operations for an assessment problem: constraints, examples, invariant, code, edges. Fifteen minutes of thinking that saves forty.
Arrays, Nodes and the Cost of a PointerContiguous storage against linked storage, the ring buffer that firms keep asking for, and why the answer is almost always the array.Hash Maps From the InsideA staple depth probe: explain how a hash map works. Buckets, collisions, load factor and the two resolution strategies, with the trade nobody mentions.Heaps and Priority QueuesThe binary heap as an array, why decrease-key is the interesting half, and the scheduling problems that are heap problems in disguise.Caches: LRU, LFU, and What They Are Really TestingThe most-asked composite structure in the industry. Two containers cooperating, the invariant that keeps them agreeing, and the extension that always follows.
Parsing a Message StreamFraming, fixed-width fields and binary decoding, plus the throughput trap that fails candidates on the last test case rather than the first.Cleaning a Feed You Did Not WriteDuplicates, gaps, corrupted rows and impossible values. What repair means when you cannot ask the sender, and why the policy is the answer.Replaying a Log in OrderTimestamps tie, clocks disagree, and two feeds carry the same messages. How to define an order and reproduce a state exactly.
Reading the ConstraintsFrom the input bound to the target complexity to the technique, in that order. The four trades that get you from the obvious solution to the intended one.Windows, Prefixes and Monotonic StacksThree linear-time patterns that cover most single-array problems, and the question that tells you which one you are looking at.Intervals and Sweep LinesInterval problems turn up at firm after firm. One transformation solves nearly all of them, and the tie-break decides whether you pass.Graphs, Trees and SearchThe three graph traversals worth having ready, tree dynamic programming in one recurrence, and the moment a problem is a graph without saying so.Dynamic Programming: The State You CarryThe two questions that define every DP, counting and game problems from the reported set, and the recursion limit that decides memoise versus tabulate for you.Talking Through Complexity in a Live RoundWhat to say about time and space, and when: sizes first, the obvious cost, the trade, then the result you can defend.
Vectorising Without Losing the PlotWhy a Python loop is slow, what a vectorised expression actually does, and the two cases where the loop is the right answer anyway.Time Series Alignment and LookaheadThe bug that produces beautiful results: using information the moment could not have had. Asof joins, point-in-time universes and back-adjusted prices.A Trade Blotter, End to EndFrom a list of fills to a position, an average price and a P&L split into realised and unrealised. The accounting choice that changes the answer.Monte Carlo That ConvergesThe square-root law that governs every simulation, why doubling paths barely helps, and the three ways to buy accuracy more cheaply.Numbers That Do Not LieFloating point that loses digits, a variance formula that cancels catastrophically, and estimators that quietly answer a different question.What CPython Does With Your ObjectsEvery value is a heap object and every name is a reference. Why a list of floats is four times the size of an array, and the four surprises that follow.Threads, Processes and the GILWhy threads do not speed up Python arithmetic, why they still help with waiting, what the GIL does not protect, and what it costs to move work into another process.asyncio and the Event LoopMany network waits on one thread: how coroutines take turns, the blocking call that stalls all of them, races at every await, and cancellation that gets swallowed.Streaming Statistics in Constant MemoryA rolling mean and variance updated in O(1) per value: running sums over a circular buffer, the rounding error they collect, the exponentially weighted version, and what cannot be done in constant time.
What an Order Book Really IsThe signature domain problem of the quant developer interview, described as a data structure: what it stores, what it must answer quickly, and what the interviewer is checking.Price-Time Priority in CodeThe matching loop, the price the trade prints at, and the two allocation rules that produce completely different code from the same order flow.Cancels, Amends and the State MachineThe half of an order book that is not matching: an order's lifecycle, which amendments keep queue position, and the race every real system has.Designing the Objects: an OMS and an AuctionThe reported design round, where the requirements change while you watch. How to choose objects that can absorb the next requirement.

Keep reading Programming for Quantitative Developers

33 lessons in this course, and every other premium course, on one subscription.

Subscribe now
  • Every lesson in every course, with the worked examples and interactive simulators
  • Graded questions on every lesson, with explanations for the wrong answers as well as the right one
  • The trainers, timed assessments and brainteaser library that go with them