Resumes for Machine Learning Engineers

Machine learning resumes tend to be written as if the model were the deliverable. A list of architectures, a list of frameworks, and an evaluation figure with no baseline next to it.

The work being hired for is almost never the model. It is the pipeline that produces its training data, the service that serves it, the mechanism that notices when it degrades, and the judgement about whether the whole apparatus was worth building. Those are engineering problems, and they are what a technical reviewer is equipped to evaluate.

Where the model metric goes wrong

An evaluation number on a resume raises three questions immediately, and a bullet that doesn’t answer them is worse than one with no number at all.

Against what baseline? A classifier’s accuracy is meaningless without the trivial alternative — the majority class, the existing rules engine, the previous model. A lift over a stated baseline is informative; a bare figure is not.

Measured on what? A held-out split, a temporal split, or a live comparison are three very different claims, and the difference between them is the entire discipline. Naming your evaluation setup is a stronger signal than the number it produced.

Did it survive contact with production? Offline improvements frequently don’t. An engineer who says so is more credible than one who doesn’t mention it.

Weak: Developed a customer churn model achieving high accuracy using XGBoost and scikit-learn.

Better: Replaced a rules-based churn flag with a gradient-boosted model, evaluated on a forward-in-time split to avoid leakage from the rules the sales team was already acting on. The lift over the rules baseline was modest; the useful part was calibrated probabilities, which let the retention team rank rather than threshold.

That second bullet contains a leakage consideration, a stated limitation, and an explanation of why the work mattered anyway. It is far more persuasive than a large number would have been.

The four stages, and what to write about each

Data. In most ML roles this is the majority of the work and the minority of the resume. Feature pipelines, labelling, the join that turned out to be wrong, deduplication, the discovery that a field changed meaning in the middle of the history. All of it is describable using the pipeline discipline in resumes for data engineers, and the strongest ML bullets are often data bullets.

Illustration: Rebuilt the feature pipeline so training and serving read the same transformations from one definition — the previous split had a normalisation applied in training and not at inference, which accounted for most of the gap between offline and live performance.

Training-serving skew is the archetypal hard problem of the field. Anyone who has fixed a case of it should say so.

Training. Worth describing when there was an engineering problem in it: distributed training, cost or time constraints, reproducibility, experiment tracking that let someone else repeat your result. Not worth describing as a list of architectures you have used.

Serving. The part reviewers most want evidence of and resumes most often omit. Online versus batch inference, latency budget, model loading and warm-up, versioning, rollback, shadow deployment, how a new model got compared to the incumbent in production. This is ordinary systems engineering and it is where an ML engineer proves they are an engineer.

The loop. Monitoring for drift, retraining triggers, the feedback data your own predictions create, and the human process for reviewing a model’s mistakes. A candidate who has operated a model over time, not just shipped one, is scarce.

Honest scope on an ML team

The division of labour varies enormously — in some teams the same person owns the data, the model, and the service; in others a research group produces models and an engineering group runs them. Both arrangements are normal, and the resume risk is describing a collaboration as sole authorship.

Precise constructions that lose you nothing:

Productionised the ranking model our research team trained — built the feature service, the batch scoring job, and the shadow comparison against the previous version.

Owned the recommendation model end to end, including its features, its offline evaluation, and the endpoint that served it.

Contributed the evaluation harness and the temporal-split methodology to a team model; the architecture work was another engineer’s.

The general principle is the one in scope, not years: the narrower true claim is the stronger paragraph.

Research, publications, and competitions

Papers. If you have them, they belong on the page — checkable and load-bearing. One line each, and for an engineering role rather than a research one, keep it short and put the systems work first. A resume where publications outweigh production work will be read as a research application.

A PhD. Say what the technical content was in a clause, because “PhD in machine learning” spans an enormous range. Whether the work involved implementing systems, and at what scale, is the part an engineering reviewer wants.

Competitions. A strong placing in a serious competition is genuine evidence of modelling skill and worth one line. It is not evidence of any of the four stages above except training, and it should not be the top of your page for an engineering role. What competitions notably don’t demonstrate is problem framing, since the problem, the metric, and the data all arrived pre-decided.

Courses. A certificate is not evidence. A project you built afterwards, with a decision in it, is — the argument in the first engineering resume.

Working with large language models, without the hype

A lot of recent ML engineering is integration work: building a feature on top of a model you did not train, from a provider whose behaviour you do not control. This is legitimate engineering and it is easy to write badly, because the vocabulary is saturated with marketing.

Write the systems problems, which are the real content:

Illustration: Built the retrieval layer for an internal question-answering feature — chunking and embedding the documentation corpus, a re-ranking step, and an evaluation set of questions with known answers so a prompt or model change could be compared rather than guessed at.

Illustration: Added caching, request batching, and a per-tenant budget to the inference path after the first month’s usage made the cost profile clear.

Both describe engineering. Neither claims a capability the model may or may not have, and neither asserts anything about a specific provider’s internals or version behaviour — which is wise on a resume in a field where those change without notice, and which keeps you out of a conversation you can’t win.

The evaluation set is the detail worth including. Anyone can wire up a model; the people who can tell whether a change made things better are rarer, and saying that you built the means to tell is the strongest available signal.

The skills block

Group by stage rather than by fashion:

Languages Python, SQL Modelling PyTorch, scikit-learn, XGBoost Data Spark, dbt, Airflow Serving & infra FastAPI, Docker, Kubernetes, Triton Tracking MLflow, Weights & Biases

The shape tells a reader whether you are closer to research or to production, which is the first thing they are trying to work out. The general rules — no proficiency bars, no listing every framework — are in the tech stack list problem.

The check

Read your ML bullets and count how many describe something other than a model.

If the answer is none, the resume is a research CV applying for an engineering job. Add the feature pipeline, the serving path, or the evaluation mechanism — whichever you genuinely built — because those are the parts the team is short of.