Machine learning engineering is closer to backend engineering than to data science, and CVs that miss this distinction get filtered by both. The reviewer wants to know whether you can put a model behind an endpoint that stays up, retrain it without a person copying files around, and explain what it costs to run.
The strongest material is therefore operational: inference latency at the ninety-fifth percentile, throughput, GPU utilisation, the size of the training set, how long a retraining cycle takes and what triggers it. Model architecture matters, but it is rarely the constraint.
This example is written for an engineer with five years of experience who has built and operated model-serving infrastructure.
Opens in the editor with this content already filled in, so you can replace it with your own.
George Whitmore
Machine Learning Engineer · Model Serving & MLOps
george.whitmore@example.co.uk+44 7700 900965Cambridge, United Kingdomlinkedin.com/in/example-george-whitmoregithub.com/example-gwhitmore
Profile
Machine learning engineer with five years building and operating model-serving infrastructure. Recent work covers a Triton cluster holding p95 inference at 45ms across four models, a drift-triggered retraining pipeline, and a 58% reduction in monthly inference cost through quantisation.
Professional Experience
Machine Learning EngineerJuly 2022 – Present
Fenland Diagnostics Technology · Cambridge, United Kingdom
•Moved four models from notebook hand-off to a Triton serving cluster on Kubernetes, holding p95 inference at 45ms for around 700 requests a second with autoscaling on GPU utilisation.
•Built an Airflow retraining pipeline triggered by a drift threshold rather than a fixed schedule, with automatic promotion only when the challenger beat the champion on a held-out week of live traffic.
•Cut monthly inference cost by 58% by quantising two models to INT8 with ONNX Runtime and moving the smaller one from GPU to CPU instances with no measurable accuracy loss.
•Introduced model versioning and one-command rollback after a bad promotion required a four-hour manual recovery; subsequent rollbacks have taken under two minutes.
•Share on-call for the inference platform and wrote the runbook covering the three most common failure modes.
PyTorch · Triton · Kubernetes · Airflow · MLflow
Software Engineer (ML Platform)January 2020 – June 2022
Orrell Data Systems · Manchester, United Kingdom
•Built the feature store that replaced six duplicated feature pipelines maintained separately by three teams.
•Packaged the team’s training code as a versioned library with tests, which took experiment reproduction from "sometimes" to reliable.
•Reduced Spark training data build time from 6 hours to 50 minutes by repartitioning and switching to Parquet with column pruning.
Python · Spark · Docker · AWS
Platform Projects
Inference cost dashboard
Author
•Internal tool attributing GPU cost per model and per customer, which made the quantisation case measurable and led directly to the 58% reduction.
Education
MEng Computer ScienceSeptember 2015 – July 2019
University of Manchester · Manchester, United Kingdom
First Class Honours
Machine Learning Engineer example on the Technical layout. All details are fictional and shown for demonstration only.
What recruiters expect
Before writing anything, it helps to know what the person reading is checking for. In this field that is usually a short, specific list:
Serving experience with numbers: p95 latency, requests per second, batch sizes.
A retraining pipeline that runs without manual steps, and what triggers it.
Strong software engineering: testing, code review, packaging, CI. ML engineers are engineers first.
Cost awareness, particularly GPU spend and where inference can be moved to cheaper hardware.
Model governance: versioning, reproducibility, rollback, and what happens when a model must be withdrawn.
Recommended CV structure
This is the running order the example uses. It is a starting point rather than a rule, but the order reflects what tends to be read first in this profession.
Profile — Three or four lines positioning you for the role.
Technical Skills — Grouped skills, for example "Languages" and "Tooling".
Professional Experience — Paid roles, in reverse chronological order.
Platform Projects — Work you built, with outcomes and the stack used.
Education — Degrees, diplomas and school-leaving qualifications.
Certifications — Completed certifications with the issuing body.
Languages — Spoken languages with CEFR levels.
Sections worth adding
Publications — Include if you have applied papers or an accepted workshop submission.
Open Source — Contributions to serving or pipeline tooling are particularly relevant here.
Skills worth including
Grouped rather than listed in one block. Grouping makes a long list readable and shows that you can tell the difference between the things you use daily and the things you have touched.
Beyond the technical list: Working between data science and platform teams, Design documents, Cost conversations, On-call for model services. These belong inside your experience bullets, demonstrated, rather than in a list of adjectives.
Example professional summary
Three or four lines, positioned for the role rather than describing your personality. Two versions you can adapt:
Machine learning engineer with five years building and operating model-serving infrastructure. Recent work covers a Triton cluster holding p95 inference at 45ms across four models, a drift-triggered retraining pipeline, and a 58% reduction in monthly inference cost through quantisation.
ML engineer with a backend engineering background. Comfortable owning the path from a data scientist’s notebook to a monitored, versioned, rollback-capable service - and the on-call rota that comes with it.
Writing your experience
The difference between a CV that gets a call and one that does not is almost always in the bullet points. Each pair below shows a real rewrite of the kind of line that appears on most CVs in this field.
Weak
Deployed machine learning models to production.
Stronger
Moved four models from notebook hand-off to a Triton serving cluster on Kubernetes, holding p95 inference at 45ms for around 700 requests a second with autoscaling on GPU utilisation.
Names the serving stack and the two numbers that define whether it works.
Weak
Automated model retraining.
Stronger
Built an Airflow retraining pipeline triggered by a drift threshold rather than a fixed schedule, with automatic promotion only when the challenger beat the champion on a held-out week of live traffic.
Shows a governance design, not just automation.
Weak
Reduced infrastructure costs.
Stronger
Cut monthly inference cost by 58% by quantising two models to INT8 with ONNX Runtime and moving the smaller of them from GPU to CPU instances with no measurable accuracy loss.
Technique, measurement and the accuracy caveat that makes the claim credible.
Taken from the example
The sample CV for this profession is fully written. A few sections from it, so you can see the level of specificity that works:
Moved four models from notebook hand-off to a Triton serving cluster on Kubernetes, holding p95 inference at 45ms for around 700 requests a second with autoscaling on GPU utilisation.
Built an Airflow retraining pipeline triggered by a drift threshold rather than a fixed schedule, with automatic promotion only when the challenger beat the champion on a held-out week of live traffic.
Cut monthly inference cost by 58% by quantising two models to INT8 with ONNX Runtime and moving the smaller one from GPU to CPU instances with no measurable accuracy loss.
Introduced model versioning and one-command rollback after a bad promotion required a four-hour manual recovery; subsequent rollbacks have taken under two minutes.
Projects
Inference cost dashboard — Internal tool attributing GPU cost per model and per customer, which made the quantisation case measurable and led directly to the 58% reduction.
Education
MEng Computer Science, University of Manchester — First Class Honours
If the bullets are about model selection and feature engineering, you will be screened as a data scientist. Lead with serving and pipelines.
No latency or throughput figures
These are the defining constraints of the role. Their absence suggests you have not owned a live service.
Ignoring cost
GPU spend is a board-level concern in most organisations running models. A cost reduction is one of the most persuasive bullets available.
Weak software engineering signals
Notebooks-only experience is a common concern with this title. Mention tests, packaging and review explicitly.
ATS considerations
Applicant tracking systems behave differently by sector, and generic advice is often wrong for a given field. These points are specific to machine learning engineer applications:
Include "MLOps" and "model deployment" as phrases; they are the two most common filters for this title.
Name the serving stack explicitly - Triton, TorchServe, SageMaker endpoints - rather than only "deployed models".
Keep "software engineering" vocabulary on the CV: testing, code review, CI. Many ML engineer adverts are written by platform teams.
State GPU experience precisely, including the hardware class where it is relevant.
The Minimal ATS layout is built for this, and the ATS guide covers what parsers do to a file in more detail.
Questions about machine learning engineer CVs
What is the difference between an ML engineer and a data scientist?
A data scientist is accountable for whether the model is right; an ML engineer is accountable for whether it runs. Most job adverts follow that split even when the titles blur.
Do I need Kubernetes?
It is common but not universal. Managed platforms such as SageMaker or Vertex AI are equally valid experience - name whichever you have actually operated.
How much modelling should I show?
Enough to prove you can read and debug a model, not enough to look like you want a research role. One or two bullets is usually the right balance.