By Scott David, Founder at Tides Digital

One of the things that has become increasingly obvious to me over the last couple of years is that the way companies describe technical roles hasn't really kept pace with the technology. We are still using a lot of familiar job titles, but the work sitting underneath them has changed considerably. That creates a problem for hiring teams because the person they actually need can look very different from the person their job description appears to be asking for.

AI is probably the clearest example of this. A company might advertise for an AI Engineer and expect experience across software engineering, LLMs, data, cloud infrastructure, agents and product development. Another company can use exactly the same title but really be looking for someone with a much deeper machine learning background. Both searches are labelled AI Engineer, but the two people could have almost nothing in common beyond a few keywords on their CV.

Recent research from Andela illustrates how widespread this has become. Its analysis of more than 47,000 technical job postings found that 53% of roles carrying titles such as AI Engineer or ML Engineer required skills spanning at least two established job families. It also identified thousands of postings where the combination of skills effectively described an emerging role that didn't have a recognised title yet.

That feels very familiar from the conversations we are having with clients. More and more, companies are coming to us with a fairly broad idea of what they want, but when we start talking about the actual problem they are trying to solve, the profile becomes much more specific.

They might tell us they need an AI Engineer, for example, and what they really need is a strong backend engineer who has spent the last two years building production applications around foundation models. In another situation, the requirement might be someone who understands model deployment and inference infrastructure rather than someone who has worked on the models themselves. We are also seeing more businesses looking for engineers who can work directly with customers and take an AI product from a prototype into a real-world implementation.

Those are very different people, and I think the companies that recognise that early have a much easier time hiring.

The temptation when a technology is moving quickly is to make the job description longer. You see this quite a lot in AI at the moment. Python, PyTorch, LangChain, RAG, vector databases, AWS, Kubernetes, LLMs, agents, MLOps and a long list of other technologies can all end up appearing in the same specification. It can look thorough, but in reality it often makes the search less precise because it doesn't tell the candidate which of those things actually matter.

When we start a search with a client, I'd much rather spend time understanding what the person is going to own. What are they expected to build? What already exists? Where are the technical problems? How much of the role is product development and how much is infrastructure? Are they going to be working independently or as part of a larger engineering organisation? Will they need to speak to customers? What does success look like after six months?

Once you understand those things, the technology becomes much easier to define.

It also opens up the candidate market considerably.

Some of the strongest AI candidates we are seeing don't necessarily come from traditional AI backgrounds. There are software engineers who have moved heavily into LLM applications because their companies needed them to solve a particular problem. There are data engineers who have moved into AI infrastructure. There are platform engineers who now spend a significant amount of their time thinking about inference, model deployment and observability. There are product engineers who have become very good at building AI features because they have been close to the product and the customer throughout the process.

If you search only for people who have already held an AI Engineer title, you can miss a significant amount of that talent.

The other thing I think companies need to be careful about is hiring around today's technology rather than the underlying capability. AI changes quickly enough that a framework or model which feels essential when a role is written can look considerably less important by the time someone joins. That doesn't mean technical experience isn't important. It means we need to distinguish between experience with a particular tool and the ability to understand and work with the underlying problem.

The latter tends to travel much better.

A good engineer who understands how to build reliable software, work with data, evaluate an AI system and make sensible architectural decisions will adapt as the technology changes. Someone who happens to have used the exact framework listed in a job description may have a head start, but that doesn't necessarily tell you how they will perform when the requirements change.

This is becoming particularly important because AI is pushing engineers into areas of the business where they might not traditionally have been involved. We are seeing technical people working much closer to product, operations, sales and customers because the value of an AI system often depends on how well it fits into the wider business rather than how impressive the underlying technology is.

That changes the profile of the person you need.

Technical depth still matters enormously, but so does the ability to understand context. The strongest people I've met tend to be curious about the business problem as well as the technical one. They want to understand why something is being built, who is going to use it and what happens when it gets into production. They can go deep technically without losing sight of what the company is actually trying to achieve.

Those people can be difficult to find because they don't always fit neatly into a category.

That is probably the biggest lesson for hiring managers. If you make the profile too rigid, you can end up excluding exactly the kind of person who could make a significant difference to the team. A candidate doesn't necessarily need to have followed the same career path as the person who previously held the role, particularly in a market where the roles themselves are changing so quickly.

I think this is where specialist recruitment has an increasingly important role to play. The value isn't in finding a CV with the right collection of keywords. It is in understanding what someone has actually been doing, how deep their experience is and whether that experience makes sense for the particular environment you are hiring into.

That requires being able to have a proper technical conversation with the candidate and then translate that back to the hiring team.

It also means being willing to challenge the brief when the market tells you that the brief isn't quite right.

Sometimes the person you need isn't an AI Engineer at all.

They might be a software engineer who has built AI products. They might be a platform engineer who understands inference at scale. They might be a data engineer who has moved into machine learning infrastructure. They might be someone with a completely different title who has spent the last few years solving exactly the kind of problems your business is now trying to solve.

The technology has moved quickly enough that the job titles are struggling to keep up.

I'd expect that to continue for some time. New roles will appear, existing roles will overlap and companies will keep finding that the skills they need don't necessarily sit neatly inside the categories they have always used.

For me, that makes the quality of the hiring conversation more important than ever.

The best AI candidates aren't always the ones who look perfect on paper. They are often the people whose experience makes more sense the longer you talk to them.

The job description is where the search starts. It shouldn't be where the thinking stops.