Intro to Coding and Automation in Prop Trading
Trading is now largely automated, and even discretionary traders work through code. The useful question for a candidate is not whether to learn programming but what level is actually expected.
Who writes what
Traders typically write analysis and research code: pulling trade data, computing markouts, testing whether a signal holds, building monitoring dashboards. Almost always Python.
Quantitative researchers build and validate models: pricing, signals, risk. Python for research, sometimes C++ for production versions.
Developers build the systems that touch the exchange: the order gateway, the matching-engine feed handler, the risk checks. C++ or Rust, occasionally hardware.
Most trading roles sit in the first category. You are expected to be comfortable manipulating data and testing ideas, not to write a low-latency engine.
The languages, and why
Python dominates research because iteration speed matters more than execution speed when you are exploring. The ecosystem (pandas, numpy, statistical and plotting libraries) is unmatched for this.
C++ and Rust dominate execution because microseconds matter and you need control over memory and system calls. Nothing garbage-collected can guarantee latency.
SQL is underrated and used constantly, because most analysis begins with pulling the right slice of trade data.
Python for research, C++ for latency, SQL for data. A trader who is fluent in Python and SQL can do most of what a trading role requires without ever writing production C++.
What traders actually build
Markout analysis. Do prices move against you after your fills? The core diagnostic for adverse selection, and it is a few lines of data manipulation.
Backtests. Would this rule have made money? Easy to write and easy to get wrong, since every backtest is one lookahead bug away from being fiction.
Quote automation. Encoding the quoting logic so the system adjusts faster than a human could.
Monitoring. Live views of position, P&L and risk, with alerts when something leaves its expected range.
The traps in backtesting
Worth knowing before you write your first one, because these are the mistakes everyone makes.
Lookahead bias. Using information not available at the time. Subtle versions are common: using a day's closing price to decide a trade during that day, or using a restated data series.
Survivorship bias. Testing on instruments that still exist today excludes those that failed, which flatters any long strategy.
Ignoring costs. Spreads, fees and impact frequently turn a profitable backtest into a losing strategy.
Overfitting. Testing enough variations guarantees one looks good. See multiple testing.
The first question to ask any backtest, including your own, is "what information does this use that I would not have had at the time?" Most too-good-to-be-true results answer that question immediately.
How much you need for an interview
For most trading roles: enough Python to load data, manipulate it and compute a statistic, plus enough algorithmic reasoning to solve a moderate coding problem. Firms with a stronger technical bar test more, and some run genuine software engineering interviews.
The honest framing is that coding is a multiplier on trading skill rather than a substitute for it. A trader who can test their own idea on Tuesday afternoon instead of waiting a week for a researcher is meaningfully more effective, and that is the reason to learn it.