What is tested
For quant research and data roles, Python rounds usually involve manipulating data, implementing a calculation correctly, and reasoning about efficiency. They are less algorithm-puzzle-focused than a general software interview and more about whether you can actually work with data.
Vectorisation
Writing a Python loop over a DataFrame is the fastest way to signal inexperience. Know how to express operations vectorised:
- Rolling statistics with pandas rolling windows rather than manual loops.
- Boolean masking rather than filtering row by row.
- NumPy broadcasting rather than nested loops.
Also know why it matters: the loop runs in the interpreter, the vectorised version runs in compiled code, and the difference is often two orders of magnitude.
Things you should be able to do without thinking
- Group and aggregate a DataFrame.
- Join two datasets and reason about what happens to unmatched rows.
- Resample a time series and handle the boundary conventions.
- Handle missing data deliberately rather than dropping silently.
- Compute returns from prices, and know why log returns are convenient.
That last one comes up constantly on research-side rounds.
Complexity still matters
Knowing that a dict lookup is O(1) while a list membership test is O(n) is expected. So is recognising that repeated string concatenation in a loop is quadratic, and that sorting is O(n log n).
Correctness over cleverness
At least one firm states explicitly that coding style is not what is being marked and that testing your code and finding corner cases is. Take that literally: a straightforward correct solution with the edge cases handled beats a clever one-liner that breaks on an empty input.
Say your edge cases out loud - empty input, single element, duplicates, negative values, NaN.
What not to over-prepare
Deep metaprogramming, decorators for their own sake, and obscure standard-library corners rarely appear. Time is better spent on data manipulation fluency and on complexity reasoning.
Practise in programming and DSA.