Risk and running a strategy in production

The gap between a backtest and a live system. This is where a backend engineer adds most value on a quant team, and where the interview questions are ones you can actually answer from general engineering experience.

Risk metrics

Metric	Definition	Watch for
Sharpe	excess return / volatility, annualised	assumes normal returns; a strategy selling tail risk shows a high Sharpe until it does not
Sortino	excess return / downside deviation	fairer for asymmetric strategies
Max drawdown	largest peak-to-trough loss	the number that gets strategies switched off
Drawdown duration	time from peak to recovery	the number people underestimate; a 3-year recovery is not survivable in practice
Calmar	CAGR / max drawdown	return per unit of pain
VaR / CVaR	loss at a quantile / mean loss beyond it	CVaR is coherent; VaR is not
Beta / factor exposure	correlation to market and known factors	an “alpha” strategy that is really leveraged beta

Annualisation matters: a daily Sharpe scales by sqrt(252), and quoting a monthly Sharpe as if annual inflates it more than threefold. Interviewers do check.

Position sizing

Sizing is a separate decision from direction, and often contributes more to the outcome.

Fixed fractional — a constant percentage of equity per position. Simple and defensible.
Volatility targeting — size inversely to recent volatility so each position contributes similar risk. Usually the largest single improvement over naive sizing.
Kelly — the growth-optimal fraction given edge and odds. Full Kelly is far too aggressive under estimation error; practitioners use a fraction of it, and saying “half-Kelly at most” shows you understand why.
Risk parity across positions — equal risk contribution rather than equal capital.

Always cap: per position, per sector, gross and net exposure. Caps are what stop a bad estimate becoming a solvency event.

Pre-trade risk checks

Every order passes these before it reaches the venue, in a component the strategy cannot bypass:

Position and notional limits, per instrument and aggregate
Order size sanity — a fat-finger check against average volume
Price collar — reject orders far from the current market
Rate limits — orders per second, to stop a runaway loop
Kill switch — one control that flattens and halts everything

The kill switch is the one to volunteer. Any automated trading system needs a single, tested, human-operable way to stop, and “tested” means you have actually exercised it, not that it exists in the code.

Reconciliation

The venue is the source of truth. Your in-memory position is a cache, and caches go stale.

Reconcile positions, cash and open orders against the broker on a schedule and after any disconnect.
Alert on any break, and stop trading the affected instrument rather than trading on a wrong view.
Keep an immutable, append-only record of every order, fill and cancel. You will need it for debugging, for P&L attribution and for regulators.

This is ordinary distributed-systems thinking: at-least-once delivery, idempotent handling, and a reconciliation loop that converges the two sides. See ../../system_design/02_resilience/ and ../13_architecture_design/18_idempotency_keys.md.

Deployment and monitoring

The uncomfortable property of trading systems: a bug loses money in real time, and there is no rollback for a filled order.

Paper trade first, on the live data feed, for long enough to see the strategy’s normal range of behaviour.
Deploy between sessions, never with positions open, unless the system is explicitly designed to hand over state.
Monitor the strategy, not just the process. Uptime tells you nothing. Alert on live-versus-backtest divergence in fill prices, signal distribution, and realised versus expected volatility.
Track slippage as a first-class metric. Systematically worse fills than the backtest assumed is the earliest sign the edge is not real at size.
Log every decision with its inputs, so a surprising trade can be explained afterwards. See ../15_observability/.

Model and strategy decay

Strategies stop working, usually gradually. Decide in advance:

The out-of-sample performance band that means “still working”
The drawdown that triggers a size reduction, and the one that triggers a halt
A review cadence, so the decision is made on a schedule rather than in the middle of a loss

Writing those thresholds down before deployment is the difference between a risk process and a series of improvised decisions under stress.

Interview angle

“What would you monitor on a live trading system?” - not uptime. Fill prices versus the backtest’s assumption, realised slippage, signal distribution drift, position and exposure against limits, and reconciliation breaks. Divergence between live and simulated behaviour is the leading indicator.
“How do you stop a runaway algorithm?” - a pre-trade risk layer the strategy cannot bypass, with rate limits and price collars, plus a tested kill switch that flattens and halts. The word that matters is tested.
“Why is drawdown duration as important as drawdown depth?” - because humans switch strategies off. A 20% drawdown that recovers in a month is tolerable; the same depth over three years does not get the chance to recover.
“How do you size positions?” - volatility targeting so each position contributes comparable risk, with hard caps per position and per sector. Full Kelly is theoretically optimal and practically reckless under estimation error.
“How do you know your strategy has stopped working?” - thresholds defined before deployment: an out-of-sample performance band, a drawdown that reduces size, and one that halts. Deciding this during the drawdown is how people hold losing strategies too long.