Let’s start with the version of this problem you have probably been told. You cannot find good engineers because there is a global talent shortage. The candidates who apply do not have the right skills. Your budget is not competitive enough for senior people. Remote work means you are competing with Silicon Valley salaries. The […]
Let’s start with the version of this problem you have probably been told. You cannot find good engineers because there is a global talent shortage. The candidates who apply do not have the right skills. Your budget is not competitive enough for senior people. Remote work means you are competing with Silicon Valley salaries. The problem, in other words, is external. It is happening to you.
Here is the version that is harder to hear: most companies struggling with hiring technical talent are struggling because of how they run their process, not because of what is happening in the market. The shortage is real. But it affects every company equally. What is not equal is how companies respond to it — and the response gap is where most of the problem lives.
This article is about the myths that keep companies stuck. The stories organisations tell themselves about why hiring technical talent is so difficult, and what the evidence actually shows when you look more carefully. Some of these myths are comforting because they externalise blame. Others are habits so embedded in standard HR practice that no one thinks to question them. All of them are costing you engineers you should have hired.
The global shortage of experienced software engineers is real. Demand consistently outpaces supply in most technical disciplines, and that gap is expected to widen. But a talent shortage does not explain why companies post the same role four times in twelve months, or why two companies in the same city with similar products and similar budgets can have completely different hiring outcomes.
The shortage affects the size of the pool. Process determines how much of that pool you actually access. A company with a slow, unclear, or unpleasant hiring process will consistently see strong candidates drop out early, accept other offers, or decline to engage at all. The shortage means your margin for process error is smaller. It does not mean the outcome is fixed.
Companies that consistently succeed at hiring technical talent acknowledge the shortage and then immediately focus on things within their control: how fast they move, how clearly they communicate, how well they treat candidates throughout the process, and how compelling their offer actually is. They do not wait for the market to change. They change their approach.
There is a deeply embedded belief in many organisations that more stages equals more thoroughness. More interviewers mean more perspectives. More time between stages means more deliberation. This belief is wrong, and it is costing companies some of their best technical candidates.
Research on hiring decisions consistently shows that most information predictive of a hire’s success is gathered in the first two or three touchpoints. Additional stages add noise rather than signal. They also add time — and in technical hiring, time is one of the most expensive variables in the process.
The strongest candidates when hiring technical talent typically receive multiple approaches and move quickly once they decide to explore options. A six-week hiring process is not thoroughness. It is a message to candidates that your organisation moves slowly and values its own administrative comfort over respect for their time. Candidates draw conclusions from this. Accurate ones.
Streamlining is not the same as rushing. You can move in two weeks and assess rigorously. The question is whether each stage genuinely adds new information or exists because it has always existed.
When hiring technical talent produces low-quality applications, the instinct is to rewrite the job description — add more detail, clarify requirements, list technologies more specifically. This is not wrong, but it is incomplete in a way that matters.
Job descriptions attract candidates who are actively searching. Active candidates represent a minority of the best technical talent at any given time. Most strong senior engineers are employed, not browsing job boards, and will not see your post no matter how well-written it is. Improving your job description improves your inbound channel. It does nothing for the outbound channel, which is where many of your strongest hires will come from.
Companies that consistently do well at hiring technical talent treat sourcing as an active function. They identify specific target profiles, reach out thoughtfully, and build relationships with candidates who are not looking right now but might be open to the right conversation. A better job description is a good thing. It is just not a hiring strategy on its own.
Technical assessments have a legitimate purpose. You need to know whether someone can do the work. The question is not whether to assess technical skill but how to do it in a way that gives you useful signal without deterring the people you most want to hire.
The standard take-home test — four to eight hours of work, sent after a screening call, due within forty-eight hours — has a well-documented drop-off problem among senior engineers. People with experience and other options frequently decline to complete it. Not because they cannot do the work. Because spending eight unpaid hours on a test for a company they have spoken to once is not a reasonable investment when they have two other processes running simultaneously.
The engineers who complete every test regardless of length tend to be those with fewer options or less clarity about their own market value. This means long technical tests function as an inadvertent filter that removes some of your strongest candidates from the pool. A sixty-minute practical scenario that reflects real work in your environment is more predictive and less deterring. That is the trade worth making.
Every hiring manager has made a hire based on someone feeling right in an interview and later regretted it. Every hiring manager has also passed on someone who seemed slightly awkward and later found out they went on to do exceptional work elsewhere. The intuitive assessment of culture fit is real. It is also unreliable in ways that compound over time.
What actually predicts cultural fit when hiring technical talent is not vibes in a room. It is alignment on how work gets done: how decisions are made, how disagreements are handled, how autonomy is distributed, how feedback is given and received. These things can be explored through structured questions. They cannot be reliably gauged from whether someone seemed warm or enthusiastic in a forty-five-minute conversation.
The culture interview is often the weakest stage in technical hiring because it is the most loosely designed — fewest clear criteria, most implicit judgment, most vulnerable to bias. Design it the same way you design the technical interview. Know what you are testing. Have consistent questions. Score responses against defined criteria.
When a strong candidate declines an offer, the internal explanation is almost always compensation. They got more money somewhere else. The budget was not competitive. If only you could pay more.
Salary matters. Underpaying will always cost you candidates. But research on why technical candidates choose between comparable offers consistently shows that compensation is rarely the only factor and often not the deciding one. Engineers cite the quality of the problem they will be working on, the experience of the people around them, the degree of autonomy they will have, and whether the company’s mission resonates with them.
More relevantly, the speed and quality of your hiring process is itself a signal about what it would be like to work for you. A company that moves slowly, communicates poorly, and treats candidates as interchangeable sends a message before any salary number does. You will lose some candidates to higher offers — that is unavoidable. You should not be losing candidates because your process was slow or disrespectful of their time. That is fixable.
When hiring technical talent repeatedly fails to produce strong shortlists, the conclusion is often that the talent is not there. The market is too thin. The candidates are not good enough. This conclusion is usually wrong, and it matters that it is wrong because it directs energy toward the external problem rather than the internal one.
The more useful question is whether the hiring criteria have been set correctly. Requirements that demand five to eight years of experience in a technology that has only existed for four years, or that specify combinations of tools rarely found together, or that conflate seniority with age — these produce thin shortlists not because the talent does not exist but because the brief has been written in a way that excludes it.
Good technical hiring requires an honest conversation about must-haves versus nice-to-haves. It requires asking whether a requirement is actually predictive of job performance or whether it is a habit, a proxy, or a copy from a previous role. And it requires the confidence to hire someone who has eight of the ten listed things if those eight are the ones that actually matter.
The companies that do well at hiring technical talent are not the ones with the best market conditions or the largest budgets. They are the ones that have looked honestly at their own process, identified where candidates are dropping out and why, and made specific changes to address those points.
That usually means designing a process that moves in weeks, not months. Writing job descriptions that are specific about what matters rather than comprehensive about everything. Using active sourcing alongside passive advertising. Making technical assessments short enough to complete and realistic enough to be meaningful. Treating the offer stage as a sales conversation, not an administrative one.
None of this is revolutionary. But all of it requires stepping back from the stories about why hiring technical talent is hard and asking a more honest question: what would you do differently if you genuinely believed the problem was fixable?