We're working on more permanent roles than we were a year ago. Fewer contracts, more full-time hires, and it's made a different hiring challenge much more visible.

A contract hire is a bounded piece of work. You need a specific thing built, you want somebody who has done it before, and if the match is imperfect the arrangement ends when the work does. A permanent hire fails differently. When a technically capable hire doesn't work out, the reason I hear most often is a mismatch between the role they accepted and the job they actually found themselves doing.

I hear both halves of this. Companies tell me why a hire didn't work out, and candidates tell me why they're leaving a job they started eleven months ago. The two accounts are usually the same thing described from opposite sides.

Which means the hard part of a permanent hire isn't assessment. Assessment is the part everyone budgets for. The hard part is accuracy: making sure the job somebody accepts is the job they turn up to.

The ways a role turns into something else

Some departures couldn't have been predicted: relocation, family circumstances, restructuring. But when somebody was capable of the work and left anyway, the mismatch usually happened in one of about four ways.

And it rarely involves anyone being dishonest. In most cases nobody misled anybody. The description was true when it was written, or true about the plan.

The new and interesting work turns out to be old and difficult. Somebody is hired to build new products and features, but much of the job turns out to be working around an aging codebase. Adding something new means understanding years of decisions nobody documented, changing one thing creates regressions somewhere else, and seemingly straightforward work takes far longer than it should. The new work is still happening, but the reality of building it is very different from the clean-slate development the candidate thought they were joining to do.

The technology doesn't materialise. An engineer joins partly because of a new product or technical direction they were expecting to work on. Six months later, priorities have changed, the new project has been pushed back and most of their work is still in the existing stack. The work may be perfectly good, but it's different from the opportunity they moved for.

Hired to change something, with no mandate to change it. A new hire is brought in to modernise a codebase, improve development practices or change the way a team works. Everyone agrees it needs doing, but product commitments and immediate problems keep taking priority, and nobody has created the time or the authority to make the change happen. Six months later, the thing they were hired to improve is still on the list for when there's time. The intention may have been genuine, but it never became part of the day-to-day job.

The person hiring you doesn't control everything about the job. A good hiring manager can be completely honest about their team and the role while decisions about the roadmap, budget or structure are being made somewhere else. Projects get cancelled and teams get reorganised for reasons they had no say in. And if that manager moves on, the person who understood what you were hired to do may have gone with them. Some of the things that made the role attractive were simply less certain than they appeared.

None of these are necessarily visible from the job spec. But asking about them directly gives a candidate a much clearer picture of the job before they accept it.

The questions I ask before we talk about candidates

The first conversation I have with a client is about the role itself.

Why is this role open? Replacing a leaver, backfilling a promotion and a newly created role are three different jobs behind the same spec. If somebody left, why they left is the most useful information available, and often enough it's one of the patterns above. If the role is new, nobody yet knows what good looks like, and the spec is a considered guess that will need revisiting.

What do you want this person to have achieved at three months, six and twelve? A spec lists responsibilities. This question describes the work. It's also, fairly often, the first time a hiring manager and their own manager discover they'd have answered it differently.

Who have you interviewed already, and what was missing? The gap between the written spec and the people a client has already turned down is where the real criteria are, and those are rarely written down anywhere. If four candidates matched the spec and none of them were right, the spec isn't describing the job.

Which parts of this job exist today, and which parts are the plan? Roadmaps move, teams change their minds, and the new project starts a quarter later than anyone intended. That's normal, and no candidate worth hiring expects otherwise. The problem is a candidate accepting the plan while believing it's the present. Separating the two out loud, before anyone writes an offer, costs nothing.

What I need to know about the team

A role doesn't exist on its own.

Who is in the team and at what level changes the job. A senior engineer joining a team of juniors may find that mentoring becomes a significant part of the role, whether or not it appears anywhere in the spec. A mid-level engineer joining a very senior team may be expecting support and development that the team hasn't actually made time to provide.

Where people are matters too, as does how often they actually meet. One time zone or three. In a room, or asynchronously in a channel.

And the one that gets forgotten: is there anyone already in the team who would want this role? If the answer is yes and you hire externally anyway, you have two things to manage rather than one. A new person arriving into a situation they know nothing about, and an existing person deciding what to do next. That's a far better problem to have before the hire than after it.

How a team works matters as much as who's in it. Two clients can send me near-identical specs and actually need very different people, because the work may be organised very differently in each team.

Does this engineer write the spec, or receive one? Do they own a subsystem end to end, or integrate across three teams and a hardware group? Can they make technical decisions themselves, or do they need consensus from the wider team? Who decides what they work on when priorities conflict?

Those are answerable facts about a job. "Good team player" tells you almost nothing about how collaboration actually works when a decision needs to be made.

This isn't an argument for culture fit

Culture fit often becomes shorthand for whether somebody feels like the people already there, which tends to reward similarity rather than capability. A better question is whether the way somebody works matches the conditions the role actually provides. Those conditions can be defined before you meet anyone and discussed consistently with every candidate.

If you're making a permanent hire and you take one thing from this: is the job you're describing the job they'll actually turn up to?

At The Audio Programmer we work across permanent and contract recruitment in audio and music technology, and a lot of the process is spent on exactly that question.

‍