By Connor, Principal AI Recruiter at Tides

One of the hardest parts of recruiting in AI at the moment is that the CV has become a lot less useful than it used to be.

That probably sounds like an odd thing for a recruiter to say, but it's something I've been thinking about quite a lot over the last year. The number of people who can put Python, LLMs, RAG, agents, LangChain or a long list of AI tools on their CV has grown incredibly quickly. So has the number of companies asking for those things.

The problem is that the list doesn't tell you very much about what someone can actually do.

I've spoken to candidates who have genuinely built impressive AI products and can talk for an hour about the decisions they made along the way. I've also spoken to people with a very impressive-looking AI CV who, when you get into the detail, have mainly been using existing APIs and following fairly standard implementation patterns.

Both can look almost identical on paper.

That is making AI recruitment much more interesting, but considerably harder as well.

The technology has moved so quickly that the way we assess people has had to move with it.

A couple of years ago, someone who had worked with machine learning in production was relatively easy to identify. Their experience tended to be fairly specific and there was a reasonable relationship between their job title, their technical background and the work they had actually done.

That relationship has disappeared to a degree.

A software engineer might now be building agentic systems every day. A product engineer might have taken an LLM feature from an idea through to production. A data engineer might have moved into retrieval and evaluation. Someone with a traditional machine learning background might now be spending most of their time working on inference infrastructure.

None of those people necessarily have "AI Engineer" as their current job title.

And I think some companies are missing good candidates because they're still searching for the title rather than the experience.

The numbers around AI coding are a good example of how quickly this is happening. JetBrains' latest developer survey, based on more than 15,000 professional developers, found that 90% are now using AI coding agents at work at least weekly, while 68% use them every day. Their research also found that developers reported agents fully writing around 47% of their code on average.

That changes the meaning of experience.

If a huge proportion of software engineers are now working with AI every week, simply having used an AI tool isn't much of a differentiator anymore.

What matters is what they did with it.

I've become much more interested in the story behind someone's work than the technology list on their CV. If someone tells me they built an AI application, I want to understand what the original problem was, what they decided to build, what they tried first and where it went wrong. I'm interested in whether they had to think about latency, evaluation, cost, reliability or data quality. I'm interested in what happened when the first version didn't work.

Those conversations tend to tell you very quickly how deep someone's experience really is.

The strongest candidates usually don't give you perfectly polished answers either. In fact, it's often the opposite. They remember the decisions they got wrong. They can tell you about a model that wasn't good enough, a retrieval system that produced rubbish results, an evaluation process that had to be completely reworked or a clever technical solution that turned out to be completely impractical once real users got hold of it.

That kind of experience is difficult to manufacture.

It's also becoming increasingly important because AI engineering is moving into a phase where simply getting something to work is no longer enough.

Companies are starting to care about what happens after the demo. Can it run reliably? Can it be monitored? Can the cost be controlled? Can another engineer understand it six months later? Does it actually improve the product? Can you measure whether it's working?

This is where I think the best AI engineers are beginning to separate themselves.

They aren't necessarily the people who know the most tools. They're the people who have developed good engineering judgement around AI.

That's also why I think some of the most interesting candidates I've met recently don't have particularly conventional AI backgrounds.

I've spoken to software engineers who have taught themselves an enormous amount about LLMs because they had a problem they wanted to solve. I've met data engineers who have moved naturally into AI because they were already working with the data infrastructure underneath it. I've spoken to product engineers who have become extremely strong at taking AI features from an idea to something customers can actually use.

Their CVs can sometimes look less impressive than someone who has worked under an "AI Engineer" title for years.

The conversation can tell you something completely different.

There is another side to this for hiring managers, and it's something I think companies are going to have to get much better at.

The requirements for AI roles are changing so quickly that writing a job description around a particular stack can date surprisingly fast. A company might think it needs someone with experience in one framework or one model ecosystem, only to find six months later that the technology has moved on.

I'd much rather see companies describe the problem they need someone to solve and the environment they'll be working in. The technical requirements still matter, obviously, but understanding whether you're looking for someone to build models, build products around models, create agentic systems, work on infrastructure or take AI into customer environments makes a much bigger difference to the search.

This is where I think specialist recruitment has a real role to play.

A good AI recruiter should be able to have a technical conversation with the candidate, understand what they've actually built and then translate that back to the hiring team. Otherwise, you end up with a CV matching exercise, and AI is already making that approach less useful.

For me, the most valuable part of the job is still the conversation.

You can learn a huge amount from what someone has built, but you learn even more from how they talk about it. The decisions they made, the things they got wrong, what they would change and how they think about the next problem.

AI is making it easier for more people to build things. That's a great development for the industry, but it also means that the signal we use to identify exceptional people has to get better.

The best candidates aren't always going to have the most fashionable title or the longest list of AI tools on their CV.

More and more, I'm looking for people who have actually been in the arena. People who have built something, broken something, figured out why it broke and made it work properly the next time.

That's the experience I think is going to matter most as AI moves from experimentation into the core of how companies build products.