Reading an AI job ad: spotting the real scope behind the title

What an ad says, and what it lets you infer

A job ad is a compromise document. It is written by several hands — an engineering team, a recruiter, sometimes an executive — and it mixes what the company actually wants, what it believes it should write, and what was copied from a previous ad. Reading it literally leads to two symmetrical mistakes: applying for roles that do not fit, or skipping roles that did.

The goal is not to check whether you tick the boxes, but to reconstruct the real role: which problem the company wants gone, which responsibility it hands over, and in what environment the work will happen.

This guide answers one question: “does this opportunity genuinely match my profile and what I am looking for?” How to present your experience afterwards is covered in the guide on tailoring your CV.

The title first, then the real job

Start by ignoring the title. Read the paragraph describing day-to-day work and responsibilities first: it is almost always the least edited part, and therefore the most reliable. Titles depend on internal grading as much as on the content of the role.

Three questions rebuild the job:

• Which problem should the hire make go away? A system that does not exist, a system that works badly, or a team that cannot ship?
• What would visible success look like after six months, from the company's point of view?
• Is the role new, a replacement, or opened after a previous attempt?

If the text answers none of the three, that is not disqualifying — but it becomes the first thing to ask in an interview.

Real responsibilities and level of autonomy

Two roles with the same title can carry opposite responsibilities. The wording usually gives away the expected autonomy: “contribute to”, “participate in” and “support” do not describe the same thing as “define”, “arbitrate” or “own”.

• High autonomy: you choose the approach, defend trade-offs and own the outcome.
• Framed autonomy: the architecture is set, you decide within an existing frame.
• Low autonomy: choices are made elsewhere and you implement them.

None of the three is bad in itself; they simply suit different moments in a trajectory. The problem starts when the ad promises the first and the organisation described matches the third.

Must-haves, nice-to-haves, and catalogues

Most ads blend three lists: what is genuinely required, what would be comfortable, and what was added out of caution. A twenty-item stack is not a specification; it is a list of everything the team uses, including what nobody will touch in the first six months.

• Useful signal: a few technologies named with their purpose — “vector store for document search”, “batch orchestration”.
• Weak signal: an enumeration with no context, listing competing frameworks and tools belonging to different jobs.
• Warning sign: advanced expertise demanded across a set of tools no single person practises daily.

Focus on what appears in the description of the work, not only in the skills list. Whatever shows up in both is genuinely expected.

AI Engineer, ML Engineer, Data Scientist, GenAI Engineer

These titles overlap, and many ads use them interchangeably. Rather than looking for the correct definition, look for the object of the work described in the text.

• The work is about existing models embedded in a product — calls, context, retrieval, evaluation, reliability in production: that is an AI Engineer orientation, whatever the title says.
• The work is about training, validation, retraining, training data and deploying in-house models: ML Engineer orientation.
• The work is about analysis, statistical modelling, experimentation and presenting results to decision-makers: Data Scientist orientation.
• The work is specifically about generative systems — assistants, RAG, agents, industrialised prompting: GenAI orientation, often close to AI Engineer with a product emphasis.

When an ad mixes all four, it is not always confusion: it can indicate a small team where one person covers several roles. What matters is which one will take most of the time, and that is an interview question.

Finally, look at how much software engineering appears: tests, code review, CI, deployment, on-call. Its presence indicates a role where code genuinely reaches production; its complete absence in a role advertised as “in production” is a contradiction worth clarifying.

Experimentation or production, data and infrastructure

This is the most discriminating dimension, and often the least explicit. Exploration roles and industrialisation roles demand different reflexes and leave different marks on a career.

• Exploration signals: notebooks, proofs of concept, experiments, “assess feasibility”, no mention of end users.
• Production signals: SLAs, monitoring, cost, latency, volume, incidents, model versions, existing users.
• Data signals: a warehouse or platform, a separate data team or none, mentions of quality, governance or access rights.
• Infrastructure signals: a named cloud, an orchestrator, existing industrialisation — or nothing at all, which often means building it is part of the job.

When RAG, agents or LLMs appear, look at what surrounds them. An ad mentioning evaluation, answer quality, failure handling or cost control describes an operated system. An ad that never mentions any of it more likely describes an intention.

Seniority, team and reporting line

Seniority stated in years says little; context says a lot. A “senior” role in a fifteen-person team with a tech lead does not carry the same expectations as a “senior” role that turns out to be the company's first AI hire.

• Team size and composition: are there already AI or data profiles, or only developers?
• Reporting line: engineering, product, business, R&D — it determines who you will explain your trade-offs to.
• Named stakeholders: a tech lead, a product manager, a business unit, an end client.
• Presence or absence of an engineering frame: review, tests, industrialisation, evaluation practices.

An ad that describes the team and how it works is already a maturity signal: someone thought about the role before publishing it.

A five-dimension reading method

To compare several offers without getting lost, rate each one on five axes, one line each. It takes five minutes and makes decisions far easier.

• Object: product, platform, exploration, or support to other teams.
• Maturity: first AI project, system under construction, system already in production.
• Responsibility: execution, framed decisions, owned decisions.
• Dominant craft: model integration, training, data, software engineering.
• Conditions: location, rhythm, organisation, explicit constraints.

An offer that stays unreadable on three axes or more is not necessarily bad, but it calls for an exploratory conversation before any prepared application.

Decoding an excerpt

Here is a fictional excerpt, close to what you commonly encounter. The right-hand column shows what to take from it.

Signs of a vague or contradictory ad

• No concrete problem mentioned, only technologies and ambitions.
• One role supposedly covering research, data engineering, production and client relationships.
• Production expectations with no mention of infrastructure, testing or quality.
• High seniority required for a scope described as purely executional.
• A skills list longer than the description of the work.
• Fashionable vocabulary with no object: “agents” with no use case, “generative AI” with no identified user.

One or two of these call for questions. Four or five indicate the company has not defined the role yet — an opportunity if you want to define it yourself, a trap otherwise.

Do you need to tick every box?

No, and waiting to tick them all means only applying below your level. The useful reading separates what is structural from what can be learned.

• Structural: the type of work expected, the level of responsibility, the relationship to production, the domain when the ad explicitly requires it.
• Learnable: a specific tool, a particular cloud, an orchestration framework, one vector database.
• Negotiable in interview: the advertised seniority, part of the scope, working arrangements.

If the core of the role matches what you can demonstrate and the gaps are tooling, apply. If the gap is the nature of the work itself — exploration when you want production, or the reverse — the ad has done you a favour by saying so before the interview.

Methodical reading saves time on both sides: fewer misdirected applications, and much sharper interviews.

• Job search
• AI Engineering