The ML engineer CV problem is specific and very recognizable: too many tools, too few results, no evidence anything you trained ever made it to production. Hiring managers skim past lists of libraries to find the one or two bullets that prove you can ship.

This post is about writing those bullets — and about the three structural choices that make an ML engineer CV land instead of getting filed under "yet another Kaggle profile."

What an ML hiring manager actually reads for

In 90 seconds with your CV, a senior ML engineer or hiring manager is checking three things, in this order:

1. Have you shipped a model to production? Not a notebook. Not a hackathon. A model that served real predictions to real users and that you owned the maintenance of.
2. Do you understand evaluation? Specifically — beyond accuracy. Did you pick the right metric for the problem? Did you measure offline vs. online? Did you catch your own model degrading?
3. What was your scope? Did you own the problem end-to-end (data, training, deployment, monitoring), or were you handed a labeled dataset and asked to maximize a metric?

If all three are clear in the first 90 seconds, you advance. If even one is missing, you are competing on tool lists, which is a fight you do not want to win.

The summary line — the first sentence that decides everything

Most ML CVs open with something like "Machine learning engineer with X years of experience in deep learning and computer vision." That tells the reader nothing they cannot guess from the section header.

A better opener names a domain, a scale, and an outcome:

ML engineer, 4 years building recommendation systems in production. Most recent: led the rollout of a deep retrieval model serving 12M users/day, +8% engagement vs. the previous matrix-factorization baseline.

Three elements: domain (recommendations), scale (12M users/day), outcome (+8% engagement, named baseline). That is one sentence that already answered the three questions above.

If you do not yet have a production project to point to, the opener should at least name a specific problem you have worked on deeply: "ML engineer focused on tabular fraud detection at small data scale (<100K labeled examples), benchmarked against XGBoost and CatBoost baselines." Specific beats grand.

The experience section — the model-shipping bullet template

The bullet pattern that lands for ML roles:

[Verb] [model type] for [business problem], trained on [data scale + source], evaluated on [metric + baseline], deployed via [serving stack], delivered [business outcome].

Filled in:

Built a sequence-aware ranker for the home feed, trained on 90 days of interaction logs (1.2B events), evaluated on offline NDCG@10 (+12% vs. the LambdaMART baseline) and online A/B (+4.1% session time, p<0.01), deployed via TensorFlow Serving on GKE behind a 30ms p95 SLO.

Every clause is doing real work:

• Verb + model type: tells the reader the technical surface (sequence ranker, fraud classifier, image segmenter).
• Data scale + source: lets them calibrate the engineering difficulty.
• Metric + baseline: shows you understand what "better" means in your context, and that you compared against something serious.
• Serving stack: signals that you owned the deployment, not just the notebook.
• Business outcome: closes the loop. The technical work mattered to the company.

Three or four bullets like this per role beats fifteen that list libraries.

The tools section — short, ranked, current

The instinct is to list everything. Resist it. A long tool list signals lack of focus and is dismissed in seconds.

The structure that works:

• Core (daily use): Python, PyTorch, scikit-learn, SQL, Docker, GCP.
• Working knowledge: TensorFlow, Spark, Airflow, FastAPI, Terraform.
• Familiar: Ray, Triton, ONNX.

Three tiers, six to eight items in the top tier, no more. Drop the tools you have not touched in two years — listing TensorFlow 1.x in 2026 is a tell.

Do not pad with framework versions, do not list "AI" or "Machine Learning" as tools (those are the field, not the tool), do not list a cloud provider as a single line item without saying what you used on it. "AWS" is meaningless; "AWS (SageMaker, S3, Lambda, IAM)" is meaningful.

The projects section — only if you actually have shipped or open-sourced work

A projects section helps when:

• You are early-career and your work history is thin.
• You shipped something side-of-desk that is more impressive than your day job.
• You contribute to a well-known open-source ML project.

It hurts when:

• The projects are Kaggle competitions with no production angle.
• The projects are tutorial reproductions ("trained a GAN on MNIST").
• The projects do not have a public link or evidence anyone uses them.

A project bullet that works:

Open-source contributor to [project] (GitHub stars: 8.2K) — implemented [feature], merged in v2.3, reduced p95 latency of [operation] by 34% (benchmark in README).

A project bullet that does not:

Built a chatbot using LangChain and OpenAI API.

For most mid-to-senior roles, drop the projects section if it would be padded with tutorial-grade work. Your experience section should be doing the heavy lifting.

Evaluation rigor — the signal that separates a junior from a senior

The quickest way to look senior on paper is to talk about evaluation the way a senior person talks about it. Three small writing moves:

1. Name the right metric for the problem. A fraud classifier with 99% accuracy is a bad fraud classifier. Use precision-recall, PR-AUC, or cost-sensitive metrics depending on the problem. Showing you picked the metric on purpose, not because it was the default, is a senior signal.
2. Compare to a real baseline. "Achieved 0.91 AUC" alone tells the reader nothing. "Achieved 0.91 AUC vs. 0.84 for the logistic regression baseline already in production" tells them everything.
3. Mention online evaluation when you have it. Offline metric improvements that do not translate online are the most common embarrassment in applied ML. If you ran A/B tests, name the result and the significance.

Three small moves. The CV reads completely differently.

What to drop or de-emphasize

• Course lists from online platforms. Coursera, Udacity, fast.ai are fine signals when you are early-career; they hurt above mid-level because they make the reader wonder why you are still listing classes.
• Hackathon wins more than three years old. Hackathons signal recent energy, not ancient achievement.
• "Published a Medium article on X". Unless the article got serious traction (10K+ reads or referenced by someone notable), it is filler.
• Lists of paper readings. Reading papers is the job; listing them is not the achievement.

This is similar to the trap we covered for adjacent roles in Data scientist CV: how to show impact, not just a tool list and Data analyst CV — the failure mode is the same across data/ML roles, the fix is the same too.

Length and structure

• One page if you are under five years of experience, two pages max above. ML engineers do not get bonus points for length.
• Reverse chronological work experience. Functional CVs are read as hiding something.
• Education section brief — degree, school, year. No GPA above mid-level. If you have a PhD with a strong publication record, the publications go in a separate section, not the education one.
• No photo. Even in markets where CVs traditionally include one, ML/tech hiring trends global and the photo-free version travels better.

How this CV pairs with the LinkedIn profile

Most ML hiring managers will check your LinkedIn within a minute of opening your CV. The two should tell the same story — same roles, same scope, same headline framing. A CV that says "led the deep retrieval rollout" and a LinkedIn that says "Machine Learning Engineer, passionate about AI" signals one of two things: the CV is exaggerated or the LinkedIn is neglected. Either way, you lose ground in the next 30 seconds.

Postulit pulls structured data from your LinkedIn into a CV that matches it, which solves the most common mismatch in ML hiring — the story is consistent across both surfaces, so the recruiter never has to decide which one to trust.

A 60-second self-check before you send

• Can a senior ML engineer answer all three questions (shipped? evaluated rigorously? owned end-to-end?) by reading just the top half of page one?
• Does at least one bullet in your last role name a production-serving stack?
• Does at least one bullet name a baseline you beat, by how much, on what metric?
• Did you cut the tool list down to three tiers with no more than eight items in the top tier?
• Did you remove anything more than three years old that does not represent who you are now?

Five yeses and you have an ML engineer CV that does not get filed under generic. Four out of five and you are still in the conversation. Three or fewer and the rewrite is faster than you think — start with the bullet template and one role, and the rest follows.