Data science and machine learning roles, tracked live.

How this route works

Two very different jobs share this vertical and most applications go to the wrong one. Product data science is an analytics and causal-inference role: SQL, experiment design, metric definition, and the judgement to say what a number means to a business decision. Machine learning engineering and research build and ship models, and are screened on modelling depth, coding and increasingly on the design of systems built around large models. The titles are used interchangeably by employers and are not interchangeable in the interview.

For the product data route the loop is unusually predictable. A SQL screen comes first at almost every employer, and it is a timed technical filter rather than a formality — window functions, multi-step aggregations and cohort logic against a schema you have not seen before. After that comes experimentation: designing an A/B test, sizing it, and reading a result honestly, including the cases where you should refuse to call it. Then a case round on metrics, usually framed as a number that moved and a question about why.

For the machine learning route the emphasis moves to modelling and to engineering judgement. Expect to justify a model choice against a simpler baseline, to talk credibly about evaluation and about what you would monitor after deployment, and — at an increasing number of employers — to discuss the design of a system built on top of a model rather than the model itself. Research seats generally expect publications or an equivalent track record; applied ML seats do not.

Finance employers on this board add a constraint the technology ones do not. Financial data is non-stationary, thin in the regimes that matter, and unforgiving of leakage, so a candidate who describes a validation approach that quietly uses the future is finished regardless of how good the model was. That is the single most common failure in these interviews and it is entirely preventable.