Algo Trading Developer Interview Questions

Six. The number of rolls is geometric with success probability 1/6, and a geometric variable has mean 1/p.

A neat way to show it without the formula is a one-step recursion. Let E be the expected number of rolls. You always spend one roll; with probability 1/6 you stop, otherwise you are back where you started. So E = 1 + (5/6)E, which gives E/6 = 1 and E = 6.

Interviewers like the recursion because it generalises: the same trick handles expected tosses until two heads in a row, gambler's ruin and most stopping problems. Say the structure aloud (state, one step, condition on the outcome) and the arithmetic follows.

Likely follow-up. What is the expected number of rolls to see every face at least once?

Two heads in a row takes 6 tosses on average; heads then tails takes 4.

For HH, define states by progress: E0 from scratch and E1 after one head. E1 = 1 + (1/2)(0) + (1/2)E0, because a head finishes and a tail sends you back to the start. E0 = 1 + (1/2)E1 + (1/2)E0. Solving gives E0 = 6. For HT, once you have a head you never lose progress: a further head still leaves you one step away. So E1 = 2 and E0 = 2 + 2 = 4.

The point interviewers want is why they differ even though each pattern has probability 1/4 per pair: HH can overlap with itself, so failures throw away progress. This self-overlap idea appears again in pattern-matching games and in Penney's game.

About 0.518. Use the complement: the chance of no six in four rolls is (5/6) to the fourth power, which is 625/1296, so the answer is 671/1296.

For mental arithmetic, 625/1296 is a little under 0.5 because 1296 is just over twice 625 (1250). So the answer is a little over a half. Getting from 0.48 to 0.518 quickly is what the interviewer is checking, not long division.

The complement trick is the default whenever a question says at least one. A common mistake is to add 4 times 1/6 and get 2/3, which ignores overlaps and breaks as soon as the number of rolls grows past six.

Likely follow-up. How many rolls do you need for the chance of at least one six to pass 90%?

I centre the quote on the expected value, 7, and set the width from the uncertainty and my risk appetite. The variance of one die is 35/12, so the sum has variance 35/6, roughly 5.83, and a standard deviation of about 2.4.

A sensible opening is something like 6.5 at 7.5: tight enough to be useful, wide enough that a single informed trader does not hurt me badly. If the interviewer buys at 7.5 and keeps buying, I ask myself whether they know something, for example that they will choose which dice count, and I move my quote up. If they reveal information (one die shows a 5), I update: the expectation becomes 5 + 3.5 = 8.5 and the variance halves.

What is being tested is the trading loop: estimate fair value, quote around it, learn from the flow, and manage inventory. Saying nothing until you are sure is the wrong behaviour in this game.

Likely follow-up. You are long ten contracts after buying at 7.5. Do you shade your bid or your offer?

About 9%, assuming 99% means both a 99% true positive rate and a 1% false positive rate.

Use counts, which is faster and less error-prone than the formula. Out of 100,000 people, 100 have the condition and 99 of them test positive. Of the 99,900 without it, 1% test positive, which is 999. So among 1,098 positives only 99 are true, a little over 9%.

The trading version of this is a signal that fires rarely. A detector of informed flow that is right 99% of the time can still produce mostly false alarms if informed flow is rare. The base rate dominates, and that is why research teams always ask what the unconditional frequency of the event is before they get excited about a classifier's accuracy.

About 0.62. Correlations behave like cosines of angles between vectors, so the question is how far apart two vectors can be if each is within the angle whose cosine is 0.9 of a third.

The bound is rho_AC at least rho_AB times rho_BC minus the square root of (1 minus rho_AB squared) times (1 minus rho_BC squared). With 0.9 and 0.9 that is 0.81 minus 0.19, which is 0.62. It comes from requiring the 3 by 3 correlation matrix to be positive semi-definite.

The practical lesson: correlation is not transitive in a loose sense. Two signals that are each highly correlated with a benchmark can still differ meaningfully from each other, and when you build a correlation matrix by hand (for stress tests, say) you must check it is positive semi-definite or your risk model will return negative variances.

Likely follow-up. What happens to the lower bound if both correlations are 0.5?

The Kelly fraction is 20%: f = p minus q divided by the odds, which is 0.6 minus 0.4 over 1. Kelly maximises the expected logarithm of wealth, which maximises long-run growth.

I would say the answer and then qualify it. Full Kelly has large drawdowns and assumes you know p exactly. If your estimate of the edge is noisy, betting full Kelly on an overestimate cuts growth sharply, and betting twice Kelly gives zero expected growth. Practitioners usually bet a fraction of Kelly, often half, which gives up a little growth for much lower volatility.

In portfolio terms, Kelly sizing for a single strategy is roughly expected excess return divided by variance. That links directly to mean-variance sizing, and is a good bridge into the portfolio questions that usually follow.

About 15.9. Since 16 squared is 256, the root of 252 is a little less than 16; a first-order correction gives 16 minus 4/32, which is 15.875.

It matters because 252 is the usual count of trading days in a year, and under independent returns volatility scales with the square root of time. A daily volatility of 1% is about 16% annualised, and a daily Sharpe ratio of 0.1 is about 1.6 annualised. Interviewers expect you to move between daily and annual figures in your head.

Mention the caveat: the square-root rule assumes returns are uncorrelated over time. Trending or mean-reverting returns break it, which is one reason to estimate volatility at the horizon you actually trade.

The probability of reaching N is 1/N, and the expected duration is N minus 1 steps.

For the probability, a fair walk is a martingale, so its expected value at the stopping time equals its starting value. The stopped value is N with probability p and 0 otherwise, so pN = 1. For the duration, use the martingale X squared minus t: its expectation at stopping equals 1, so pN squared minus E[T] = 1, giving E[T] = N minus 1. In general, starting at k, the duration is k times (N minus k).

This is the gambler's ruin problem. In trading it is a reminder that a strategy with zero edge and a finite bankroll eventually ruins you against a much larger counterparty, and the optional stopping argument is the tool interviewers want to see.

Likely follow-up. How does the probability change if the coin is biased?

A p-value is the probability, assuming the null hypothesis is true, of seeing a test statistic at least as extreme as the one observed. A small value means the data would be surprising under the null.

It does not tell you the probability that the null is true, it does not measure the size of the effect, and it says nothing about whether the effect is economically useful after costs. A strategy can have a tiny p-value and a return that disappears once you pay the spread.

In research the biggest trap is that p-values assume you ran one pre-planned test. If you tried two hundred signal variants and report the best, the nominal p-value is far too optimistic. I would mention multiple testing straight away, because that is where the interviewer is heading.

Only marginally. Under independent, roughly normal returns, the t-statistic of the mean return is about the annualised Sharpe ratio times the square root of the number of years, so 1.0 times 2 gives a t of about 2.

That is borderline at the usual 5% level for a single test, and weak if this strategy was one of many tried. Fat tails, autocorrelation and regime changes widen the real uncertainty further. A rough standard error for an estimated annual Sharpe is about 1 over the square root of the years observed, so four years gives a confidence band of roughly plus or minus 1.

I would say four years of daily data sounds like a lot of observations, but for the mean it is the calendar span that matters, not the number of samples. That is why short-horizon strategies with many independent bets reach significance faster than monthly rebalanced ones.

Likely follow-up. How long a track record would you need to be confident that a Sharpe of 0.5 is positive?

I control for multiple comparisons and, more importantly, keep the testing process honest.

On the statistical side, Bonferroni divides the significance level by the number of tests and controls the chance of any false positive; it is simple but very conservative when tests are correlated. Holm's step-down method is uniformly better. For research, where I expect several true effects, controlling the false discovery rate with Benjamini and Hochberg is usually the better target. For Sharpe ratios specifically, you can deflate the best observed Sharpe for the number of trials and the variance across trials.

On the process side, I record every variant I try, keep a final hold-out period that nobody touches until the end, and prefer signals with an economic story so the hypothesis comes before the data. The count of trials is the input everyone forgets to log, and without it no correction is possible.

If you regress 20-day forward returns on a daily signal, consecutive observations share 19 days of the same return, so the residuals are strongly autocorrelated. Ordinary least squares standard errors assume independent residuals and come out far too small, which makes t-statistics look much better than they are.

Fixes, in order of preference: sample non-overlapping observations (every 20th day) as a sanity check; use heteroscedasticity and autocorrelation consistent standard errors such as Newey and West with a lag window at least as long as the overlap; or bootstrap in blocks longer than the overlap so the dependence is preserved.

The point estimate of the slope is usually fine. It is the confidence you attach to it that is wrong. I would also check whether the effective number of independent observations is large enough to say anything at all.

It means extreme moves are much more frequent than a normal distribution predicts, so any method that leans on normality underestimates risk and overstates confidence.

Concretely: value at risk from a normal model is too small in the tails, so I prefer historical or filtered historical simulation and look at expected shortfall too. Sample means and variances are dominated by a few days, so I report results with and without the largest days and use rank-based statistics such as Spearman correlation for signal evaluation. In regressions I winsorise or clip inputs at sensible levels so a single bad tick does not set the coefficient.

Volatility also clusters, so returns are closer to normal once scaled by a conditional volatility estimate. Scaling positions by recent volatility is one of the simplest and most useful responses to fat tails.

Likely follow-up. How would you test whether a return series is normal?

A series is weakly stationary if its mean, variance and autocovariances do not change over time. Prices are generally not stationary; returns are closer.

Pairs trading relies on a spread between two prices being stationary, so that deviations revert. Two non-stationary prices whose linear combination is stationary are cointegrated. The usual test is to estimate the hedge ratio by regression and test the residual for a unit root, or to use a Johansen test for more than two series. A high correlation of returns is not enough: two random walks can have correlated returns while their spread drifts without bound.

The practical risks are that the hedge ratio itself drifts, that the half-life of reversion is too long to trade after costs, and that the relationship breaks after a structural event such as a merger. I would estimate the half-life, check stability on rolling windows, and set a stop for when the spread exceeds anything seen in the fitting window.

I check the assumptions that matter most for financial data and look at stability rather than a single fit.

First, multicollinearity: if factors are highly correlated, coefficients become unstable and can flip sign while the fit barely changes. I look at the correlation matrix and variance inflation factors, and consider orthogonalising or using ridge regression. Second, heteroscedasticity and autocorrelation, which bias the standard errors; I use standard errors that allow for both, or errors clustered by date in a panel. Third, outliers, which I handle by winsorising inputs.

Then stability: rolling or expanding window estimates, subperiod splits and out-of-sample predictive performance. A coefficient that only holds in one regime is a description of history rather than a model. Finally I check the economic size: a significant coefficient that implies a return smaller than trading costs is not useful.

A cross-sectional signal ranks assets against each other at the same time: which stocks will outperform the others tomorrow. A time-series signal predicts one asset's own future return from its history: will this future go up or down.

They are built and judged differently. Cross-sectional signals are usually traded as long-short portfolios that are neutral to the market, so the market's direction drops out and what matters is the ranking; they are evaluated with rank information coefficients across many assets each day. Time-series signals, such as trend following, take directional exposure and are evaluated on the timing of each asset's own return.

A momentum effect can exist in both forms, and they behave differently: cross-sectional momentum is a bet on relative winners, while time-series momentum can be long everything in a rising market. Being clear which one you mean is the first thing an interviewer checks.

The information coefficient is the correlation between a signal and the subsequent returns it is trying to predict, usually measured cross-sectionally each period and then averaged. Most teams use the rank (Spearman) version so a few extreme names do not dominate.

Typical values for a daily equity signal are small, often a few hundredths. That sounds tiny, but across hundreds of stocks and many periods it can support a useful strategy. What matters as much as the mean is its consistency: I look at the mean IC divided by its standard deviation over time, the fraction of periods with positive IC, and how IC decays as the forecast horizon lengthens.

A high IC on a small or illiquid universe is less useful than a lower IC on names you can trade cheaply, so I would always quote it alongside the universe and the horizon.

Likely follow-up. How does IC relate to the expected information ratio of a strategy?

It says the information ratio is roughly the information coefficient times the square root of breadth, where breadth is the number of independent bets per year. A small IC applied to many independent bets can give a good information ratio.

The limits are in the word independent. Five hundred stocks traded daily are not 126,000 independent bets a year, because stocks share sector and market exposures and signals persist from day to day. Breadth is usually much smaller than a naive count. The law also ignores transaction costs and constraints: a transfer coefficient term is often added to show how much of the ideal signal survives position limits and neutrality constraints.

I use it as a way of thinking rather than a calculation: it explains why a slightly better IC on a broad universe can beat a much higher IC on a narrow one, and why diversifying across uncorrelated signals helps.

I regress the signal's portfolio returns on known factor returns (market, size, value, momentum, low volatility, industry) and see how much return is left in the intercept. I also neutralise the signal itself cross-sectionally against factor exposures and re-measure its IC.

If the signal's returns are mostly explained by momentum, say, it is not new alpha; it is an expensive way of getting a factor I can buy more cheaply. The residual IC after neutralisation and the intercept of the regression are the honest measures of novelty.

I would also check correlation with the team's existing signals, because the useful question in a real team is incremental value: does adding this improve the combined forecast after costs. A signal with modest standalone performance but low correlation to everything else can be worth more than a strong one that duplicates what you already have.

Likely follow-up. What does neutralising a signal against sector actually do to the numbers?

Each day I take the raw signal across the universe, subtract its cross-sectional mean (and sometimes divide by its cross-sectional standard deviation) so it has mean zero and unit spread on every date.

This makes the signal comparable through time, removes the market-wide component so a long-short portfolio built from it is roughly dollar neutral, and stops a volatile day from dominating the weights. Often I first clip extreme values, then rank or z-score, then optionally neutralise against sector and size.

The pitfall is computing the mean or standard deviation over the whole sample instead of per date, which leaks future information. Every normalisation must use only data available at the time of the decision.

I compute the IC, or the return of a simple portfolio, at a range of forward horizons: next 1, 2, 5, 10, 20 days, or next few seconds to minutes for intraday signals. The decay curve shows how quickly the predictive power fades.

It matters for three decisions. Holding period: you should hold roughly as long as the signal still carries information net of costs. Turnover: a fast-decaying signal forces high turnover and therefore high costs, so it needs a large IC per trade. Execution delay: if half the edge is gone in the first minute, a signal computed at the close and traded the next morning is not viable, so the decay curve tells you how fast the trading system must be.

I would also look at IC lagged by one period to see how much is lost from a realistic delay between signal and trade.

I start simple: z-score each signal, weight them equally or by their historical IC, and measure the combined IC out of sample. Equal weighting is a strong baseline because estimated weights are noisy.

If I have enough data I fit a regression of forward returns on the signals, ideally with shrinkage such as ridge, using a rolling or expanding window so weights only use past data. Correlated signals get split weight automatically, which a simple IC weighting does not do. Non-linear models can help when signals interact, but they overfit easily and need a strict validation set.

The trade-offs are stability against fit and interpretability against accuracy. I would always compare the combination against the equal-weight baseline after costs, and watch whether weights jump around between refits, which usually means the model is fitting noise.

Likely follow-up. When would you combine signals at the portfolio level rather than the forecast level?

Data is stored in long format keyed by date and asset, with a point-in-time universe so delisted stocks remain. I build the signal from data known at each date, lagging anything published with a delay, then clip, rank and neutralise it per date with a groupby on date.

Forward returns are computed separately and aligned explicitly, for example by shifting returns back by one period within each asset, so the join between signal and outcome is the only place where future data enters. I evaluate with per-date rank IC, quantile portfolio returns, turnover and decay, all split into in-sample and out-of-sample periods.

Engineering habits matter: vectorised pandas and numpy, no row loops over a large panel, functions that take a date range so nothing peeks forward, unit tests on small hand-made frames, and saved configuration for every run. See Python for Data Analysis Roadmap for the library skills behind this, and Python Roadmap for the language itself.

Look-ahead bias is using information in a simulated decision that would not have been available at that moment. It makes backtests look better than any real strategy can be.

Common routes: trading at the same close price that was used to compute the signal, which assumes you could act instantly at a price you only learn at the end; using fundamental data on its period-end date rather than its publication date, which can be weeks later; and normalising features with statistics computed over the full sample, such as a global mean or a scaler fitted on all data. Others include backward-filling missing values and using today's index membership to choose the historical universe.

My defence is structural: compute signals with an explicit as-of time, align them to returns that start strictly after that time, and write a test that shuffles future returns and checks performance drops to zero.

Survivorship bias comes from testing only on assets that exist today. Companies that went bankrupt, were delisted or were acquired drop out, and they are disproportionately the poor performers, so the backtest universe is quietly tilted towards winners.

It inflates long-only and value-style results in particular, because a cheap stock that later went to zero is exactly the trade that is missing. The fix is a point-in-time security master: for every historical date, the universe is the set of instruments that were tradable on that date, with their returns through delisting, including the delisting return.

A related bias is using a current index constituent list for the past. Index changes are themselves predictable events, so membership must be historical too.

Overfitting is a single model with too many parameters for the data, fitting noise in the training set. Data snooping is subtler: many researchers, or one researcher over months, try many ideas on the same history and keep what worked. Each individual model can be simple, but the selection process has fitted the noise.

The defences differ. For overfitting, regularisation, fewer parameters and out-of-sample validation work. For snooping, a hold-out set only helps if it has truly never been looked at, so I keep a final period locked, log the number of trials, apply multiple-testing corrections, and favour ideas with an economic reason decided before seeing the data.

A sign of snooping is a strategy with oddly specific parameters, such as a 17-day lookback with a 0.83 threshold, whose performance collapses when the parameters change slightly.

Likely follow-up. How would you check whether a parameter choice is fragile?

Never randomly. Random k-fold cross-validation puts future observations in the training set for past test points, and with autocorrelated features and overlapping labels it leaks information heavily.

I use walk-forward validation: train on data up to time t, test on the following block, roll forward and repeat, so every test point is strictly after its training data. Where labels span several days, I add a purge (drop training samples whose label window overlaps the test block) and an embargo (a gap after the test block) so the model cannot learn from neighbouring days.

I keep a final out-of-sample period untouched until the model is frozen. The number I report is the walk-forward result across many blocks, with its variation, not the best block.

I include three parts: explicit fees and commissions, the half-spread you pay when crossing, and market impact, which grows with the size of the trade relative to volume.

A common impact model is that the cost per share scales with volatility times the square root of order size over daily volume. For a daily strategy I charge each trade a half-spread plus a square-root impact term, using the spread and volume known at the time. For intraday strategies I simulate fills against the book: a passive order only fills if the price trades through it, and with queue position modelled where possible.

I report results across a range of cost assumptions, including double the estimate, because the cost model is the least certain input. A strategy whose Sharpe goes from 2 to zero when costs double is a fragile strategy.

Likely follow-up. How do you know your cost model is right?

I assume a bug until proven otherwise, because daily strategies with that Sharpe after costs are extremely rare.

First, timing: is the signal using the close it trades at, or data published after the decision time. I shift the signal by an extra day; if most of the performance disappears, I have look-ahead. Second, universe: survivorship, and whether tiny illiquid names drive the result, which I check by restricting to liquid names. Third, costs and capacity: is turnover huge, and what happens with realistic spreads and impact.

Then data errors: bad prices, splits not adjusted, stale prices that create fake mean reversion. Then the research process: how many variants were tried. Finally, concentration: does the return come from a handful of days or names. Only after all of that would I look at out-of-sample periods and believe any part of the number.

I would make it event-driven at the core, with a clock that only releases data whose availability timestamp is at or before the current time, and strategies that can only read through that interface.

Every dataset carries two times: the event time and the time we knew it. Fundamentals, corrections and index changes are stored as point-in-time records, so a query for a past date returns what was known then, not the revised value. Orders are submitted at time t and filled by a separate fill simulator against later market data, with latency added, so a strategy cannot trade at the price that triggered it.

For fast research, vectorised backtests are still useful, so I would have both, and run the same strategy through each as a consistency check. I would add tests that inject a known future-dependent signal and assert the engine refuses or that results collapse when shifted.

Turnover is how much of the portfolio is traded per period, usually the sum of absolute weight changes, sometimes halved so that replacing the whole book once counts as 100%. A daily turnover of 20% means you trade a fifth of your gross book each day.

It matters because costs scale with turnover. The net return is roughly the gross return minus turnover times the cost per unit traded, so a strategy with a small edge per trade and high turnover can be unprofitable. Turnover also limits capacity: the more you trade, the more of daily volume you consume.

I reduce turnover by smoothing the signal, adding a no-trade band around current positions, or optimising with an explicit cost penalty. The goal is not minimal turnover but the best return after costs.

The Sharpe ratio is the mean excess return divided by the standard deviation of returns, over the same period, then annualised. For daily returns you multiply by the square root of 252, assuming independent returns.

Weaknesses: it treats upside and downside volatility the same; it ignores fat tails and skew, so a strategy that sells insurance can show a high Sharpe until the crash; it is biased upwards when returns are autocorrelated, as with smoothed or illiquid prices; and it is a noisy estimate with a wide confidence band over short periods.

So I report it together with maximum drawdown, skewness, the worst days and the Sortino ratio, and I check the autocorrelation of returns. For a market-neutral strategy the risk-free rate matters little, but for directional strategies it must be subtracted consistently.

Likely follow-up. Why might a Sharpe ratio computed on monthly returns differ from one computed on daily returns?

Mean-variance optimisation chooses weights to maximise expected return minus a risk-aversion penalty times portfolio variance. Unconstrained, the optimal weights are proportional to the inverse covariance matrix times the expected returns.

In practice the raw version is an error maximiser. Expected returns are estimated very noisily, and inverting a sample covariance matrix amplifies noise in its smallest eigenvalues, so the optimiser takes huge offsetting positions in assets that look slightly different by accident. Results are unstable from one rebalance to the next.

Practitioners use a factor or shrunk covariance matrix, shrink expected returns towards zero or towards a prior, add constraints (position limits, sector and factor neutrality, gross and net exposure), and include a transaction cost term so the optimiser trades only when the improvement pays for the cost.

A sample covariance matrix for N assets has about N squared over two parameters. With 2,000 stocks and a few years of daily data you have far fewer observations than parameters, so the matrix is noisy and often singular.

A factor model says each asset's return is its exposures to a small number of factors times the factor returns, plus a specific return that is independent across assets. Covariance becomes B F B-transpose plus a diagonal matrix D, where B holds exposures, F is the small factor covariance and D holds specific variances. That needs far fewer parameters, is always positive definite if D is positive, and gives interpretable risk: how much comes from market, sector, style or stock-specific bets.

The trade-off is model error: risk that does not load on any chosen factor is treated as diversifiable, so crowded trades with a hidden common driver can be underestimated.

Dollar neutral means the long market value equals the short market value, so net exposure is zero in money terms. Beta neutral means the beta-weighted exposures cancel, so the portfolio has no expected sensitivity to the market. Sector neutral means net exposure within each sector is zero.

They are different. A dollar-neutral book that is long high-beta tech and short low-beta utilities still has a large positive market beta. Which neutrality you want depends on the signal: if the alpha is about stock selection within industries, sector neutrality removes risk the signal says nothing about.

Each constraint costs a little expected return and reduces risk you are not paid for, which usually improves the risk-adjusted result. The test is whether the information ratio rises after neutralisation.

I target a constant level of risk, scaling the position by the inverse of a forecast volatility. If volatility doubles, the position halves, so the expected contribution to portfolio risk stays roughly the same.

For the forecast I use an exponentially weighted estimate of recent returns, with a half-life chosen to balance responsiveness against noise, and a floor so a quiet period does not create a huge position. Across assets, inverse-volatility weighting is the simple version; using the full covariance accounts for correlations as well.

Volatility targeting usually improves the Sharpe ratio because volatility clusters and is more predictable than returns. The risks are that you cut positions after a shock and miss the rebound, and that you scale up just before volatility returns, which is why caps on leverage matter.

Market impact is the price move your own trading causes. Part of it is temporary, the cost of demanding liquidity right now, and part is permanent, because the market reads your trading as information.

Trading quickly means a large temporary impact because you take liquidity aggressively. Trading slowly reduces impact but exposes you to price risk while the order is unfinished, and to information leakage as others detect you. The optimal schedule balances expected impact cost against the variance of execution cost, weighted by risk aversion. That is the structure of the Almgren and Chriss framework, where a more risk-averse trader front-loads the schedule.

Empirically, impact grows roughly with the square root of participation, so splitting an order into smaller pieces over time helps, but with diminishing returns. A strategy's capacity is the size at which impact eats its alpha.

Likely follow-up. How would you estimate the impact parameters from your own fills?

Capacity is the capital at which net performance falls to an unacceptable level because costs grow with size while the gross alpha does not.

I simulate the strategy at increasing capital levels with a cost model in which impact depends on trade size relative to each asset's daily volume. At each level I also impose participation limits, such as never more than a few percent of daily volume in a name. Plotting net Sharpe and net profit against capital gives a curve: profit rises, peaks and falls. The capacity is somewhere before the peak, where the marginal dollar still earns enough.

Signals concentrated in small, illiquid names or with high turnover have low capacity. I would also check crowding: if similar strategies trade the same names, real impact will be higher than the model, especially when everyone exits at once.

A limit order book holds resting buy and sell limit orders at each price. The best bid is the highest price a buyer is willing to pay, the best ask the lowest price a seller will accept. The spread is the ask minus the bid, the mid is their average, and depth is the quantity resting at each price level.

An incoming order that crosses the spread, a buy at or above the best ask, trades against resting orders and removes liquidity. An order that does not cross rests in the book and adds liquidity. Most exchanges match by price-time priority: best price first, then earliest arrival at that price.

Depth and spread together describe liquidity. A tight spread with little depth is cheap for small orders and expensive for large ones, which is why researchers look at several levels, not only the top of the book.

A market order trades immediately at the best available prices, with certainty of execution but not of price. A limit order sets a worst acceptable price and rests if it cannot trade. Immediate or cancel trades what it can at once and cancels the rest; fill or kill must fill completely at once or not at all.

Post-only is a limit order that is rejected or repriced if it would take liquidity, which market makers use to be sure they earn the maker rebate and never cross. A stop order becomes active once the market trades at a trigger price; it is used to cut losses but can execute far from the trigger in a fast market.

Exchanges also offer iceberg orders that show only part of their size, and auction-only orders for opening and closing auctions. The exact behaviour differs by venue, so a good engineer reads the venue's rules rather than assuming.

Adverse selection is the cost of trading with someone who knows more than you. When a market maker's bid is hit, it is more likely than average that the price is about to fall, because informed sellers choose to sell before bad news. Fills arrive exactly when you would rather not have them.

This is why the spread exists even with no processing cost: the market maker earns the spread on uninformed flow and loses on informed flow, and the spread must cover the losses. Measuring it is straightforward: look at the mid price a short time after each fill. If the mid consistently moves against you after fills, your markouts are negative and you are being adversely selected.

Responses include widening quotes when signals suggest informed flow, skewing quotes based on order book imbalance, cancelling faster after market moves, and avoiding flow from counterparties whose fills have bad markouts.

Likely follow-up. How would you compute markouts from a fill log?

The microprice weights the bid and ask by the opposite side's size: it is the bid times the ask size plus the ask times the bid size, divided by the total size. When the bid has much more size than the ask, the microprice sits closer to the ask.

The intuition is that a thin ask is more likely to be consumed first, so the next mid is more likely to be higher. Order book imbalance is one of the most reliable very short-horizon predictors of the next price move, and the microprice folds it into a single fair value estimate.

The caveats: displayed size can be misleading because of hidden and iceberg orders and fleeting quotes, imbalance predicts only very short horizons, and its usefulness depends on the tick size. It works best in instruments where the spread is usually one tick and queues are long.

Under price-time priority, a passive order at a given price fills only after all orders ahead of it at that price. Being at the front of the queue means you fill more often and your fills are less adversely selected, because you get filled by ordinary flow before the level is swept.

In large-tick instruments, where the spread is nearly always one tick and the price levels hold a lot of size, queue position is valuable and a large part of the market-making game is getting to the front quickly when a new level forms. In small-tick instruments the spread is several ticks wide, queues are short, and competition shifts to price improvement instead.

For backtesting, ignoring queue position overstates fill rates for passive orders. A reasonable simulator estimates your place in the queue from the size ahead when you joined and the trades and cancels since.

Price-time priority fills orders at the best price in arrival order: the first order at a price fills first. Pro-rata allocates an incoming order across all resting orders at the best price in proportion to their size.

The incentives differ. Price-time rewards speed and being early in the queue. Pro-rata rewards size, so participants tend to post larger orders than they really want, expecting to receive only a fraction, which creates its own risk if a large order hits them. Some markets use a mix, for example a priority allocation to the order that improved the price, then pro-rata for the remainder.

For a trading system the matching rule changes the strategy and the simulator, so it must be modelled for each venue.

For an order-by-order feed, I keep a map from order identifier to order (side, price, remaining size), and per side a price-indexed structure of levels with aggregate size and, if needed, a queue of orders. Each message (add, modify, cancel, execute, delete) updates both the order map and the level.

Feeds are usually UDP multicast with sequence numbers, so the main risk is a gap. On a gap, the book is no longer trustworthy: I mark the instrument stale, stop trading it, and recover from a snapshot channel or a retransmission service, then replay buffered messages after the snapshot's sequence number. Many venues send the same feed on two lines, A and B, and the handler arbitrates, taking whichever copy of each sequence number arrives first.

Other failure modes: a crossed book after a missed message, integer overflow in price fields, assuming one instrument per channel, and doing allocation or logging on the hot path. I test with recorded captures, including deliberately dropped packets.

Likely follow-up. How do you know your book is correct in production?

TWAP slices an order evenly over a time window, for example one child order every minute of the same size. VWAP slices in proportion to the expected volume profile over the day, trading more when the market usually trades more, such as near the open and close.

VWAP is used when the client is measured against the day's volume-weighted average price, which is common for large institutional orders, because matching the volume profile tends to keep the execution close to that benchmark. TWAP is simpler and more predictable, useful when volume forecasts are poor or in instruments without a reliable profile.

Both are schedules, not strategies: a real implementation adds randomisation so the pattern is less detectable, limit prices, a participation cap, and logic to choose between passive and aggressive child orders.

Implementation shortfall is the difference between the price when the decision was made, usually the arrival price, and the average price actually achieved, plus the opportunity cost of any part not filled. It is the true cost of turning a decision into a position.

Measurement is transaction cost analysis. For each parent order I compute slippage against arrival price, against interval VWAP and against the close, in basis points, signed so that positive is a cost. I break it into spread paid, impact and timing. Averaged over many orders and normalised by volatility and size, it shows whether an algorithm or broker is better.

Benchmarks can be gamed: VWAP slippage looks good if you trade slowly in a trending market, while shortfall shows the real cost. That is why I prefer arrival price as the main benchmark for alpha-driven trading.

Likely follow-up. Why can VWAP slippage look good while the trade was actually expensive?

A new order is a NewOrderSingle, message type D, carrying a client order id in tag 11, the symbol, side in tag 54, quantity in tag 38, order type and price in tag 44. The venue replies with ExecutionReports, message type 8, for acknowledgement, partial fills, fills and rejections, with OrdStatus in tag 39 and ExecType in tag 150.

A cancel request is message type F and an amend is an OrderCancelReplaceRequest, message type G. Both carry a new client order id in tag 11 and the id of the order being changed in tag 41, OrigClOrdID. If a cancel cannot be done, for example because the order already filled, the venue sends an OrderCancelReject, message type 9.

The detail interviewers like is that cancel and amend races are normal: a fill can arrive after you sent a cancel, so the order state machine must handle fills on orders that are pending cancel.

Likely follow-up. What happens if a cancel and a fill cross on the wire?

Each side numbers its outgoing messages in tag 34, MsgSeqNum, starting from 1 at the beginning of a session. The receiver checks every number. If one is higher than expected, messages were missed and it sends a ResendRequest, message type 2, for the range. If it is lower than expected without the possible duplicate flag, that is a serious error and the session is usually terminated.

The sender replays the requested messages with PossDupFlag set, and may use a SequenceReset in gap-fill mode, message type 4, to skip administrative messages that should not be resent, such as old heartbeats. Logon is message type A, heartbeat 0 and test request 1; heartbeats at the agreed interval detect a silent connection.

For an order gateway, the important rule is that order messages are persisted with their sequence numbers before or as they are sent, so a restart can resume the session correctly instead of resetting and losing the state of live orders.

It tracks each order from creation to a terminal state: pending new, new or acknowledged, partially filled, filled, pending cancel, cancelled, pending replace, replaced, rejected and expired. Every transition comes from either our request or the venue's report.

The tricky cases are races. A fill can arrive while a cancel is pending, so filled quantity must be accepted in any non-terminal state. A replace can be rejected, so the old order remains live at its old price. Reports can arrive out of order across channels, so I key on cumulative quantity rather than incrementing on each fill. An unacknowledged order after a timeout must be treated as possibly live, never assumed dead.

I would make the state machine a pure function of events so it can be unit-tested with recorded sequences, and reconcile positions against the venue's drop copy at regular intervals.

It is a trade-off between saving the spread and taking timing risk. A passive order earns the spread if it fills, but may not fill, and fills tend to come when the price is moving against you. An aggressive order pays the spread but executes with certainty.

I decide using how far behind schedule the algorithm is, a short-term price forecast such as order book imbalance or microprice, the spread in ticks, and the queue length. If the forecast says the price is about to move away, crossing now is cheaper than chasing later. If the queue is short and the forecast neutral, joining the bid is attractive. Near the end of the window, urgency grows and the algorithm crosses more.

The decision should be evaluated with markouts and fill-rate statistics, comparing realised cost against what the alternative choice would have cost.

Every order must pass checks that are fast, deterministic and independent of the strategy's own logic. Typical checks: maximum order size and value; price collars that reject orders too far from a reference price, catching fat-finger and stale-price errors; position and exposure limits per instrument and in total; maximum open orders; message rate throttles to stay within venue limits; and checks on duplicate or runaway order sequences.

A kill switch must be able to cancel all orders and block new ones in one action, both manually and automatically on triggers such as a loss limit or a disconnection from the risk system. Checks must be evaluated on the current state including orders in flight, not just confirmed positions, otherwise a burst of orders can breach limits before fills arrive.

For low latency the checks are written as simple comparisons on precomputed limits, with no allocation, and their latency is measured like any other hot-path code.

A cache line is the unit the CPU moves between memory and cache, 64 bytes on most current x86 and many Arm processors. Reading one byte brings in the whole line, so data used together should live together.

A miss to main memory costs on the order of a hundred nanoseconds, far more than the arithmetic in a typical handler. So hot-path data structures favour contiguous arrays over linked nodes, pack the fields read on every message into one or two lines, and keep rarely used fields elsewhere. An order book stored as an array of levels indexed by price offset is usually faster than a tree because walking it is predictable.

The other side is false sharing: two threads writing different variables on the same line force the line to bounce between cores. Padding or aligning such variables to separate lines fixes it.

A general-purpose allocator call has unpredictable latency: it may take a lock, search free lists, or ask the operating system for memory, which can involve a page fault. The average is small, but the tail is what loses trades.

So hot-path code preallocates everything at start-up: object pools for orders, fixed-capacity ring buffers for messages, and containers with reserved capacity. Memory is touched once at start-up so pages are already mapped, often with huge pages to reduce translation lookaside buffer misses. Standard library types that allocate implicitly, such as std::string concatenation, std::function with large captures and growing vectors, are kept off the critical path.

The same reasoning applies to anything with variable cost: exceptions, logging that formats strings, and system calls are moved to another thread or done in a non-critical phase.

Likely follow-up. How would you log from a hot thread without slowing it down?

The producer writes the element into the slot and then publishes the new tail index with a release store. The consumer reads the tail with an acquire load; if it sees the new index, the release-acquire pair guarantees it also sees the element written before it. The consumer publishes its head index the same way so the producer knows when a slot is free.

No locks or compare-and-swap are needed because each index has a single writer. Relaxed ordering is enough for a thread reading its own index. Using sequentially consistent operations everywhere also works but adds fences that are unnecessary on some architectures.

For speed, the head and tail live on separate cache lines to avoid false sharing, and each side keeps a cached copy of the other side's index, refreshing it only when the queue looks full or empty. That cuts cross-core traffic sharply. See the SPSC exercise below for a tested version.

Kernel bypass lets an application read and write network packets directly from the network card's queues in user space, instead of going through the operating system's network stack and socket calls.

It removes system call overhead, interrupt handling, copies between kernel and user buffers and contention with other kernel work. Combined with a dedicated core that busy-polls the receive queue, it reduces both the median and, more importantly, the variance of packet latency. Some cards also timestamp packets in hardware, which gives accurate latency measurement.

The costs are a core spinning at full use, a more complex software stack, and often vendor-specific libraries. You also lose the kernel's protections and tools, so packet capture and monitoring must be built separately. It only helps if the rest of the path is also fast: a slow strategy loop behind a bypassed network card gains little.

I timestamp at well-defined points: packet arrival (ideally a hardware timestamp from the network card), after decoding, after the strategy decision, and when the order is handed to the network card. The difference between the first and last is tick-to-trade.

Within one machine I use a cheap, monotonic counter such as the CPU's time stamp counter with a known frequency, read without serialising more than needed. I record values into a preallocated buffer and aggregate on another thread, reporting percentiles rather than means. Wire-to-wire measurement uses a capture device that timestamps packets on both sides, which also includes the time spent in the network card and the stack.

Pitfalls: measurement code that itself allocates or takes a lock, clock differences between cores or machines, and averaging away the tail.

I isolate cores for the critical threads so the scheduler and most interrupts never run there, pin each critical thread to its own isolated core, and route the network card's interrupts away from them. Power-saving states and frequency scaling are disabled or fixed so the core does not slow down while idle.

Memory is allocated on the NUMA node local to the network card and the critical cores, using huge pages, and locked so it cannot be swapped. Hyper-threading siblings of critical cores are left idle so they do not share execution resources. Unneeded services and timers are reduced.

I would verify each change by measuring tail latency before and after, because tuning by habit can hurt. Interviewers also like hearing that the configuration is automated and checked at start-up, so a machine that came back from maintenance with the wrong settings refuses to trade. See Linux Roadmap for the operating system background.

A virtual call is an indirect branch through a table. On its own it costs little if the branch predictor guesses the target, but it blocks inlining, which stops the compiler from optimising across the call, and a mispredicted target costs a pipeline flush.

In a hot path where the concrete type is known at build or start-up time, I use templates: the curiously recurring template pattern for static polymorphism, or a strategy type passed as a template parameter so the whole handler is compiled as one unit. Where a choice is made at run time among a few types, std::variant with a visit, or a switch, keeps calls direct and inlinable.

I would not remove virtual functions everywhere. Outside the critical path they make code easier to extend. Measure first, and change what the profile shows.

kdb+ is a column-oriented, in-memory time-series database, and q is its vector query language. Trading firms use it to store and query tick data, both live and historical, because queries over long time-ordered columns are very fast.

A common architecture has a tickerplant that receives the feed and logs it, a real-time database holding today's data in memory, and a historical database on disk partitioned by date. Subscribers such as analytics or monitoring processes receive updates from the tickerplant. At end of day, the real-time data is written to the historical database.

Useful features to mention are as-of joins, which attach the prevailing quote to each trade, and concise aggregation. For example:

select vwap:size wavg price by sym from trade where date=2024.01.02

q evaluates right to left with no operator precedence, which catches newcomers out. For SQL foundations see SQL Roadmap.

Likely follow-up. Why are as-of joins so useful for trade and quote analysis?

I make the core logic a function of its inputs: every market data message, order response and timer event is an input event with a sequence number and timestamp, and the strategy reads time only from the event, never from the system clock. Inputs are recorded in order at the boundary.

With that, any production session can be replayed through the same binary and must produce the same outputs, which gives exact reproduction of bugs, regression testing against recorded days, and a check that a new version only changes what was intended. Single-threaded core logic, fed by queues from I/O threads, makes this much easier than shared-state concurrency.

Sources of hidden non-determinism to remove: iteration over unordered containers whose order depends on addresses, uninitialised memory, floating-point differences across builds, and timers driven by the wall clock. The same design also makes the backtester and the live system share one code path.

Quant researcher loops lean on probability, statistics, research design and Python data work, with a backtest critique round. Algo trading developer loops lean on C++ or another systems language, data structures, concurrency, networking and microstructure, with a system design round. Both usually include probability and mental maths, and many firms mix the two, which is why this page covers both. Check the job description and ask the recruiter which rounds to expect.

For junior roles, deep finance knowledge is usually not required, but you should understand the basics on this page: how an order book works, what bid, ask and spread mean, order types, what a backtest is and why costs matter. Interviewers care more that you reason precisely and learn quickly. For senior roles, expect detailed questions on microstructure, execution and risk in the asset classes the team trades.

Python for research roles, because research teams work in pandas and numpy and set data-manipulation problems. C++ for low-latency developer roles, with emphasis on memory, templates, concurrency and performance. Some firms use Java, Rust or OCaml for trading systems, but they test the same ideas. Pick one main language and be fluent; see Modern C++ Roadmap and Python Roadmap, and practise algorithm problems with Data Structures and Algorithms Roadmap.

They usually involve fast arithmetic with two and three digit numbers, fractions, percentages and simple estimation, under time pressure and sometimes with many questions in a few minutes. The difficulty is speed and accuracy together. Practise daily for a few weeks: multiplication by splitting numbers, squares near round numbers, converting fractions to decimals, and estimating roots. It improves quickly with practice.

Describe the problem, the method and your contribution in general terms, and give results as relative improvements or qualitative outcomes rather than exact strategy details, parameters or returns. Interviewers respect this and will not ask you to reveal a previous employer's proprietary methods. Personal projects on public data are useful precisely because you can discuss them fully.