How to become an ML Engineer

You train, evaluate and ship models: the person who owns a model from the data that feeds it to the service that serves it, and who is called when its numbers move.

This is the broadest of the three routes and the longest, because it genuinely spans data engineering, modelling and production systems. It suits people who want to own outcomes rather than components. The maths is real but it is applied maths: you need to read it, reason with it, and know when a result is not real.

Topics: 50
Reading: 811h
Practice: 955h
Projects: 5

The route

In order. Each chapter ends in something you can do, so you can tell whether it worked rather than whether you got to the end of it.

1Foundations

95h

By the end of this chapter: You can write Python, work a repository with other people, get data out of a database correctly, and pass the algorithms screen that still gates most large companies.

2The maths

85h

By the end of this chapter: You can read the notation in a paper or a library's documentation without stalling, reason about whether an experiment's result is real, and manipulate arrays and tables vectorised rather than in loops.

3Data

42h

By the end of this chapter: You can move data reliably on a schedule, judge whether your labels are worth training on, and turn text into the numbers a model consumes.

4Classical ML

73h

By the end of this chapter: You can train a supervised model end to end, choose a metric that matches the cost of being wrong, and tell overfitting apart from a genuine improvement.

Build this now — you have just done Model evaluation & metrics

Take a model from a table to an endpoint

One classical supervised model carried through the whole lifecycle — messy table, honest split, defended metric, tuned model, served endpoint, drift monitor — with no deep learning anywhere.

8 stages · 26h

5Deep learning

167h

By the end of this chapter: You can build and train networks in PyTorch, derive what backpropagation is doing rather than nod along to it, and explain a transformer, what pretraining bought, what fine-tuning changes, and how alignment turns a text predictor into something that answers.

Build this now — you have just done Transformers & attention

Build your own GPT

A decoder-only transformer you wrote yourself, trained on text you chose, generating new text — no framework magic, about 300 lines.

7 stages · 24h

Build this now — you have just done Transformers & attention

Serve a model, then make it cheaper

A model behind an HTTP API that you have measured honestly, then made faster with batching, caching and quantization — with the numbers for what each one bought.

7 stages · 24h · also needs HTTP & APIs, which is not on this route

6Scale & evals

81h

By the end of this chapter: You can train a model too big for one GPU, reason about the hardware that shapes every decision you make, and prove a model is better rather than assert it.

Build this now — you have just done Evaluation

Fine-tune a small model

A small open model adapted with LoRA to a task you define, measured against the two honest baselines — the base model, and the base model with a good prompt — and an adapter you serve.

7 stages · 26h · also needs Prompting, which is not on this route

7Production

87h

By the end of this chapter: You can serve a model, keep it working after launch as the data moves under it, and design the system around it — which is the interview round you will actually get.

8The interview

61h

By the end of this chapter: You can test and debug what you built, show that a launch moved a real metric rather than an offline one, and conduct yourself well in the rounds that decide the offer.

Build this now — you have just done Testing

An eval harness that fails the build

A dataset built from real traces, graders checked against human labels, a runner that scores a change, and a CI job that turns a pull request red when quality drops.

7 stages · 24h · also needs Prompting, which is not on this route

9Specialisms

120h

By the end of this chapter: You have real depth in whichever areas the job you want asks for — vision, sequences, recommendations, time series, compression — instead of breadth and nothing else.

What ready looks like

Not “finished the route”. These are things you can do, and each one is something an interview will actually ask you to do.

You can take a business problem to a trained model and a served endpoint without being handed a spec for either.
You can choose a metric that matches the cost of being wrong, and defend it against an easier one that looks better.
You can implement a transformer's attention from scratch, and explain what pretraining and fine-tuning each buy.
You can debug a training run that runs and does not learn, which is a distinct skill from debugging one that crashes.
You can train something too big for one GPU and say where the memory went.
You can design an ML system end to end in an interview: data, training, serving, monitoring, and what you would cut.
You can show one launch where you moved a real metric, and say what you would do differently.

What this route is not

Publishing. If the goal is to be a research scientist at a frontier lab, this route stops short of research practice — reading, experiment design, writing, taste — which the Research route covers.

Commonly over-studied by ML engineers

These are on the route because they come up, but people reliably spend more time here than the role repays. Read the topic for the reason.

GPUs & accelerators — Writing custom kernels is a niche specialisation that very few roles require, and being able to read one is enough almost everywhere. Learn what the hardware does to your throughput; do not start by learning CUDA.
Sequence models before transformers — Many courses still spend weeks here. For applied work today, understand the limitation and move on.

Start at Python, or see this route drawn on the map. The question bank covers every topic here.

The AI Engineer route The Research route