A job description is a marketing document written by several people who disagree. Reading it as a specification is how candidates talk themselves out of roles they would have got, and into roles that turn out to be something else entirely.
Requirements are not requirements
Most postings list more than the role needs, because they are assembled from a template, a hiring manager's wish list and whatever the last person in the role happened to know.
The signal is in the ordering and the repetition. What appears in the first two bullets, in the summary paragraph, and again in the responsibilities is what the job is. What appears once, at the bottom, next to four other technologies, is a preference.
Five years of experience with a framework that has existed for two is a reliable sign the list was not written carefully — and a reliable sign that the numbers elsewhere are soft too.
Working out what the role actually is
Job titles in this field are close to meaningless. "AI Engineer" covers everything from prompt work on an existing product to training models from scratch. The responsibilities section tells you more than the title, and the interview process tells you most of all.
- Heavy on dashboards, SQL and stakeholders: an analytics role with an AI label.
- Heavy on pipelines, orchestration and infrastructure: data engineering.
- Heavy on APIs, retrieval and product surfaces: applied AI engineering, which is where most current hiring is.
- Heavy on training, architectures and papers: research, and usually gated on a postgraduate degree in practice even where the posting does not say so.
The 60% question
The common advice is to apply if you match around 60%, and it is broadly right — but the useful version is more specific. What matters is not the percentage but which 40% you are missing.
Missing a framework you could learn in a fortnight is not a reason to skip a posting. Missing the central thing the role does every day is. Read the responsibilities, not the requirements, to work out which of those you are looking at.
Questions worth asking them
The interview is your only reliable source on what the role is, and most candidates use their question time badly. Three that consistently produce useful answers:
- What does the first ninety days look like for whoever takes this? Vague answers usually mean the role is not well defined yet.
- What is currently in production, and who maintains it? Distinguishes teams shipping from teams still experimenting.
- How do you measure whether an AI feature is working? A team without an answer is a team where you will be the one inventing it, which may be a good thing or an exhausting one.
Signals worth taking seriously
Some things in a posting predict the experience of the job more reliably than the requirements do, and they are easy to miss because they are not presented as information.
- A very wide salary band usually means the level is not settled, which can favour you in negotiation and can also mean the role is not clearly defined.
- No salary at all in a market where it is normally disclosed is worth one direct question early, before either side invests time.
- A requirements list spanning data engineering, modelling, frontend and deployment is often one person expected to do four jobs. Sometimes that is a genuinely good early-career opportunity; it is never a small one.
- Wording about "fast-paced" and "wearing many hats" is honest signalling about headcount, and should be read as such rather than as culture language.
- A posting reappearing every few weeks for months usually means something is wrong upstream — compensation, the manager, or an unrealistic specification.
Applying badly is worse than not applying
Volume applying to everything with one generic CV is the default strategy and it performs poorly, for a reason worth understanding: the marginal cost of an application is near zero for you, which means it is near zero for everyone, which means the pile is enormous and shortlisting is brutal.
Ten applications where the project bullets were reordered to match the posting and the cover note names something specific about the role will out-perform a hundred generic ones. That is not a motivational claim about effort; it is arithmetic about which pile you land in.
The exception is early-career hiring at scale, where processes are more mechanical and volume genuinely helps. Even there, the reordering edit costs five minutes and is worth doing.
What reading a posting cannot tell you
The posting is a marketing document. The real role often differs, sometimes substantially, and no amount of careful reading closes that gap — only the conversation does.
That cuts both ways, and it is the argument for applying to things you are unsure about. You are not making a final decision by applying; you are buying information.
Key takeaways
- 1.Requirements listed once at the bottom are preferences. What repeats is the job.
- 2.Titles are meaningless in this field. Read the responsibilities to find out what the role is.
- 3.Which 40% you are missing matters more than the percentage.
- 4.A posting is marketing. Applying buys you information rather than committing you to anything.
Do it now, free
Job Description Analyzer
Job postings are written to attract, which makes them hard to read. This separates what is genuinely required from what was added by committee, and tells you where your gaps are if you paste your background.
No sign-up. The internship is free to join too, with real project briefs and reviewed submissions.