How we work

A deliberately unremarkable process. The value is in the assessment, not in the workflow around it.

This is the whole process. It is deliberately unremarkable, because the value is in the assessment rather than in the workflow around it.

You describe the work, not the stack

The most useful brief describes the system, what it does, what is already decided and what the new person would own. A list of ten technologies with no context filters for keyword matches, and keyword matches are exactly who gets rejected in the technical round. If you are unsure what the role is, that is a normal place to start and we would rather work it out with you than guess.

We tell you what we think before we start

If we think the role is really two roles, that the level is wrong for the work, or that you would be better served hiring locally, we say so at this point. This is the cheapest moment for that conversation and it is the one most agencies skip because it can end the engagement.

We source against the brief

We look for people who have solved your shape of problem, which is not the same as people whose CV lists your technologies. A developer who has run the kind of system you are building in a different stack is frequently a better hire than one who has used your exact stack on something trivial.

We assess properly

Working code and a conversation about decisions. We look at what someone has built, ask what they would now do differently and why, and probe the areas where their technology most reliably separates people. Each technology page on this site publishes what we test and why, so you can hold us to it.

You get a short list and our reasoning

Two or three people, with what we think each is strong at, where we have reservations, and why we ruled others out. The reservations are the part that matters. A shortlist with no stated weaknesses has not been assessed, it has been assembled.

Your team interviews

You make the decision. We will tell you what we would ask and what we think the risks are, and we will not push a candidate you are unsure about. A developer somebody was talked into hiring rarely works out.

We stay involved through the first month

The first weeks decide most of what follows, and most of what goes wrong is on the client side: no environment, no reviewer, no access. We check in, and if something is not working we would rather hear it in week two.

Why technical hiring goes wrong

Most of the expensive mistakes in technical hiring are made before anybody is interviewed, and they are the same mistakes each time. They are worth naming because each one is avoidable at no cost.

The brief describes a stack rather than a system

A specification listing ten technologies and no description of what the system does filters for keyword matches. Keyword matches are exactly the candidates who get rejected in the technical round, which means the brief has selected for the people who will waste your engineers' time.

The band comes from the wrong market

A remote role competes with the markets that pay most, whether or not you are located in one. Teams that set a remote band from their own local figures have answered a different question and then conclude that nobody good is available.

The process outlasts the candidate's patience

In a concentrated market anybody worth hiring is in several conversations. Five interview stages optimise against the risk of a bad hire while creating the near-certainty of losing good ones. Adding a stage midway loses precisely the candidates the stage was meant to be careful about.

The filtering is pushed onto engineers

If your engineers are interviewing ten people per role, the most expensive people in the process are doing the cheapest part of it. Two or three properly assessed candidates is the goal; ten screened ones is a failure of the stage before.

Nobody owns the decision

Processes without a named decision-maker drift, because everybody defers and nobody declines. Candidates read this accurately as a signal about what working there would be like, and the strongest ones withdraw first.

The vacancy is not counted

Every month a role is open, the work it was meant to do is not happening. That cost is identical whichever way the seat is eventually filled, and in a specialist search it routinely exceeds the difference between the options being compared.

The setup is blamed on the hire

No running environment, no reviewer with capacity, no access to the real system. The difference between a first merged change in week one and week four is almost entirely on the employer's side, and it gets attributed to the developer far more often than to the conditions that produced it.

What we need from you

Almost everything that makes an engagement go badly is on the client side, and almost all of it is fixable before anyone starts.

• A running environment on day one, not documentation describing how to build one.
• A named reviewer with genuine capacity, because a developer waiting two days for review does a fraction of the work.
• Access to the real system rather than a mock, since work built against a simplification has to be rebuilt.
• A first task that is small and real, which proves the environment, the review path and the deployment path all work.
• A decision about who owns design, if the work touches an interface.
• An agreed overlap window, published and treated as real.

None of this is specific to working with us; it is what any developer joining any team needs. It is written down because these failures get attributed to the developer far more often than to the setup that produced them.

Frequently asked questions

How long does it take to get a shortlist?

It depends on how specific the requirement is and how deep the pool for it is. A common request against a clear brief moves quickly; an unusual combination takes longer. We would rather tell you a realistic timeline than a comfortable one, and if we think the search will be slow we will say so before you commit.

What if we do not know exactly what we need?

That is normal and it is a better starting point than a confident brief that is wrong. Describe the system and the problem. Working out what the role actually is tends to be the most valuable part of the first conversation.

Do you replace someone who does not work out?

The commercial terms are agreed before an engagement starts and are set out in the agreement rather than on this page. What we will say here is that if a placement is not working we want to know in week two rather than month three, and the response starts with working out whether the problem is the person or the setup.

Can we talk to the developer before deciding?

Yes, and you should. We shortlist; you decide. We will never ask you to take someone on our assessment alone.

Do you work on a retainer or per placement?

Both arrangements exist and the right one depends on whether this is a single hire or ongoing capacity. We will propose what fits rather than what suits us, and the terms are agreed in writing before anything starts.

What happens if you cannot find anyone?

We tell you, and we tell you why. Usually it means the brief is asking for a combination that barely exists, or the band is below what the market requires. Both are fixable and neither is fixed by continuing to search.