Most engineering CVs now mention AI. Some candidates have built and run models in production. Others have used an AI coding assistant, completed a short course, or worked alongside a team that did the hands-on work. On paper, all three can look much the same.
Demand is high. In Emergn’s study of 751 large organisations, 52% of senior leaders said they could not hire the data and AI skills they need. ManpowerGroup’s 2026 UK Talent Shortage survey found that AI skills, from basic literacy upwards, are now the hardest for UK employers to find. When supply is tight and the label is everywhere, assessment matters more.
Decide which AI capability you need
“AI engineer” covers several different jobs. Before assessing anyone, be clear which one you’re hiring for:
- Applied AI engineering: building product features on top of existing models, including retrieval, evaluation and integration.
- Machine learning engineering: training, deploying and monitoring models, along with the pipelines underneath them.
- Data engineering: making the data reliable enough for any of the above to work. Often the hire that should come first, as we covered in data engineering vs data science.
- AI-literate software engineering: using AI tools well inside a conventional engineering role.
Each one needs a different test and a different salary benchmark. Hiring a machine learning engineer to build product features, or an applied engineer to run training pipelines, is one of the most common mismatches we see.
What to test for
Shipped work. Ask the candidate to walk through something they put into production. What did it do, who used it, what broke, and what would they change? People with real experience go into detail on the failures.
Evaluation. Ask how they knew the model or feature was working. Strong answers mention test sets, error analysis, user feedback and the metrics that mattered to the business.
Data handling. Ask where the data came from, how it was cleaned, and what they did about gaps or bias. Most AI problems in production turn out to be data problems.
Cost and reliability. Ask what the feature cost to run and how they kept it within budget. Answers about inference costs, latency and fallback behaviour show who has run a system at scale.
Judgement. Ask about a time they recommended a simpler approach than AI. Candidates who can explain that decision usually understand the technology well.
Questions you can use
- Talk me through the last AI feature you shipped. What did you measure before release?
- Tell me about a time a model behaved differently in production than in testing. How did you find out?
- How would you estimate the running cost of this feature at ten times the current usage?
- What data would you need before starting this project, and what would you do if it wasn’t available?
Follow each answer with a second question that goes a level deeper. Candidates who did the work can keep going, while those repeating a summary run out of detail quickly.
A short exercise based on a real, anonymised problem from your own team will tell you more than a generic coding test.
Listen for who did the work
The same verification problem comes up in cybersecurity hiring, where paper certifications don’t always reflect capability. With AI, the risk is a strong vocabulary covering limited delivery. Ask for specifics every time. “We” is fine in an answer, but you need to know which part was theirs.
Find engineers who have delivered
Intec Select recruits AI, data and engineering talent across the UK, and we assess for delivered work before a CV reaches you. If you’re planning AI hires for 2027, tell us what you’re building and we’ll tell you what the market looks like for it.
