A practical guide to hiring developers

What we would tell a team hiring engineers, whether or not they work with us.

This is what we would tell a team hiring engineers, whether or not they work with us. It is written down because most of the expensive mistakes in technical hiring are made before anyone is interviewed, and they are the same mistakes each time.

Set the band from the right data

The US median annual wage for software developers is $135,980, with the middle half of the market between $105,210 and $171,980 and the 90th percentile at $214,670. Those national figures are the wrong input for almost any specific decision, because the spread between US metro areas is about a factor of two. Use the published band for the metro you are hiring into, and if the role is remote, use the band for the market you are competing with rather than the one you are in.

An offer below the local 25th percentile does not produce a hard negotiation. It produces silence, because strong candidates read an under-market offer as information about the company and stop replying. That is the most common way a search fails quietly.

How much US markets differ

Ranked by median annual wage for software developers, the gap between the highest and lowest of these 28 metro areas is a factor of about 1.7. San Jose sits at the top with a median of $213,110 and Pittsburgh at the bottom with $124,500. A budget built from the national median of $135,980 will be wrong in both, in opposite directions.

Location quotient compares how concentrated the occupation is locally against the national average. Above 1 means more of this work than the size of the local economy would predict.

The location quotient column is the more useful one for planning a search. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin, Dallas-Fort Worth, Raleigh each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the local economy's size would predict. Those are markets where sourcing is quick and closing is the hard part, because good candidates are already employed and will be countered.

At the other end, Los Angeles, Chicago, Miami, Orlando, Houston, Pittsburgh have quotients below 0.9, meaning the occupation is less concentrated there than nationally. In those markets the constraint is supply rather than competition: fewer people to find, and offers that close more easily once you find them. Widening the geography early is usually cheaper than extending the timeline later.

Write the brief around the system

A specification listing ten technologies and no description of the system filters for keyword matches. Keyword matches are precisely the candidates who get rejected in the technical round, which means the brief has selected for the people who will waste your engineers' time. Describe what the system does, what is already decided, what the new person would own, and what the first three months would involve.

Interview for judgement, not recall

The questions that discriminate are not technology-specific. What did you remove. What decision do you regret and what constraint produced it. What did you decide against. How would you approach a codebase with no tests and no original authors. Those four questions separate candidates more reliably than any puzzle, and they are hard to prepare for because the answers have to be real.

Move at the speed of the market

In a concentrated market, anyone worth hiring is in several conversations. A two-week gap between final interview and offer is not diligence; it is a withdrawal. Decide the panel, the decision-maker and the offer range before the first interview rather than after the third. Adding a stage midway through a process loses exactly the candidates the stage was meant to be careful about.

Count the vacancy, not just the salary

Every month a role is open, the work it was meant to do is not happening. That cost is identical whichever way you eventually fill the seat, and in a specialist search it routinely exceeds the difference between the options being compared. Any comparison between hiring locally and building the team another way that leaves out time to fill has already reached the wrong answer.

Fix your side before you blame the hire

The difference between a first merged change in week one and in week four is almost entirely on the employer's side: whether an environment runs, whether a reviewer has capacity, whether access exists. These failures get attributed to the developer far more often than to the setup that produced them, and they are all fixable before anyone starts.

The US technical labour market in numbers

Software development is one of fourteen technical occupations the Bureau of Labor Statistics publishes separately. Together they account for about 4,860,150 people, of whom 1,687,890 are software developers, which is why that one occupation dominates most conversations about technical hiring. The other thirteen matter because they compete for the same people.

Source: BLS Occupational Employment and Wage Statistics, May 2025 national file, read 25 September 2026. Figures cover all US employers.

The spread across these titles runs from $175,140 for computer and information systems managers down to $92,650 for web developers. That gap is the practical reason technical people move sideways between titles rather than upward within one: for many engineers the fastest available pay rise is a change of job title rather than a change of employer. If you are hiring at the lower end of that range, expect to lose some candidates to the upper end of it, and expect that to happen after they have accepted.

It is worth reading the employment column alongside the wage column. Occupations with small headcounts, such as database administrators and architects, are specialisms where a local search will frequently produce nobody, regardless of what you are prepared to pay. Occupations with large headcounts are where a well-run process matters more than a generous band, because the people exist and the competition is for their attention.

What the levels actually mean

Job titles are not comparable between companies, so it is more useful to describe levels by what somebody can be left to own without supervision. These are the boundaries we use, and every technology page states what each level looks like in that specific technology.

Junior

Delivers defined pieces of work inside an existing structure, with the approach decided for them. Reviews catch the things experience teaches. Valuable where there is strong direction and capacity to teach, and a poor investment where there is neither.

Mid-level

Owns a feature end to end, including its tests, its failure states and its data access. Can be given a problem rather than a solution. Still benefits from review on decisions that will be expensive to reverse.

Senior

Owns the shape of an area. Makes the decisions that are costly to change later and can justify them against the alternatives. Raises the level of the people reviewing alongside them, which is the part most often left out of the definition.

Staff

Owns cross-cutting concerns: the contracts between areas, the standards others build against, the migration path off whatever the system has outgrown. Measured by what other teams stop having to decide.

Years of experience correlate with these far less than people expect. Somebody who has spent six years maintaining one application carries less transferable judgement than somebody who has spent three across three very different ones. When a CV and a level disagree, the interview should settle it.

The most reliable seniority signal we know is what somebody has removed. Mid-level developers describe what they added. Senior ones describe a store they deleted, an abstraction they collapsed, a dependency they took out. The ability to make a system smaller is harder to fake than any amount of technical vocabulary.

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.

Know when the answer is not a hire

Adding developers to a team that cannot review what it already produces makes the queue longer. Adding capacity to avoid confronting an architectural problem produces more of what is already difficult. If delivery is slow and nobody can say why, that is a diagnosis job rather than a recruitment one, and a month of senior attention frequently beats a quarter of hiring.

Frequently asked questions

How do we set a salary band for a remote role?

Against the market you are competing with rather than the one you are in. If the role is open to anyone in the country, you are competing with the concentrated high-paying metros whether or not you are located in one. Teams that set a remote band from their own local market and then wonder why nobody accepts have answered a different question.

How long should a technical interview process take?

Days rather than weeks, from first conversation to decision. Two substantive conversations plus a decision is usually enough. Processes with five stages are optimising for the risk of a bad hire while creating the near-certainty of losing good ones.

Should we use take-home exercises?

Short ones, paid, if at all. Long unpaid exercises filter for people with free evenings, which selects on circumstances rather than ability and quietly excludes people with caring responsibilities. A short session on real code gives more signal per hour anyway.

How many candidates should we interview?

Two or three properly assessed, not twelve screened. If your engineers are interviewing ten people, the filtering has been pushed onto the people least able to spare the time, which is the most expensive place to put it.

What is the most common reason a good candidate declines?

In our experience, the process itself. Slow decisions, unclear ownership of the role, and an interview that suggested nobody had thought about what the person would actually do. Compensation is the stated reason far more often than it is the real one.

Should we hire senior or mid-level?

Depends on whether anyone can set direction. A team with no senior engineer that hires two mid-level developers produces more code and no more clarity. A team with strong direction and no capacity is the right place for mid-level hires, and they will grow faster there than anywhere.

How do we tell a senior developer from a mid-level one?

Ask what they removed. Mid-level developers describe what they added; senior ones describe a store they deleted, an abstraction they collapsed, a dependency they took out. Years of experience correlate with this far less than people expect.

Is it cheaper to hire locally or work with a partner?

It depends entirely on the market, the specialism and how long the search would take, and we will tell you when we think local is the better answer. The comparison that is nearly always wrong is a local salary against an hourly rate, because it omits employer taxes, benefits, recruitment cost and the months the seat stands empty.