Two readings of the same track record
AI Engineer and ML Engineer overlap heavily as titles, but the expectations behind them differ. The useful distinction is not the label: it is whether the company wants someone who builds a product around existing models, or someone who builds and hardens the models themselves.
Product-facing reading
Integrating existing models, designing the system around them, evaluating perceived quality, shipping, cost and latency. The deliverable is an application that holds up.
Model-facing reading
Data preparation and quality, experimentation, training or adaptation, performance measurement, lifecycle industrialisation. The deliverable is a reliable, reproducible model.
Plenty of roles mix both. Your CV should make the dominant one visible, not deny the other.
One project can therefore feed both readings. An internal assistant built on an existing model carries an integration and production story, but also a data quality and measurement story. What you foreground changes; the facts do not.
Spotting the expected reading in the job ad
The title is unreliable. Four signals in the body of the ad say far more. For reading an ad in full, our guide on reading an AI job ad goes further; here we keep to what changes the CV.
- Data: talk of collection, labelling, quality or volume points to a model-facing reading.
- Production: talk of users, latency, cost, availability or support points to a product-facing one.
- Deliverables: “a service”, “an application”, “an API” on one side; “a model”, “a training pipeline”, “a performance improvement” on the other.
- The counterparts named: product and business signal an application focus; research and data engineering signal a model focus.
When an ad is too vague to call, that is information in itself: the role is probably not settled yet. Prepare the question for the interview rather than the perfect CV variant.
Reorder before you rewrite
The most effective edit is also the fastest: change the order. A first pass over a CV is short, and it happens at the top of the page.
- Header: one positioning line naming the systems you build, not a generic title.
- Within a role: put the responsibilities matching the expected reading in the first bullets.
- Skills: grouped by use — building, evaluating, operating — not as an alphabetical tool list.
None of this changes a single fact. It simply makes the relevant part legible for this specific role, which is exactly what a CV is for.
Writing a bullet that earns its line
Most CV bullets describe a task. A useful bullet describes a decision. The sturdiest frame has three parts: the problem, the decision, the observable outcome.
Before
“Built an internal chatbot with Python, LangChain and a vector database.”
After
“Document search assistant for the support team: procedures indexed by version, mandatory source citation, evaluation set reviewed by two domain leads. Cut answers drawn from outdated documents.”
No invented figures: an observable outcome can be qualitative as long as it holds up under questioning.
A bullet also gains credibility when it says what you personally carried. “We put in place” cannot be checked in an interview; “I designed the indexing and the evaluation set, the team handled production” can. Separating your part from the team's does not weaken the story: it is what makes it open to questioning.
Before (model-facing)
“Trained classification models on customer data, improved performance.”
After (model-facing)
“Ticket classification model: rebuilt the training set with the support team to fix inconsistent labelling, moved validation to time-based splits rather than random ones to remove temporal leakage, automated monthly retraining. Narrowed the gap between validation and observed production behaviour.”
Same track record, other reading: what is demonstrated here is data, protocol and reproducibility.
Only quote a number if you can explain how it was measured. An improvement claimed without a measurement method reads as marketing, and it turns against the candidate in the technical interview.
The skills section: drop the tool list
A long tool list no longer differentiates anyone and blurs your actual level. Three groupings are enough, and they mirror how interviews are structured: build, measure, operate.
- Building: languages, orchestration frameworks, stores in use, the kinds of systems you have actually shipped.
- Evaluation: quality measurement methods, building example sets, human review.
- Operations: deployment, monitoring, cost management, model lifecycle.
Separate what you practise from what you have merely touched. Two distinct blocks — daily practice and working knowledge — read far better than one flat list where everything looks equal.
Side projects, courses and certifications
These matter most when your professional experience does not yet cover the expected reading: a Data Scientist targeting an applied role, or an application engineer targeting a model-facing one.
- Keep two projects at most, genuinely reachable and documented.
- Describe the problem and the known limitation, not the stack; an unexplained repository hurts more than it helps. Our guide on building a credible AI portfolio on GitHub covers what a reviewer actually looks for.
- Certifications signal entry into a field, not experience: never place them above your roles.
- Drop course projects identical to thousands of others unless you extended them substantially.
Two versions, not one per ad
Maintaining a CV per posting is unsustainable and produces inconsistent documents. Two stable versions — one product-facing, one model-facing — cover almost every application. Each submission then needs only a header tweak and a reshuffle of the first bullets.
On formatting conventions, follow the market you are targeting rather than a universal rule: expectations differ across France, Spain and international markets, particularly on photos, length and document language. When in doubt for an international company, an English version, no photo, two pages maximum remains the safest option.
On automated filters, stay measured: reusing the ad's terminology where it genuinely matches your experience helps you be found, while stacking keywords fools no one and shows at the first question. Write for a human reader, using the words that reader uses.
Final pass before sending
Six checks once the CV is done. Each one takes under ten minutes to fix.
- The first visible experience matches the reading the ad expects.
- Every bullet contains a problem, a decision and an observable outcome.
- No number I could not explain in an interview.
- The skills section separates what I practise from what I have merely touched.
- Linked personal projects are reachable and documented.
- A non-technical reader understands what I can solve within thirty seconds.
Key takeaways
- Two role families, two readings: product/integration or model/experimentation.
- The ad tells you which one: look at data, production and the deliverables it names.
- Reordering and rephrasing is almost always enough; rewriting your history is neither useful nor credible.
- A useful bullet contains a problem, a decision and an observable outcome.
- Keep two CV versions per role family, not one per job ad.
- Opportunities
- AI Engineering
- MLOps
- Evaluation