Design a Backtesting Framework

A quick note on where this one lives before you prep it. There is no whiteboard round at Jane Street where someone asks you to architect a backtester for a billion users. This is trading-systems reasoning, the kind that surfaces in a senior or systems-role project discussion, or as research-infrastructure literacy woven into a coding round. So treat what follows as the shape of a good answer when the conversation turns to "how would you build the thing that decides whether a strategy is worth running." It is no boxes-and-arrows exam.

A strategy earns real capital only once the firm believes what it did on history, and a backtest exists to build that belief honestly. You take a candidate strategy and feed it recorded market data as though the past were streaming by again. It places the orders it would have placed. You simulate which of those would have filled and at what price, and tally the money. The output is a judgment: over these years and these instruments, this idea made or lost this much, at this risk. Every design decision below serves that judgment being trustworthy rather than flattering.

Two pressures shape the framework before a single box goes on the board, and they lean opposite ways. The first is fidelity. The simulation has to behave the way the live market would, and the quietest failure is the dangerous one: letting the strategy read something that did not exist yet when it acted. A backtest that is generous in ways the market will not be is worse than having none, because it hands you the confidence to deploy a loser. The second is scale. A single liquid name throws off hundreds of thousands of quote and trade updates on a normal day. Once options chains enter the picture, the instrument count alone runs into the hundreds of thousands. A full run over several years reaches the hundreds of billions of events. Underneath both sits a third demand that Jane Street weights unusually heavily. The same run has to reproduce exactly.