The AI skills employers are actually hiring for

Read enough AI job postings and you will see the same inflated list: a dozen frameworks, three cloud providers, several databases and a vague requirement for "strong communication". Very few teams expect any single candidate to have all of it. The list is usually written by committee and rarely pruned.

What consistently decides interviews is narrower. Can you write solid code. Can you get data into a usable shape. Can you tell whether the thing you built is actually working. Almost everything else is learnable on the job, and hiring managers know it.

This gap has a practical consequence worth naming: candidates routinely rule themselves out of roles they would get. A posting listing fifteen requirements is describing an ideal nobody matches, and the people who apply anyway are competing against a much smaller field than the list implies.

If you are choosing where to spend limited time, these compound faster than anything else. They are also the ones that survive a shift in tooling, which matters when the popular framework changes every eighteen months.

The common thread is that each is about getting something to work reliably rather than about knowing a particular library. That is why they transfer: a person who can shape messy data, build something end to end and prove it works is useful on any stack, and a person who knows one framework deeply is useful until that framework falls out of use.

• Python and general software engineering — most production AI work is ordinary engineering with a model somewhere inside it
• SQL and data modelling — underrated, asked about constantly, and the bottleneck on most real projects
• Evaluation — defining what "correct" means for your system and measuring it honestly
• Retrieval and context handling — how you get the right information in front of a model, which is where most LLM products actually live or die

Of the four, evaluation is the one where demand most outstrips supply. Every team shipping something built on a model eventually hits the same wall: they cannot tell whether a change made it better, so every decision becomes an argument about vibes.

The skill itself is concrete. It means deciding what correct looks like for an open-ended output, building a set of examples with known-good answers, measuring against them on every change, and being honest about what the measurement does not cover.

It is also unusually durable. A labelled evaluation set keeps its value when the model, the framework and the vendor all change, which is more than can be said for most of what appears in job postings. Candidates who can talk concretely about how they evaluated something stand out immediately, because so few can.

Memorising model architectures rarely comes up unless you are interviewing for research. Neither does the ability to derive backpropagation by hand. These are useful for understanding, but they are almost never the thing that separates two candidates.

Collecting framework names is similarly low-yield. Someone who has shipped one working system with a single stack interviews far better than someone who has completed tutorials in five. Depth is legible to interviewers; breadth without depth reads as a list.

Prompt technique deserves a specific mention, because it is heavily marketed as a standalone skill. It is genuinely useful and it is not a job by itself — it is a small part of building systems, and it has a short shelf life as models change. Treat it as a technique you pick up, not a specialism you train for.

Sequence matters more than volume. Learning modelling before you can handle data is the most common wasted month, because you end up unable to build anything end to end.

The ordering below is deliberately conservative: each step produces something you can show, and each one makes the next easier. Skipping ahead is tempting because the later steps sound more impressive, and it reliably produces people who can describe a technique but cannot get a project working.

• Get genuinely comfortable with Python — not syntax, but writing something maintainable
• Learn SQL properly, including joins and aggregation over messy real data
• Build one small end-to-end project with an existing model and real data
• Add evaluation: decide what good looks like and measure whether you hit it
• Only then go deeper into training, fine-tuning or architecture

Having a skill and being hired for it are different challenges. Most AI roles are keyword-searched heavily because they attract enormous applicant volumes, so a resume that does not name the specific tools in the posting frequently never surfaces in a recruiter search.

Mirror the posting’s vocabulary where it is genuinely true of you, and put the concrete stack on the page rather than describing it abstractly. Then check the resume against the actual job description before applying — closing a vocabulary gap costs minutes and is the cheapest improvement available to you.

Be specific about outcomes as well as tools. "Built a retrieval system over 40,000 documents; cut unanswered queries from 30% to 9%" survives scrutiny in a way that "experience with RAG pipelines" does not, and it gives the interviewer something to ask about.