AI & hiring · 8 min read

The AI skills employers actually ask for in 2026

Almost every role now mentions AI somewhere, and almost none of them mean the same thing by it. The gap between what postings say and what the job requires is wider here than in any other skill area right now, which makes it hard to know what to learn and harder to know what to claim.

This is a rotating post, revisited as the market moves. What follows is the shape of the demand as it currently stands rather than a prediction about where it goes next.

Three different jobs wearing the same word

The first is building AI systems: training, fine-tuning, serving models, evaluation, inference cost. This is a specialist engineering role and the bar is high — it wants machine-learning fundamentals, not familiarity with a chat interface.

The second is building products on top of models someone else trained. Prompt design, retrieval, tool use, evaluation harnesses, latency and cost management, and a great deal of ordinary software engineering around a probabilistic component. This category has grown fastest, and it is where most of the new postings sit.

The third, and by far the largest, is using AI to do an existing job better. An analyst who can get a first pass at a query, a marketer who drafts and edits rather than drafts from nothing, a support lead who builds a triage assistant. No new title, no model training, and the skill being hired is judgement about when the output is good enough.

Most candidates read a posting mentioning AI as the first category and disqualify themselves. Usually it is the third.

What actually appears in postings

The consistent asks are unglamorous. Familiarity with the major assistants and the ability to get useful output reliably. Understanding retrieval — why a model answers better when given your documents. Awareness of where models fail, particularly confident wrong answers, and the habit of verifying before shipping. Some understanding of cost, because inference is a line item. And increasingly, judgement about what should not be automated.

What appears far less than the discourse suggests: prompt engineering as a standalone job title. It briefly looked like a career and mostly folded back into ordinary roles, because the skill turned out to be a component of using the tools rather than a profession.

How to describe this on a resume without overclaiming

The failure mode is a skills line reading AI, ChatGPT, prompt engineering, which says nothing and invites a question you cannot answer. Describe the outcome instead, the way you would any other tool: what you built or changed, and what it saved.

Cut first-draft time on weekly reporting by roughly half using a retrieval assistant over our own documentation is a claim with substance. It names a task, a mechanism and a result, and it survives the follow-up. AI-driven productivity improvements does not survive anything.

Be ready to say what did not work. The most credible candidates in this area talk about where they stopped using it — the summaries that were confidently wrong, the code that looked right and was not, the point at which reviewing the output cost more than doing the work. That answer signals judgement, which is the actual scarce skill.

The disclosure question

Candidates ask whether to mention using AI in a take-home or on the job. Assume the answer is yes and that most employers assume you did. What matters is that you can explain everything you submitted, line by line — a review conversation finds the gap immediately, and being unable to defend your own work is worse than not using the tools at all.

Where a brief explicitly asks you to disclose, do it plainly: what you used it for and what you changed afterwards. That answer generally reads well, because it is the same answer a competent colleague would give.

What is worth learning if you are starting

Learn to get reliable output from the mainstream assistants on your own real work, and learn where they break. Learn the basics of retrieval — why grounding a model in your own documents changes the answer — because that concept underpins most current products. Learn to evaluate output, which is the skill that transfers across every model release.

For engineers, the practical additions are calling model APIs, structuring tool use, and thinking about latency and cost as first-class constraints rather than afterthoughts. For everyone else, the highest-return skill is knowing which parts of your job should not be handed over, and being able to explain why.

The claim to avoid

Do not describe yourself as an AI expert unless you can defend it against someone who is. It is the fastest way to lose a room, and the bar is being set by people who train models for a living. Uses these tools well, and knows what they cannot do is a stronger and more defensible position — and much closer to what most of these postings are actually hiring for.

The underlying advice has not changed with the technology. Name what you did, attach a number, and be ready to explain how you know. That worked before any of this and it still works now.

How to build evidence when your current job does not offer any

The common objection is reasonable: my employer has not adopted any of this, so I have nothing to point at. The answer is to build something small on your own work rather than to complete another course. Certificates in this area carry little weight because the field moves faster than the syllabus, and everyone has them.

What does carry weight is a small, finished, explainable thing. An assistant over your own notes that you actually use. A script that drafts the report you write every Monday. A tool that classifies your inbox. It does not have to be impressive; it has to be real, and you have to be able to say what it does badly as well as what it does well.

That last part is what separates a credible answer from an enthusiastic one. Anyone can say they built something with AI. Being able to explain that it works for the routine ninety percent and produces confidently wrong output on the edge cases, which is why you kept a human check in front of it, is the answer that gets taken seriously.

Where the hype and the hiring diverge

Two things are worth naming plainly because they cost candidates time. The first is chasing model-specific expertise. Which assistant you know is close to irrelevant, because they converge and change quarterly; the transferable skills are evaluation, retrieval and knowing where the failure modes are. Learning one deeply is fine, learning to switch is better.

The second is the assumption that AI fluency substitutes for the underlying craft. It does not, and it is currently being tested for. An engineer who cannot read the code they generated, an analyst who cannot sanity-check the number, a writer who cannot tell that the paragraph is empty — these are visible immediately in a review conversation. The tools raise the floor on output and raise the bar on judgement, and it is judgement that is being interviewed.

What this means for the rest of your application

Do not restructure your whole resume around this. For the large majority of roles, AI use is a line in your skills section and a clause in one or two bullets, not a headline. The work you have done and the results you produced remain the substance; how you produced them is context.

The exception is roles that are genuinely about building these systems, where it becomes the centre of the conversation and the bar is engineering depth rather than tool familiarity. Read the posting carefully enough to know which of those you are applying to, because the two applications look nothing alike.

Revisiting this post

This is a rotating entry, which on this site means it is expected to go out of date and is flagged for review when it has not been touched in a while. Job titles in this area are unstable, the tooling changes on a quarterly cadence, and any claim about what employers want is a snapshot. Treat the categories as durable and the specifics as perishable.

Interviewing for these roles

Expect at least one question aimed squarely at judgement rather than tooling. Where has this gone wrong for you, what did you stop automating, how do you check the output — these are the questions that separate the two kinds of candidate, and the strong answers are specific rather than balanced-sounding.

For product and engineering roles, expect to be asked how you would evaluate whether a feature built on a model is actually working. Most candidates reach for user feedback and stop. The stronger answer covers what you would measure before shipping — a held-out set of real examples, an agreed definition of a good answer, an error budget for the confidently wrong ones — because that is the part teams keep skipping and then regretting.

For non-technical roles, expect something closer to a scenario: your team wants to automate a process, how do you decide what to hand over. The answer that lands names the cost of being wrong. Automating something reversible and low-stakes is a different decision from automating something a customer sees, and saying so demonstrates the judgement being hired for.

A note on job titles

Titles in this area are unusually unreliable. The same posting content appears under AI Engineer, ML Engineer, Applied Scientist, Software Engineer (AI), and simply Software Engineer, depending on the company. Screening by title alone will make you miss roles you can do and apply for ones you cannot.

Read the responsibilities instead. If the posting talks about training, evaluation datasets and model architecture, it is the first category. If it talks about latency, retrieval, orchestration and shipping, it is the second and the bar is ordinary strong engineering. If AI appears once in a list of tools, it is the third and it is a normal job with a modern toolchain — which is most of them.

Related guides

Try JobStraight free →