Key takeaways
- Four skills carry most of the weight: Python, SQL, evaluation, and retrieval or context handling.
- Job ads list far more than any team expects one candidate to have; the list is written by committee.
- Depth beats breadth — one shipped system interviews far better than tutorials in five frameworks.
- Sequence matters: learning modelling before data handling is the most common wasted month.
- Evaluation is the most transferable skill and the one fewest candidates can demonstrate.
The gap between job ads and hiring reality
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.
The four that carry the most weight
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
| Skill | Matters most for | How it is tested |
|---|---|---|
| Python and engineering | Every production role | Practical coding, code review |
| SQL and data modelling | Data and analytics roles | Live query exercise |
| Evaluation | LLM and agent products | Design question, project deep dive |
| Retrieval and context | LLM application roles | System design round |
| Cloud, containers, CI/CD | Platform and MLOps | Architecture discussion |
Why evaluation is the one to lean into
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.
What is worth less than people assume
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.
A learning order that actually works
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
Proving the skill is a separate problem
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.
Frequently asked questions
Which AI skill should I learn first?
Python, then SQL. Almost every AI role assumes both, and most production work is data handling and ordinary engineering rather than modelling. Starting with model architectures before you can move data around reliably tends to waste time.
Do I need to know deep learning maths to get an AI job?
For research roles, yes. For the large majority of AI engineering jobs, a working intuition is enough — being able to ship, evaluate and debug a system matters far more than deriving the maths by hand.
How long does it take to become employable in AI?
For someone already programming, six to twelve months of consistent work including a real deployed project is a realistic range. From a complete standstill it is longer, and the timeline depends much more on shipping something than on courses completed.
Is prompt engineering a real skill to specialise in?
It is a useful technique rather than a standalone job, and it dates quickly as models change. Learn it as part of building systems, not as a specialism you train for.
Should I apply if I only have half the listed requirements?
Usually yes. Postings describe an ideal nobody matches, and the people who apply anyway compete against a much smaller field than the requirement list suggests.
Which single skill would most improve my interviews?
Evaluation. Every team hits the wall of not knowing whether a change helped, very few candidates can discuss it concretely, and a labelled evaluation set keeps its value when models and frameworks change.
Check this against your own resume
Scan your CV against a real job description, or build a parse-safe one from scratch. Your first scan costs nothing.