Why a careful spec can shrink a candidate pool that was never as small as it looked
Most founders write an engineering job spec the same way. You start from the work that needs doing, add the things your current team is stretched on, and then, because a wrong hire in a small team is genuinely expensive, you tighten it. Every line feels reasonable on its own.
The problem is that a spec is not a description. It is a filter. And in a niche stack, a filter tuned for certainty will often return a market far smaller than the one that actually exists.
I spend most of my week talking to Elixir and Erlang engineers. Over the last five weeks, every engineering conversation I have had has been with someone on the BEAM. Three of those conversations, taken together, say something I think is worth passing on.
The engineer who took a pay cut to change one word
She has eight years of Erlang. Distributed systems, dozens of microservices, hundreds of millions of transactions a day. On one project she rebuilt how test databases were templated and took the CI run from thirty minutes to seventeen.
She was made redundant in April.
She started her search looking for Erlang roles and gave up, because the market for them was too narrow to sustain a search. So she is moving to Elixir instead. She has been working through tutorials, joining the community, building side projects, and she is going to Code BEAM in October as a volunteer.
She is willing to take a pay cut to secure an Elixir role. She volunteered that, and she volunteered the reason: she expects less because she has no commercial Elixir experience.
Zero years of the language. Eight years of the virtual machine it runs on, the actor model it is built around, and the operational reality of running it at scale.
A spec that says “5+ years commercial Elixir” screens her out before a human reads the CV.
Must have, or already done it here
The second conversation was with a senior engineer who had a two hour interview with a company and came away genuinely enthusiastic. His feedback to me was that the conversation with the team was great and he really enjoyed it.
The rejection came back a week later. They were looking for deeper BEAM knowledge.
This is the part I have real sympathy for. When a team has been on one stack for years, the things it knows stop being visible. The way you structure supervision trees, the conventions around your umbrella apps, the reason you do a thing the unusual way you do it. None of that is written down. It just is.
Put that team in an interview and those unwritten things surface as gaps in the candidate. It feels like a depth problem. Most of the time it is a context problem, and context is what onboarding is for.
The test is simple. When you write rejection feedback, name the specific thing the person did not know. Then say honestly how long it would take them to learn it inside your codebase.
If the honest answer is two weeks, you did not find a depth issue. You found a first sprint.
What ramp actually costs
The instinct behind a tight spec is a real cost, and it deserves to be taken seriously rather than waved away.
One founder I spoke to had exactly this experience. Previous hires had slowed the team down because they needed substantial Elixir training, and their lead engineer had become resistant to hiring at all as a result. That is not fussiness. That is a team that got burned and adjusted.
But the sum has two sides, and only one of them usually gets counted.
The cost of ramp is visible. It is six to eight weeks of reduced output and a chunk of your senior engineer’s attention. You can feel it.
The cost of waiting is invisible. It is four extra months of an unfilled seat, four months of the work not happening, and four months of your existing engineers absorbing it. It does not show up anywhere, so it rarely gets weighed against the first number.
When you do put them side by side, an adjacent hire who takes six weeks to get productive almost always wins against a perfect-match hire who takes four months to find. That is before you account for what an engineer who is genuinely stretching into a new language brings in energy and retention.
How to write the spec so the market can answer it
Four changes, none of them expensive.
Split your requirements honestly. Two lists. Things someone must arrive with, and things they must be able to learn quickly. Most specs have three or four items in the first list and pretend it is nine. Be strict about what genuinely cannot be taught in your environment.
Specify the foundation, not the label. In a BEAM shop, the thing that takes years is distributed systems thinking, fault tolerance and operational instinct. Elixir syntax is not the hard part. Write the spec around the part that is hard.
Name your ramp tolerance out loud. Decide, before you post, how many weeks you can genuinely absorb. Then say it internally, so your interviewers are calibrated against that number rather than against their own fluency.
Ask what the candidate has already crossed. Someone who has moved between languages before, deliberately, has proven the exact skill you are worried about. That is evidence, and it is better evidence than five years on a CV.
What this looked like in practice
Two Elixir Developers I placed with a client started this month. One came from a background of short stints and repeated layoffs and wanted somewhere stable. One wanted a small team and real autonomy and was direct about it in the first conversation.
Neither of them was a line by line match to the original brief. Both are exactly right for the team.
The search worked because the founder was clear about which two things were genuinely non negotiable and honest about the rest. That decision is what turned a shortlist of two into a shortlist worth interviewing.
If your engineering job spec isn’t producing a hire, it is worth reading it as a filter rather than a description, and asking which line is doing the most damage.
If you want a second pair of eyes on a role before it goes out, that is a conversation I am always happy to have.
Arjun Gillard
Founder, AG Talent
agtalent.co.uk
