What's happening in AI and ML hiring (2026)
The roles have changed faster than most job descriptions have. Here is what has shifted and what it means for how you hire.
The roles are shifting
Most teams no longer start by training models from scratch. They start from a foundation model and spend their effort on everything around it: retrieval, evaluation, fine-tuning, guardrails, serving and cost. That has created a large group of roles, usually called LLM, GenAI or applied AI engineer, that sit between classic software engineering and ML research.
The older specialties have not gone away. Computer vision, speech, recommendation and forecasting teams still need people who know their domain deeply, and every model in production needs MLOps and data engineering underneath it. What has changed is that titles no longer tell you much. Two “ML Engineer” postings can describe completely different jobs, so the description has to do the work.
Where AI and ML hiring is concentrated
- 🧩 LLM & GenAI engineering: building products on foundation models
- ⚙️ MLOps & ML infrastructure: training, serving, GPUs and cost
- 🔬 Applied and research science: new methods and evaluation
- 🗄️ Data engineering: the pipelines every model depends on
What AI candidates weigh beyond salary
Strong ML candidates judge an offer by whether they will be able to do good work. Expect questions about compute (how many GPUs, how long jobs wait in the queue, who approves spend), about data (is there enough of it, is it labelled, can they get access in their first month) and about how models reach production. Vague answers here lose candidates who would have accepted the salary.
Researchers and research-leaning engineers also ask about publishing, open-source contributions and conference travel. If your policy allows them, say so in the job description; if it does not, say that too, so you do not spend an interview loop on someone who will turn the offer down.
The skills that are hard to find
Calling a model API is easy to learn and easy to claim. What separates candidates is the work that makes a model reliable: designing evaluations that catch regressions, reasoning about why a model fails on a slice of the data, and trading quality against latency and cost.
Screen for these directly. Ask candidates how they measured whether something worked, what broke in production, and what they would do differently. People who have shipped ML systems answer with specifics; people who have only built demos answer with tools.
Skills worth screening for
- ✓ Evaluation design: offline metrics, test sets, regression checks
- ✓ Retrieval and RAG systems, and how to tell when they fail
- ✓ Fine-tuning, and judging when it beats a better prompt
- ✓ Inference cost and latency: batching, caching, quantization
- ✓ Data quality: labelling, leakage, drift
Slow processes lose AI candidates
Experienced ML engineers and researchers usually run several processes at once. Every extra week between rounds is a week in which another team can make an offer. Being second with an equivalent offer is not a tie; it is a loss.
ML loops are especially prone to bloat: a coding round, an ML fundamentals round, an ML system design round, a research presentation and a take-home can add up to weeks. Decide which signals you actually need for the role and cut the rest. A take-home that needs a GPU the candidate does not have is a filter for free time, not skill.
What helps employers close
Be specific in the job description: what the model does, what stage it is at (research, prototype or production), the stack, and what the first project will be. Candidates use these details to decide whether to apply, and specific postings attract people who fit.
Then run the process like a sale as well as an evaluation: a salary range from the first message, interviews with written rubrics, a hiring manager who can talk about the technical work in depth, and a decision soon after the final round.