The roles we know well.

The largest part of what we do. The distinctions that matter here are rarely the languages: whether the system is event-driven or request-response, whether the person owns architecture or implements a design, whether they have worked on systems that already had users and history, and whether they have carried anything through to production and supported it afterwards.

Roles where the difficulty is usually in the data and the problem definition rather than the modelling. We look for people who can tell you when a problem is not worth solving with machine learning, who understand how a model behaves once real users reach it, and who can work with the engineers who have to operate it.

Platform, reliability and operations work. The useful question is whether someone has run what they built: cost, failure modes, on-call, capacity and the difference between a system that deploys and a system that stays up. Design experience and operational experience are not the same thing, and the roles usually need one or the other clearly.

Application, infrastructure and governance roles. We look for judgement about risk rather than a list of tools — people who can prioritize what actually matters for a business of a given size, and who can work with engineering teams instead of around them.

Engineering management, architecture leadership and senior technical roles. Here the assessment is mostly about decisions: how someone has handled a failing project, how they have grown people, how they say no, and whether the teams they led would work with them again.