A complete, honest roadmap for the skills machine learning engineers actually use, from programming and math through data and feature engineering, ML fundamentals, deep learning, training, evaluation, MLOps, monitoring, scaling, LLMs, and responsible ML. It runs top to bottom, foundational to advanced, so you always know what comes next. Free to read, no signup required.
How to use this: each step below is collapsed. Tap one to expand its details, skill pills, and guidance (only one opens at a time). Work down the spine in order; each stage assumes the ones above it. The field moves fast, so anchor on the fundamentals and build real projects, because that’s what turns ML experiments into engineering.
01
ML engineering is where machine learning meets real software. Before models, get genuinely good at writing code that other people can run and trust.
Python, deeply: The default language for ML. Learn data structures, control flow, error handling, and idiomatic style.
Software engineering: Version control, testing, clean code, and working in a codebase. ML systems are software and rot without these.
APIs & services: How services talk over HTTP, because a trained model becomes useful once it’s served behind an API.
Data handling in code: Reading, transforming, and validating data programmatically, the everyday substrate of ML work.
ML engineering leans more on software skill than data science does. The gap between a notebook experiment and a production system is mostly engineering, which is why it comes first.
PythonGit & testingClean codeAPIsData handling
02
You don’t need a maths PhD, but you do need enough to understand why models behave as they do. Aim for working intuition, not proofs.
Linear algebra: Vectors, matrices, and operations, the language models are built and computed in.
Probability & statistics: Distributions, expectation, and uncertainty, the foundation of how models learn and how you evaluate them.
Calculus intuition: Gradients and optimisation at a conceptual level, enough to understand how training works.
Why it matters: The goal is intuition that helps you debug and reason about models, not memorising formulas.
Linear algebraProbabilityStatisticsCalculus intuitionOptimisation
03
Models are only as good as the data they learn from. A large share of real ML work is getting data clean and shaping it into useful features.
Data wrangling: Loading, cleaning, and transforming messy real-world data into something a model can learn from.
Feature engineering: Turning raw data into features that carry signal, often the single biggest lever on model quality.
Data splitting & leakage: Splitting data correctly and avoiding leakage, where information from the future sneaks into training and inflates results.
Data pipelines: Building repeatable pipelines so data prep is consistent between experiments and production.
Beginners obsess over model choice; experienced engineers know the data and features usually decide the outcome. Time spent on data is rarely wasted.
Data wranglingFeature engineeringData leakageTrain/test splitsPipelines
04
Classic ML is the bedrock beneath everything else. These ideas apply to every model you’ll ever train, from a simple regression to a large network.
Supervised & unsupervised: Learning from labelled data versus finding structure in unlabelled data, the two core paradigms.
Core algorithms: Regression, trees, and clustering, which still solve many real problems better than deep learning.
Training & generalisation: Overfitting versus underfitting and the bias-variance trade-off, the ideas behind a model that works on new data.
Evaluation metrics: Accuracy, precision, recall, and why the right metric depends entirely on the problem.
Don’t skip classic ML to jump to deep learning. Overfitting, evaluation, and generalisation are exactly the concepts that separate reliable models from impressive demos.
A model that scores well on paper can still fail in the real world. Rigorous evaluation is what separates a serious ML engineer from a leaderboard chaser.
Choosing the right metric: Picking metrics that reflect the real goal, since the wrong metric can hide a broken model.
Validation strategy: Building held-out and validation sets that honestly represent the data the model will see in production.
Error analysis: Looking at where and why a model fails, which teaches more than the headline score.
Baselines: Comparing against a simple baseline so you know whether the complex model is actually earning its keep.
The most common ML mistake is trusting a good validation number without checking how it was produced. Leakage and a poorly chosen metric produce confident, wrong results.
Metric choiceValidationError analysisBaselines
08
A model in a notebook helps no one. Getting models into production reliably and repeatably is the core of what an ML engineer does.
Serving models: Exposing a trained model behind an API and running inference reliably under real load.
Versioning: Tracking model, data, and code versions together so any result can be reproduced and rolled back.
CI/CD for ML: Automated pipelines that test, package, and deploy models consistently instead of by hand.
Model registry: A central record of models and their stages, so promoting a model to production is controlled, not ad hoc.
Model servingVersioningCI/CD for MLModel registryContainers
09
A deployed model is not finished. The world changes, data shifts, and performance drifts, so keeping a model healthy is an ongoing job.
Performance monitoring: Watching accuracy, latency, and cost in production so a degrading model is caught early.
Data & concept drift: Detecting when incoming data or the relationship it models has changed enough to hurt results.
Retraining: Deciding when and how to retrain, and doing it safely without breaking what already works.
Data quality in production: Validating live inputs, because bad data reaching a good model quietly produces bad predictions.
Real ML runs at scale, where cost, latency, and hardware become central. Designing the system around the model is as important as the model itself.
Cost & latency: Balancing quality against speed and cost, the trade-offs that dominate production ML decisions.
Optimising inference: Caching, batching, and model optimisation to serve predictions efficiently at scale.
Distributed training: How large models are trained across many GPUs, and the basics of what that requires.
System design: Designing systems where the model is one component among many, with the reliability care of any backend.
Cost vs latencyInference optimisationGPUsDistributed trainingSystem design
11
Foundation models have changed what an ML engineer builds. Knowing when to train, when to fine-tune, and when to just prompt is now part of the job.
Foundation models: What large pre-trained models can do, and why using one often beats training from scratch.
Fine-tuning vs prompting: When adapting a model is worth the cost versus when careful prompting is enough.
Retrieval & embeddings: Using embeddings and retrieval to ground a model in specific data, the basis of many AI features.
Evaluating LLM output: Judging quality when there’s no single correct answer, which needs different evaluation from classic ML.
Foundation modelsFine-tuningEmbeddingsRetrievalLLM evaluation
12
ML systems affect real people, and the field moves fast. Building responsibly and learning continuously are both part of doing the job well.
Bias & fairness: Recognising and reducing unfair or harmful behaviour that data and models can encode.
Interpretability: Understanding why a model made a prediction, which matters for trust, debugging, and some regulations.
Privacy & governance: Handling training data responsibly and following the emerging norms around deploying models.
Learning continuously: Anchoring new techniques in the fundamentals above, so you can tell real progress from hype.
Tools and model names on this page will change; the fundamentals of data, evaluation, and reliable systems will not. Anchor on those and the rest becomes easy to pick up.
ML engineering is learned by building, and especially by taking a model all the way to production. A project you can measure, deploy, and reason about proves far more than any certificate.
Take a real dataset, engineer features, and train a model with an honest validation setup and a simple baseline.
Do proper error analysis, and write up why the model fails where it does, not only its headline score.
Serve the model behind an API, then add monitoring so you would notice if its performance drifted.
Package the whole thing so someone else could reproduce your result from your code and data versions.
Put it on GitHub with a README that reports how you evaluated and deployed it. Being able to say why your model works, and how well, is what separates an engineer from a tinkerer.
Frequently asked questions
What’s the difference between an ML engineer, a data scientist, and an AI engineer?
The lines are blurry and vary by company. Broadly, data scientists lean toward analysis and modelling to answer questions; ML engineers focus on training models and getting them running reliably in production; AI engineers increasingly focus on building applications on top of foundation models. ML engineering is the most software-heavy of the three.
Do I need a PhD to be an ML engineer?
No, not for most applied ML engineering roles, which are about building reliable systems around models. A strong grasp of the fundamentals here, real software skill, and projects you can show matter more than a specific degree. Research roles that invent new methods are where advanced degrees are more common.
How much math do I really need?
Enough for intuition, not proofs. Linear algebra, probability and statistics, and a conceptual grasp of optimisation are what help you evaluate and debug models. You can go a long way in applied ML engineering with working intuition rather than deep theoretical mathematics.
Should I focus on classic ML or deep learning and LLMs?
Build the foundation first. It’s tempting to jump to deep learning and LLMs, but concepts like evaluation, overfitting, and generalisation come from classic ML and are exactly what keep advanced models honest. Learn the fundamentals, then apply them.
How long does it take to become an ML engineer?
It depends heavily on your starting point and far more on real projects than any fixed number. Someone with a strong software background can move into ML engineering faster than someone starting from zero programming. Building and deploying a real model is what accelerates it.
Do I need to master every topic on this roadmap?
No. Programming, data and feature engineering, ML fundamentals, and evaluation are the core. Deep learning depth, large-scale systems, and LLM work you deepen as roles demand, and the emphasis differs a lot between, say, a recommendations team and an LLM product team.
Early access
ML Engineer support is coming to Interview Ready
Our personalized Interview Ready plans don’t cover ML Engineer just yet, so unlike our other roles, this page doesn’t hand you off to a plan we can’t build for you honestly. This roadmap is free to use in the meantime. Want to be first in line when we add ML Engineer? Register your interest and we’ll let you know the moment it’s ready.
