Talent — Technology Recruitment
We understand the work behind the job description.
A job description is a summary written by someone with a hundred other things to do. The work behind it is more specific — and that is where a search is won or lost.
We recruit into technology roles across software engineering, data, cloud, security and technical leadership. Before we approach anyone, we make sure we understand the system they would be working on, the decisions they would own, and the environment they would be joining.
Back to TalentReading the role
We start with the work, not the wish list.
Most postings describe an ideal person who does not exist. The first job is to separate the requirements that matter from the ones that describe a preference.
A posting is usually assembled from several sources: the manager's wish list, the shape of the last person who held the role, the tools the team happens to use today, and a set of requirements written to protect a decision that was already made. Reading it properly means asking which lines describe real, everyday work and which are preferences that can move.
That reading is what changes the search. It tells us what to look for in a career history rather than in a skills list, which questions are worth asking in a first conversation, and which people are worth speaking to even when their CV does not match the posting word for word.
Is this event-driven, or is it CRUD?
Two systems can name the same framework and still be different work. An event-driven service needs someone who thinks about ordering, delivery, retries, idempotency and what happens when a downstream system is unavailable. A transactional application needs honest data modelling, clear boundaries and the discipline to keep a domain simple as it grows. The technology list looks almost identical. The daily work does not.
When “senior” means ownership, not years
In some organizations senior is a pay band with a few extra years attached. In others it means the person is accountable for architecture, trusted to decide what not to build, and expected to raise the standard of everyone around them. Those are different hires at different points in a career. We ask what the person will own in their first six months, and we look for evidence of that ownership rather than a number.
Operational experience is not build experience
Building a system and running it are separate skills. Someone who designed a platform from the first line may never have been called at two in the morning when it misbehaved. Someone who has carried a pager for years may be exactly who you need to make a fragile platform dependable. Which one you need depends on the state of your systems, not on how senior the title sounds.
Domain context changes the search
Domain knowledge matters most where the rules are unusual: regulated data, money movement, physical operations, clinical or industrial constraints. In those environments a capable engineer without the domain takes months to become useful, and a capable engineer with it is effective in weeks. We establish how much of the domain can genuinely be learned on the job before deciding how narrowly to search.
An example
The same line, four different jobs
A posting asks for an engineer with Java, Spring Boot, PostgreSQL and AWS. Nothing in that sentence says whether the service is event-driven or transactional, whether the person owns the schema or inherits it, whether the AWS experience means designing accounts, networks and permissions or simply deploying into an environment someone else built, or what the organization means by senior. Those are the questions we settle before we search — and the answers decide who is worth approaching.
Specializations
The areas we recruit into
Five areas where we can hold the technical conversation with both the hiring manager and the engineer.
Software Engineering
Backend • Frontend • Full Stack • Mobile • Architecture
AI & Data
Cloud & Infrastructure
Security
Technology Leadership
Fit
A team is a set of gaps as much as a set of skills.
A strong engineer in the wrong shape of team is a bad hire. So we look at the whole picture: what the team already does well, where the work currently stalls, who the new person will sit beside every day, and what kind of support they will need in their first months.
That is why the same CV can be a strong fit for one organization and a poor one for another. The capability is only half of the answer; the context is the other half.
How we assess people, for candidatesOur approach
How a search runs
Five steps, in this order, whether the role is straightforward or difficult to fill.
Understand
We learn the work behind the role before we search for anyone.
Search
We look where the right people actually are, not only where they are advertised.
Evaluate
We assess technical capability and context, not just a keyword match.
Introduce
We introduce people worth meeting, with the reasoning behind the introduction.
Support
We stay involved through offer, start date and the early months.
Talent
Where to go next
For Employers
How a search is scoped, how candidates are assessed, and what happens when a role is genuinely hard to fill.
For Candidates
What we look at beyond a CV, and the conversations that happen before your details go anywhere.
Specializations
The five areas we recruit into, and what the work in each one actually involves.
Talent overview
The wider picture: permanent, contract and specialist search, and how we work with both sides.
We don't just recruit into technology. We understand it.
Tell us about the role, the team and what the work actually involves. We will tell you honestly whether we can help.