Algo Trading Developer

How Electronic Markets Work Core

Most trading today happens on electronic venues: exchanges, multilateral trading facilities and dark pools. Each venue runs a matching engine that holds resting orders and pairs buyers with sellers according to published rules. Participants connect through member firms or brokers, send orders over a session protocol, and receive market data that describes the state of the book.

Prices are set where supply meets demand. The best price someone will pay is the bid, the best price someone will sell at is the ask (or offer), and the gap between them is the spread. The midpoint between the two is the usual reference for a fair price. A stock may trade on many venues at once, so a trading system often sees fragmented liquidity and must decide where to route.

Participants differ in why they trade. Market makers quote both sides and earn the spread; liquidity takers cross it to trade now; the buy side trades to express investment views, and the sell side executes for clients.

Practice. Draw the path of one order from a strategy to an exchange and back, labelling every message and component.

Asset Classes and Instruments Core

Algorithmic trading covers several asset classes, each with its own conventions. Equities are shares in companies, traded on exchanges with corporate actions such as dividends and splits. Futures are standardised contracts to buy or sell later at an agreed price; they expire, so continuous price series must be stitched across contract rolls. Options give a right but not an obligation, and their value depends on volatility, time and the underlying price.

Foreign exchange trades mostly over the counter across many venues, around the clock on weekdays. Fixed income and credit trade more through dealers and request-for-quote systems, though electronic trading keeps growing. Crypto assets trade on venues that run all week and have their own data quirks.

Interviewers expect you to know the basic mechanics of at least equities and futures, including tick size, lot size, contract multiplier and settlement.

Practice. Pick one equity and one futures contract and write down tick size, trading hours, multiplier and how P&L is computed for each.

Returns, Prices and P&L Core

A simple return is (P1 − P0) / P0. A log return is ln(P1 / P0); log returns add across time, which makes multi-period maths easy, while simple returns add across assets in a portfolio. For small moves the two are close. Always use prices adjusted for splits and dividends when computing returns over time, or a two-for-one split looks like a 50 percent crash.

P&L has two parts. Realised P&L comes from closed trades. Unrealised or mark-to-market P&L values open positions at a current price, usually the mid or last trade. Fees, rebates, financing and borrow costs must be subtracted to get the real figure.

Practice. From a list of fills, compute realised and unrealised P&L with average cost accounting and check it against a hand calculation.

Order Types and Time in Force Core

A market order trades immediately at the best available prices and accepts whatever they are. A limit order sets the worst price you accept; if it cannot trade, it rests in the book and waits. A stop order becomes active only when the price reaches a trigger. Venues add variants: iceberg orders show only part of their size, pegged orders track the best price, and post-only orders are rejected if they would trade immediately, so a market maker never pays the taker fee by accident.

Time in force says how long an order lives. Day orders expire at the close, immediate or cancel (IOC) fills what it can and cancels the rest, fill or kill (FOK) fills completely or not at all, and good till cancelled stays until removed.

Practice. For each order type, describe one situation where it is the right choice and one risk of using it.

Probability and Expected Value Core

Probability is the language of trading: every decision is a bet with uncertain payoff. The expected value of a random outcome is the probability-weighted average of its values. A trade with positive expected value after costs is worth taking if the risk is acceptable; one with negative expected value is not, however exciting.

Learn the rules cold: complement, addition for mutually exclusive events, multiplication for independent events, and linearity of expectation, which holds even when variables are dependent. Linearity solves many interview puzzles in one line, for example the expected number of fixed points in a random permutation of n items is 1, because each position is fixed with probability 1/n.

Practice. Find the expected number of rolls of a fair die until you see a six, then the expected number until you have seen every face.

Conditional Probability and Bayes' Rule Core

Conditional probability P(A | B) is the probability of A once you know B happened. Bayes' rule reverses it: P(A | B) = P(B | A) P(A) / P(B). Trading uses this way of thinking constantly: how much should a large print on the tape change your view of where the price is going?

Classic interview questions test whether you ignore base rates. If a test for a rare condition is 99 percent accurate and the condition affects one person in a thousand, a positive result still means the person probably does not have it, because false positives from the large healthy group outnumber the true positives.

Practice. Solve the two-children problem in both of its common phrasings and explain why the answers differ.

Distributions, Variance and Fat Tails Core

Know the common distributions and when they appear: Bernoulli and binomial for counts of wins, Poisson for arrivals such as orders per second, normal for sums of many small effects, and exponential for waiting times. For each, know the mean and variance.

Variance adds for independent variables, so the standard deviation of a sum of n independent equal risks grows like the square root of n. This is why daily volatility is scaled to annual by multiplying by the square root of about 252 trading days. Covariance and correlation measure how two variables move together; correlation is covariance divided by both standard deviations.

Real returns have fat tails: extreme moves happen far more often than a normal distribution predicts, and volatility comes in clusters. Any risk model that assumes normality will understate the chance of a very bad day.

Practice. Simulate daily returns from a normal and from a Student t distribution with the same variance, and compare how often a four-standard-deviation day occurs.

Linear Regression for Quants Core

Ordinary least squares fits y = a + bx + error by minimising squared errors. In trading it measures a stock's beta to the market, the sensitivity of returns to a factor, or how well a signal predicts future returns. Know how to read the coefficient, its standard error and t-statistic, and R-squared.

Know the assumptions and how they fail on financial data: errors are not independent because returns overlap in time, variance changes over time, and outliers dominate the squared loss. Use standard errors that allow for autocorrelation and heteroskedasticity, winsorise extreme values, and be suspicious of a high R-squared on price levels, which is usually a spurious regression of two trending series.

Practice. Regress one stock's daily returns on an index's returns, report beta and its t-statistic, then repeat on prices and explain why that result is misleading.

Hypothesis Testing and Multiple Testing Core

A hypothesis test asks whether an observed effect is larger than chance would produce. The p-value is the probability of seeing a result at least this extreme if the null hypothesis, usually no effect, were true. It is not the probability that the strategy works.

The danger in research is multiple testing. If you try 100 random signals, about five will pass a 5 percent test by luck. Researchers who try many variants of parameters, universes and holding periods are running hidden multiple tests. Corrections such as Bonferroni, which divides the threshold by the number of tests, or false discovery rate control help, and a common practical rule is to demand a much higher t-statistic, around 3 rather than 2, for a new signal.

Practice. Generate 200 random signals on real returns, test each, count how many look significant, then apply a Bonferroni correction.

Time-Series Basics Core

Financial data is ordered in time, and most standard statistics assume it is not. A series is stationary if its statistical properties do not change over time. Prices are not stationary; returns are closer to it. Always model returns, spreads or other stationary transformations rather than raw prices.

Autocorrelation measures how a series relates to its own past. Daily stock returns show little of it, while volatility is strongly autocorrelated, which is why models such as GARCH forecast volatility better than returns. Mean-reverting series, such as the spread between two closely related assets, can be modelled with an autoregressive process, and the half-life of reversion tells you the useful holding period.

Overlapping returns, for example 20-day returns sampled daily, create autocorrelation by construction and make naive t-statistics far too large.

Practice. Compute the autocorrelation of daily returns and of absolute daily returns for an index and explain the difference.

Probability Brainteasers Core

Trading firms ask puzzles to watch you reason under uncertainty. Common families: dice games with an option to reroll, coin sequences, card draws without replacement, random points on a line or circle, gambler's ruin, and betting games where you must name a fair price.

A worked example: you roll a die and may take the number in pounds or roll once more and take the second result. On the second roll the expected value is 3.5, so you keep 4, 5 or 6 and reroll 1, 2 or 3. The value is (1/2)(5) + (1/2)(3.5) = 4.25. Another: the expected number of fair coin flips to see two heads in a row is 6, while heads then tails takes 4, because a failed attempt at HT never wastes the head you already have.

Practice. Solve ten puzzles from each family above, writing state equations for each, and explain two of them aloud to a friend.

Mental Maths and Market Making Games Core

Many firms test fast arithmetic without a calculator: two-digit multiplication, division to a few decimal places, percentages and fractions. Speed comes from tricks. 47 × 53 = 50² − 3² = 2491. 1/7 is about 0.1429, 1/8 is 0.125, and 1/9 is 0.111. To find 6 percent of 350, compute 1 percent (3.5) and multiply by 6.

Market making games are also common: the interviewer asks for a two-sided price on an uncertain quantity, such as the sum of three dice, then trades with you. Quote around your expected value (10.5 for three dice), widen the spread when uncertain, and update your quotes when the interviewer's trades reveal information. Explain your thinking as you go.

Practice. Do a daily timed drill of 80 mixed arithmetic questions and track your score and error rate for three weeks.

numpy Vectorisation Core

numpy stores data in contiguous typed arrays and runs operations in compiled code, so whole-array arithmetic is orders of magnitude faster than Python loops. Learn broadcasting, which combines arrays of different shapes without copying, boolean masks for filtering, and functions such as cumsum, diff, argsort and where.

Watch the details that bite in research: integer overflow in cumulative sums of large volumes, NaN propagation through sums and means, and floating-point comparison. Use nan-aware functions such as nanmean deliberately, not by habit, because silently skipping missing data can hide a data problem.

Practice. Compute cross-sectional ranks of a signal for each day in a dates-by-stocks array using only numpy, with no Python loop over dates.

pandas for Time Series Core

pandas is the workhorse for research data. The key skills are time-indexed data: resampling ticks to bars, rolling and expanding windows, shift for lags, and aligning series with different timestamps. merge_asof joins each trade to the most recent quote at or before its time, which is exactly what a point-in-time join needs.

Use a long format (date, symbol, value) or a wide format (dates as rows, symbols as columns) on purpose, and convert with pivot and stack. groupby on date gives cross-sectional operations such as ranking or demeaning; groupby on symbol gives per-asset time-series operations.

Be careful with time zones and with timestamps that mark the start or the end of a bar. The Python for Data Analysis Roadmap covers pandas in depth.

Practice.

# signal known at close t, traded from t+1
sig = px.pct_change(20)
fwd = px.pct_change().shift(-1)
ic = sig.rank(axis=1).corrwith(fwd.rank(axis=1), axis=1)

Explain why the forward return uses shift(-1) and what would go wrong without it.

Market Data and Point-in-Time Correctness Core

Research is only as good as its data. Market data comes as trades, quotes, and full order book updates; reference data covers symbols, corporate actions, index membership and trading calendars; fundamental data covers company accounts. Each has its own problems: bad prints, missing days, symbol changes and late corrections.

The key idea is point-in-time data: for every date, you must know only what was knowable then. Company results are published weeks after the period ends and are later restated; index membership changes; a dataset built today may silently include revisions. Store the time each value became available, not only the period it describes.

Practice. Build a daily universe table that records which symbols were tradable on each historical date, including ones that were later delisted.

SQL and Time-Series Storage Recommended

Trade records, orders, positions and reference data often live in relational databases, and research data in columnar files such as Parquet or in time-series databases. SQL is the shared language for querying them. You should write joins, aggregations and window functions comfortably, for example a running position per account with SUM OVER (PARTITION BY account ORDER BY time).

Columnar storage reads only the columns you need and compresses well, which suits wide market data tables. Partition data by date and symbol so that a query for one day does not scan years. For large research datasets, engines that run SQL over Parquet files on a single machine are often enough before you need a cluster.

Know how to check data quality with SQL: duplicates, gaps, and prices outside the day's range. The SQL Roadmap covers the language in depth.

Practice. Write a SQL query that computes each symbol's daily volume-weighted average price from a trades table using a window or group aggregate.

kdb+ and q Optional

kdb+ is a column-oriented time-series database widely used in trading for tick data, and q is its terse array language. You will meet it at many banks and trading firms for storing and querying billions of trades and quotes. Data is usually split into an in-memory real-time database for today and a date-partitioned historical database on disk.

Its strength is fast operations on ordered columns: as-of joins that attach the prevailing quote to each trade, time bucketing into bars, and aggregates over very large tables. q reads right to left and treats lists and tables as first-class values, so idioms look unfamiliar at first.

Practice. Describe in plain words how you would store a year of trades and quotes in a date-partitioned time-series database and query the VWAP for one symbol and day.

What Alpha Means Core

Alpha is return that cannot be explained by exposure to known, cheaply available risks such as the overall market. If a strategy earns 10 percent a year but simply holds the market with a beta of one, it has no alpha; you could buy an index fund. A signal has alpha when it predicts returns after removing those exposures and after paying realistic costs.

Every real edge has an economic reason: someone is willing to pay you, for example for immediate liquidity, for taking a risk they want to shed, or because of a behavioural bias or a structural constraint such as index rebalancing. If you cannot say who is on the other side and why, be very sceptical of a backtest.

Practice. For three well-known effects, write one sentence each on who is paying the return and why they might keep doing so.

Common Signal Families Core

Most signals fall into a few families. Momentum bets that recent winners keep winning over weeks to months. Mean reversion bets that short-term moves partly reverse, often over days or minutes. Value and other fundamental signals compare price with accounting measures. Carry earns the yield or roll of holding an asset. Statistical arbitrage trades the spread between related assets, as in pairs trading.

At short horizons, microstructure signals dominate: order book imbalance, the size and direction of recent trades, queue changes and the lead-lag between related instruments such as a future and its underlying shares. Alternative data, such as text or satellite measures, is used mostly at longer horizons.

Practice. Implement a 12-month minus 1-month momentum signal and a 5-day reversal signal on the same universe and compare their turnover.

Cross-Sectional and Time-Series Signals Core

A cross-sectional signal ranks assets against each other at the same moment: buy the top decile, sell the bottom decile. It is naturally market-neutral and predicts relative returns, so a market crash affects both sides. A time-series signal looks at one asset against its own history: go long when its trend is up, short when it is down. Trend-following in futures is the classic example.

The two need different evaluation. Cross-sectional signals are judged by how well the ranking predicts the next period's ranking of returns, day by day. Time-series signals are judged by the profit of each asset's position over time and are exposed to the overall direction of the market.

Practice. Build both a cross-sectional and a time-series version of a momentum signal and compare their correlation to the market.

Factor Models and Neutralisation Core

A factor model explains each asset's return as exposures to a few common factors, such as the market, sector, size, value and momentum, plus an asset-specific part. Factor models are used for risk, to decompose P&L, and to find out whether a new signal is just an old factor in disguise.

To test a signal for new information, neutralise it: regress the signal cross-sectionally on the factor exposures each day and keep the residual. If the residual still predicts returns, the signal adds something. If its predictive power disappears, you have rediscovered a known factor.

Practice. Neutralise your momentum signal against sector membership and beta and report how its information coefficient changes.

Information Coefficient and the Fundamental Law Core

The information coefficient (IC) is the correlation between a signal and the subsequent returns, usually computed cross-sectionally each period with ranks. Values look tiny: a daily IC of 0.02 to 0.05 can be valuable when applied across many stocks and days. Report the mean IC, its standard deviation and the IC information ratio (mean divided by standard deviation).

The fundamental law of active management approximates the information ratio as IC multiplied by the square root of breadth, where breadth is the number of independent bets per year. It explains why weak signals applied to many assets often beat strong signals on a few. Real bets are correlated, so effective breadth is smaller than the raw count.

Practice. Compute the daily rank IC of a signal for horizons of 1, 5, 10 and 20 days and plot the decay curve.

Alpha Decay, Turnover and Capacity Core

Alpha decay describes how quickly a signal's predictive power fades after it is computed. Fast-decaying signals must be traded quickly, which means high turnover, the fraction of the portfolio traded per period, and high costs. A signal with strong IC at one day but fast decay may lose to a weaker, slower signal once costs are included.

Capacity is how much capital a strategy can run before its own trading costs, mostly market impact, eat the edge. It falls with turnover and rises with the liquidity of the assets traded. Estimate it by simulating larger sizes with an impact model.

Practice. Estimate the break-even cost per trade for a signal by dividing its gross return by its turnover, and compare it with typical spreads.

Backtest Architecture Core

A vectorised backtest computes positions and returns for all dates at once with array operations. It is fast and ideal for early research on daily signals, but it makes it easy to use future data by accident and hard to model orders, partial fills and queue position.

An event-driven backtest replays data in time order through the same interfaces the live system uses: market data events go to the strategy, the strategy sends orders to a simulated exchange, and fills come back as events. It is slower but much closer to reality, and it lets research and production share strategy code.

Practice. Write a small event-driven loop with a data feed, a strategy, a simulated broker and a portfolio, and reproduce your vectorised results within a small tolerance.

Look-Ahead Bias Core

Look-ahead bias means using information in the simulation before it was available. Classic forms: computing a signal from today's close and trading at today's close, using a full-sample mean or volatility to normalise data, using restated fundamentals, using an index's current members for past dates, and joining data on the period it describes instead of the time it was published.

The symptom is a result that is too good: very high Sharpe, smooth equity curve, profits concentrated in the first minutes after events. The cure is discipline: lag every input explicitly, compute normalisations with expanding or rolling windows only, store publication timestamps, and test that shuffling future data does not change past decisions.

A simple guard is a unit test that truncates the data at date t and checks that the positions up to t are identical.

Practice. Add a deliberate one-day look-ahead to a strategy, record how much the Sharpe ratio rises, then write a test that would have caught it.

Survivorship and Selection Bias Core

Survivorship bias comes from testing only on assets that still exist today. Companies that went bankrupt, were taken over or were delisted vanish from many free datasets, so a backtest on today's index members silently avoids every failure and overstates returns, especially for strategies that buy cheap or falling stocks.

The fix is a point-in-time universe: for each historical date, include exactly the assets that were tradable and met your rules then, with delisting returns where available. Selection bias also appears when you choose the test period, the market or the asset list after seeing results.

Practice. Run the same strategy on a survivor-only universe and on a point-in-time universe and report the difference in annual return.

Data Snooping and Overfitting Core

Overfitting is tuning a strategy until it fits the noise of the past. Data snooping is the wider problem: every idea you try on the same history, and every idea others published from it, uses up the information in that data. A backtest that survived 500 trials is much weaker evidence than one that survived on the first try.

Defences: fewer free parameters, parameters chosen for economic reasons, results that are stable across nearby parameter values, a held-out period never touched during research, and reporting the number of trials. Adjusted measures such as the deflated Sharpe ratio estimate how high a Sharpe ratio needs to be given the number of variants tried.

Practice. Grid-search two parameters of a moving-average strategy, plot the Sharpe surface, and pick a setting from the plateau rather than the peak.

Walk-Forward Testing and Time-Series Validation Core

Random k-fold cross-validation leaks the future into the past for time-series data. Use walk-forward testing instead: fit on a window, test on the following period, roll forward and repeat, so every test result comes from a model that only saw earlier data.

When labels span time, such as 10-day forward returns, training samples near the test period overlap with test labels. Purging removes those samples from training, and an embargo leaves a gap after the test period before training resumes. Without them, validation scores are inflated.

Practice. Implement walk-forward validation with purging and an embargo for a 5-day forward return label and compare scores with plain k-fold.

Transaction Cost Modelling Core

Costs turn many good-looking signals into losers. Model them in layers. Explicit costs are commissions, exchange fees, rebates and taxes. Spread cost is paying half the bid-ask spread each time you cross it. Market impact is the price moving against you because of your own trading; a widely used approximation makes impact grow with the square root of trade size as a fraction of daily volume, scaled by volatility.

For passive strategies that post limit orders, model fill probability and adverse selection: your passive orders tend to fill just before the price moves against you. Ignoring this makes market making look far better than it is.

Short selling adds borrow costs and recall risk. Always report results gross and net of costs, and show how net performance changes if costs are doubled.

Practice. Add a spread plus square-root impact model to your backtest and plot net Sharpe as you scale the capital from small to large.

Performance Metrics Core

The Sharpe ratio is mean excess return divided by its standard deviation, annualised; for daily returns multiply the daily ratio by the square root of 252. It ignores the shape of losses, so also report the maximum drawdown (largest peak-to-trough fall), the Sortino ratio, which penalises only downside volatility, and the Calmar ratio of return to drawdown.

Add trading statistics: turnover, hit rate, average win against average loss, holding period, and P&L per unit traded. A strategy with a low hit rate can be excellent if wins are large; a high hit rate with rare huge losses is a warning.

Practice. Write a metrics function that reports annualised return, volatility, Sharpe, Sortino, maximum drawdown, turnover and hit rate for a daily P&L series.

Risk Measures Core

Volatility, the standard deviation of returns, is the basic risk measure. Value at risk (VaR) is the loss that should be exceeded only with a given small probability over a horizon, for example the one-day 99 percent VaR. It says nothing about how bad losses are beyond that point, so many teams also use expected shortfall, the average loss in the worst cases.

Compute these with historical simulation, a parametric model or Monte Carlo, and know each method's weakness: history may not contain the next crisis, and parametric normal models understate fat tails. Add stress tests that replay large historical moves or hypothetical shocks.

Practice. Compute one-day 99 percent historical VaR and expected shortfall for a portfolio, and compare with the normal-distribution estimate.

Covariance Estimation and Shrinkage Core

Portfolio risk depends on the covariance matrix of asset returns. With hundreds of assets and a few years of data, the sample covariance matrix is very noisy: it has far more parameters than the data can pin down, and its smallest eigenvalues are badly underestimated. Optimisers then exploit that noise and build portfolios that look low-risk but are not.

Shrinkage pulls the sample matrix towards a simple target, such as a constant-correlation matrix, trading a little bias for much less variance. Factor models reduce the problem to a few factor covariances plus specific risks. Exponentially weighted estimates react faster to changing volatility.

Practice. Compare realised volatility of minimum-variance portfolios built from the sample covariance and from a shrunk covariance on held-out data.

Portfolio Optimisation Core

Mean-variance optimisation chooses weights that maximise expected return minus a penalty on variance. In practice it is very sensitive to errors in expected returns, and unconstrained solutions often take extreme positions. Production systems add constraints: position and sector limits, neutrality to the market and factors, turnover limits and a cost term in the objective.

Simpler methods often work well: weight by signal divided by volatility, use inverse-volatility weights, or apply risk parity. The choice depends on how reliable your forecasts are.

Practice. Build a constrained optimiser with cvxpy or a similar library: market neutral, sector neutral, a turnover limit and a cost penalty.

Position Sizing and Volatility Targeting Core

Position sizing decides how much to trade on each signal. Volatility targeting scales positions so that each strategy or asset contributes a chosen risk, for example sizing each futures position to the same expected daily P&L volatility. It keeps risk steady when markets become calmer or wilder.

The Kelly criterion gives the bet size that maximises long-run growth; for a strategy with mean excess return mu and variance sigma squared, the full Kelly leverage is mu divided by sigma squared. Because the estimates are uncertain and full Kelly leads to deep drawdowns, practitioners use a fraction of it, often a half or less.

Practice. Simulate repeated bets at full, half and double Kelly and plot the distribution of final wealth and the worst drawdowns.

The Limit Order Book Core

The limit order book lists resting buy orders (bids) and sell orders (asks) by price. Each price level holds a queue of orders. An incoming order that crosses the spread trades against the opposite side, best price first; whatever remains, if it is a limit order, joins its own side of the book.

Market data describes the book at different depths. Level 1 shows the best bid and ask with sizes; Level 2 shows aggregate size at each price level; Level 3, or order-by-order data, shows each individual order with its own identifier, so you can rebuild the queue exactly.

Practice. Implement an order book that applies add, modify, cancel and trade messages and prints the top five levels after each update.

Matching Engines and Priority Rules Core

Most venues use price-time priority: better prices trade first, and among orders at the same price, earlier orders trade first. Changing an order's price or increasing its size usually sends it to the back of the queue; reducing size often keeps priority. Some futures markets use pro-rata allocation, splitting fills in proportion to resting size, which rewards large orders instead of being early.

Queue position is valuable in price-time markets: the first order at a price is likely to fill before the price moves away, and the last is likely to fill only when the price is about to move against it. This is why low latency matters for passive strategies.

Practice. Extend your order book into a matching engine with price-time priority, partial fills and IOC orders, and write tests for each case.

Market Data Feeds Core

Exchanges publish market data, usually as binary messages over UDP multicast, because one packet reaches every subscriber at once. Each message carries a sequence number. A feed handler decodes the messages, detects gaps in sequence numbers, recovers missing data from a retransmission service or snapshot, and builds the book for the strategy.

Venues often publish two identical feeds on separate networks, A and B; the handler takes whichever copy arrives first and uses the other to fill gaps. Timestamps from the exchange, the network card and the application let you measure delay at each stage.

Practice. Write a decoder for a simple binary message format, add gap detection with a recovery request, and test it with dropped and reordered packets.

The FIX Protocol Core

FIX (Financial Information eXchange) is the standard text protocol for orders between firms, brokers and many venues. Messages are lists of tag=value fields separated by the SOH character. Tag 35 gives the message type: D is a new order, F a cancel request, G a cancel/replace, 8 an execution report, A a logon and 0 a heartbeat. Other common tags are 11 (client order ID), 54 (side), 38 (quantity), 44 (price) and 39 (order status).

A FIX session handles logon, heartbeats, sequence numbers and resending missed messages; the application layer handles orders. Many exchanges also offer faster binary protocols for order entry, but FIX remains the common language for brokers and clients.

Practice.

8=FIX.4.4|35=D|49=CLIENT|56=BROKER|34=12|11=ord-001|
55=XYZ|54=1|38=500|40=2|44=101.25|59=0|10=123|

Decode this new order message field by field, then write the execution reports for a partial fill and a final fill.

Order Lifecycle and Order Management Core

An order passes through states: pending new, new (acknowledged), partially filled, filled, pending cancel, cancelled, replaced or rejected. An order management system tracks each order's state, the quantity still working and the fills, and keeps positions in step. It must handle messages arriving in surprising orders, for example a fill that arrives after you sent a cancel.

Model the order as an explicit state machine with allowed transitions, and treat any unexpected transition as an alert. Use unique client order IDs, persist state so a restart does not lose working orders, and reconcile against the venue's view at start of day and after any disconnection.

Most trading incidents are not clever strategy failures. They are state bugs: duplicated orders, lost cancels and positions out of sync.

Practice. Write an order state machine with tests for cancel-fill races, rejects and replace requests that arrive after a full fill.

Execution Algorithms: TWAP, VWAP and POV Core

Execution algorithms split a large parent order into many small child orders to reduce impact. TWAP trades evenly over time: 10,000 shares over 100 minutes means about 100 a minute. VWAP follows the market's typical volume profile across the day, trading more at the open and close, so the average price tracks the volume-weighted average price. POV (percentage of volume) trades a fixed fraction of the volume actually observed.

Good implementations add randomness to size and timing so they are less predictable, choose between passive and aggressive child orders based on urgency and book state, and respect limit prices and participation caps.

Practice. Implement TWAP, VWAP and POV schedulers in your simulator and compare their average price and completion time on the same day of data.

Implementation Shortfall and Transaction Cost Analysis Core

Implementation shortfall measures the cost of executing a decision: the difference between the price when the decision was made (the arrival price) and the average price actually achieved, plus the cost of any part not executed. It exposes the trade-off at the heart of execution: trading fast increases impact, trading slowly increases risk that the price drifts away.

Optimal execution models, such as the Almgren-Chriss framework, choose a trading schedule that balances expected impact cost against the variance of the outcome, given a risk aversion. More urgent orders trade faster.

Practice. For a set of simulated parent orders, compute implementation shortfall and VWAP slippage in basis points and plot them against order size.

Market Making and Adverse Selection Recommended

A market maker quotes a bid and an ask and hopes to buy at the bid and sell at the ask many times. The risks are inventory risk, holding a position while the price moves, and adverse selection, trading with someone who knows more, so fills tend to come just before the price moves against you.

Basic models set quotes around a fair value, then skew them according to inventory: if you are long, lower both quotes to encourage selling. Spreads widen when volatility rises or when informed flow is likely. Fair value often uses the microprice or a short-horizon signal rather than the plain mid.

Practice. Simulate a simple market maker with inventory skew on historical data and measure P&L, inventory and the average price move after each fill.

Trading System Architecture Core

A typical trading system has a clear pipeline: feed handlers decode market data and build books; a strategy engine reacts to book updates and computes orders; an order gateway applies risk checks and speaks the venue protocol; a position and risk service tracks exposures; and logging, monitoring and reference data services sit around them.

Latency-sensitive paths keep everything in one process on dedicated cores, passing messages through shared-memory queues, and avoid locks, allocation and system calls on the hot path. Slower components, such as dashboards and databases, are kept off that path and fed asynchronously.

Practice. Draw the architecture of a small trading system with five components and mark which paths are latency-critical and which are not.

Modern C++ for Low Latency Core

Low-latency C++ is ordinary modern C++ used with discipline. Avoid heap allocation on the hot path by preallocating object pools and using fixed-capacity containers. Prefer value types and contiguous storage such as std::vector and std::array over node-based containers like std::map and std::list, which scatter data across memory.

Use templates and compile-time dispatch, including constexpr and the curiously recurring template pattern, instead of virtual calls where it matters. Know move semantics, so large objects are not copied, and know which standard library calls may allocate or throw. Avoid exceptions on the hot path; many teams disable them there entirely.

Measure before changing anything, and keep the code readable: the fastest code that nobody can review is a liability. The Modern C++ Roadmap covers the language in depth.

Practice. Rewrite an order book that uses std::map of std::list into one built on flat arrays and a free list, and benchmark both on the same message stream.

CPU Caches and Memory Layout Core

A modern CPU core can do a great deal of work in the time one main-memory access takes, so cache behaviour often decides performance. Data moves in cache lines, typically 64 bytes. Keep hot data small and contiguous, put fields used together next to each other, and lay out arrays so loops walk memory in order.

False sharing happens when two threads write to different variables on the same cache line: the line bounces between cores and both slow down. Fix it by aligning such variables to separate cache lines, for example with alignas(64).

Practice. Benchmark two threads incrementing adjacent counters, then align them to separate cache lines and measure the change.

Lock-Free Queues and Concurrency Core

Threads in a trading system pass messages without locks where latency matters. The workhorse is the single-producer single-consumer ring buffer: a fixed array with a head index written only by the consumer and a tail index written only by the producer. With the right atomic memory ordering, each side needs only a load and a store.

Use release ordering when publishing a slot and acquire ordering when reading the index, so the data is visible before the index change. Put the two indices on separate cache lines. Multi-producer queues are harder and slower; avoid them by design where you can.

Practice.

bool push(const T& v) {
  auto t = tail_.load(std::memory_order_relaxed);
  auto n = (t + 1) & mask_;
  if (n == head_.load(std::memory_order_acquire)) return false;
  buf_[t] = v;
  tail_.store(n, std::memory_order_release);
  return true;
}

Write the matching pop function, explain each memory order, and stress-test the queue with a sanitiser.

Linux Tuning for Trading Core

Trading servers are tuned to make latency low and, just as important, predictable. Common steps: isolate cores from the scheduler with isolcpus or cgroups, pin each critical thread to its own core, keep interrupts away from those cores, disable deep power-saving states and frequency scaling, and use huge pages to reduce translation lookaside buffer misses.

Hot threads often busy-poll, spinning on a queue instead of sleeping, which costs a whole core but avoids wake-up delay. Memory is allocated and touched at start-up so page faults do not occur during trading. NUMA placement keeps threads near their memory and network card.

Learn the tools: perf for profiling, strace for system calls, and the proc and sys file systems for configuration. The Linux Roadmap covers the operating system in depth.

Practice. Pin a benchmark thread to an isolated core and compare its latency percentiles with an unpinned run under background load.

Networking and Kernel Bypass Recommended

The normal Linux network stack is general and safe, but each packet passes through interrupts, kernel buffers and system calls, which adds microseconds and variable delay. Kernel bypass lets an application read and write packets directly from the network card's memory in user space, avoiding most of that work. Vendors provide libraries that offer familiar socket interfaces over bypass, and frameworks such as DPDK expose the raw approach.

Firms also colocate servers in the exchange's data centre, choose network cards with hardware timestamping, and in the most latency-sensitive cases move parts of the logic into FPGAs.

For interviews, know the concepts: why multicast UDP for data and TCP for orders, what Nagle's algorithm does and why it is disabled with TCP_NODELAY, and where time goes between a packet arriving and an order leaving.

Practice. Measure the round-trip latency of a small TCP echo between two processes with and without TCP_NODELAY, sending messages in quick pairs, and explain the difference.

Measuring Latency Core

Averages hide the problems that matter in trading. Report latency as a distribution: median, 99th, 99.9th percentile and maximum, using histograms recorded without slowing the hot path. A system with a low median and occasional long stalls can lose money exactly when markets are busiest.

Measure with the right clock: the CPU timestamp counter for short intervals inside a process, and hardware timestamps from the network card for wire-to-wire latency, the time from a market data packet arriving to the resulting order leaving. Synchronise clocks across machines with PTP when comparing their timestamps.

Practice. Instrument a small event loop with timestamp counters, record a histogram of a million iterations, and report the 50th, 99th and 99.9th percentiles.

Data Structures for Trading Core

The order book is the central data structure. Price levels can be stored in a sorted array or a fixed array indexed by price ticks around the current price, which gives constant-time access; individual orders live in a pool, found through a hash map keyed by order ID, and linked in time order within each level.

Other daily structures: ring buffers for queues and rolling windows, heaps for timers and scheduled events, and hash maps with open addressing for symbol lookups. Interviewers ask you to implement these and to explain both big-O cost and cache behaviour, because a tree with good complexity can be slower than a scanned array for small sizes.

Rolling statistics, such as a moving average or variance updated in constant time per tick, are a classic question. The Data Structures and Algorithms Roadmap covers the fundamentals in depth.

Practice. Implement a rolling mean and variance over the last N ticks with constant time per update and test it against a direct calculation.

Pre-Trade Risk Checks and Kill Switches Core

Every order must pass pre-trade risk checks before it reaches a venue: maximum order size and value, price collars that reject prices far from the market, position and exposure limits, order rate limits and checks for duplicate orders. These checks sit in the order path, so they must be fast, but correctness comes first.

Add kill switches that cancel all orders and stop a strategy when P&L, position or message rates cross thresholds, and a manual control that operators can trigger at once. Test the kill path regularly, since a control that has never been exercised may not work when needed.

Software errors in trading have caused very large losses within minutes. Treat risk code with the care of safety-critical software: simple, reviewed, tested and independent of strategy code.

Practice. Add order size, price collar, position and rate checks to your order gateway, then write tests that each limit rejects the right orders.

Testing, Simulation and Deployment Core

Trading code needs layers of testing: unit tests for parsers, books and risk checks; replay tests that feed recorded market data and compare outputs with a known-good run; simulation against an exchange simulator that models acknowledgements, fills and rejects; and conformance testing against each venue's test environment.

Deploy carefully. Release outside market hours, roll out to one strategy or a small size first, keep the previous version ready to restore, and watch rejects, fills and P&L closely after the change. Configuration changes, such as limits and symbol lists, deserve the same review as code.

Practice. Build a replay test that runs a day of recorded data through your strategy and fails if any order differs from the stored reference output.

Quant Developer, Researcher and Trader Roles Core

The field has three overlapping roles. A quant researcher finds and validates signals; interviews stress statistics, probability and research judgement. A quant developer or trading engineer builds research platforms, backtesters and production systems; interviews stress coding, C++ or Python depth and system design, plus some probability. A quant trader manages strategies and risk in real time; interviews stress fast mental maths, betting games and decision-making.

Low-latency developers form a specialist group whose interviews go deep into C++, Linux and networking. Execution developers sit closer to brokers and clients and are asked more about algorithms such as VWAP and about FIX.

Practice. Write one paragraph on which role suits you and list the three interview areas you will spend most time on.

Presenting Projects and Research Core

Interviewers will dig into your projects until they find the edge of your understanding. Prepare two or three stories in depth: the problem, the data, the design choices, the numbers and what went wrong. For research, describe the hypothesis, the tests, the biases you guarded against and the result after costs. For systems, describe the latency budget, how you measured it and the hardest bug.

Honesty scores well. Saying a strategy did not survive costs, and explaining why, shows more skill than claiming a Sharpe of five. Never overstate results; interviewers will ask how you avoided look-ahead bias and will notice if you did not.

Practice. Write a one-page summary of your best project with the numbers and three likely follow-up questions with answers.

Conduct, Compliance and Market Rules Recommended

Trading is regulated, and developers share responsibility for the systems that send orders. Know the basic ideas: market abuse rules forbid manipulating prices, for example by placing orders you intend to cancel to mislead others, which is called spoofing; firms must keep accurate records of orders and communications; and automated trading usually requires controls such as pre-trade limits, testing and the ability to stop trading quickly.

You do not need to be a lawyer, but you should recognise when a design or strategy could look abusive and ask compliance before building it. Firms also have rules on personal trading and confidential information.

Practice. List the controls you would expect around an automated strategy before it trades live, and explain which risk each one addresses.