Engineering hiring has never had more infrastructure around it.
Recruiters today have access to LinkedIn, job boards, sourcing platforms, referrals, specialist communities, recruitment partners and increasingly sophisticated AI tools. Finding people who appear to match an engineering requirement has become faster, and a single opening can generate hundreds of potential candidates.
Yet ask recruiters or engineering leaders whether finding the right engineer has become equally easier, and the answer is often very different.
A company may receive hundreds of applications for a role. Twenty candidates look relevant enough to shortlist. Eight or ten eventually reach the engineering team. After the first meaningful technical conversations, perhaps only two or three are considered strong enough to continue.
The natural response is often to widen the funnel again. Source more candidates, open another channel, add another recruiter or bring in another recruitment partner.
But if candidates are entering the funnel and consistently dropping out once meaningful technical evaluation begins, is sourcing really the problem?
This is what we think of as the engineering hiring paradox: companies have become significantly better at finding engineers, but finding engineers and identifying the ones genuinely worth interviewing are two very different problems.
The distinction matters because solving the wrong problem doesn't just make recruitment inefficient. It can consume a surprising amount of engineering capacity along the way.
Consider a company looking for a Senior Backend Engineer.
The requirement asks for seven or eight years of experience, Java, Kafka, AWS, microservices and experience working in a product environment. A recruiter identifies several candidates who meet almost every criterion. Their experience levels are similar, their technology stacks overlap and they have worked at credible companies.
On paper, they all look relevant.
But the Engineering Manager may actually be looking for something the CV doesn't clearly reveal. Has this person designed distributed systems, or primarily worked within systems designed by someone else? What architectural decisions have they personally made? Have they dealt with production failures at scale? Can they explain the trade-offs behind their technical choices? When faced with an unfamiliar engineering problem, how do they reason through it?
Two engineers can have remarkably similar CVs and very different answers to those questions.
This is where engineering hiring starts behaving differently.
The information that makes someone searchable is not necessarily the information that makes someone qualified.
Technologies, titles, years of experience and previous employers are valuable signals for finding potential candidates. But they don't automatically establish technical depth, ownership, problem-solving ability or engineering judgement.
The gap becomes even wider as roles become more senior. When hiring an Engineering Manager, Head of Engineering, VP Engineering or CTO, companies aren't simply looking for someone who has used the right technologies. They are evaluating architecture decisions, technical leadership, organisational judgement, team building, trade-offs and the ability to operate within the company's particular stage and constraints.
A resume remains an important part of the process. But it tells you primarily where someone has been and what they have been exposed to.
Engineering hiring ultimately needs to determine what they can actually do in the environment you're hiring them into.
That's a much harder signal to establish.
A weak signal early in the funnel doesn't eliminate the need for evaluation. It simply moves that evaluation further downstream.
A recruiter finds a candidate who appears relevant. The candidate clears an initial conversation and reaches an Engineering Manager. Twenty or thirty minutes into the technical discussion, it becomes apparent that their depth isn't what the role requires.
The candidate is rejected.
There's nothing inherently wrong with that. Hiring involves evaluation and rejection. The problem appears when the same pattern repeats across candidate after candidate.
Consider a simple example:
That's 32 hours of engineering capacity for a single hire.
Those hours come from somewhere. Engineering Managers and senior engineers aren't dedicated interviewers. The same people are responsible for architecture, product delivery, mentoring, incidents, technical planning and helping their teams ship.
The question isn't whether engineering teams should spend time interviewing. They absolutely should. Rigorous technical evaluation is necessary for good engineering hiring.
The more useful question is:
How much of that engineering time is being spent evaluating genuinely plausible candidates, and how much is being spent filtering candidates whose technical mismatch could have been identified earlier?
This creates a cost that most hiring dashboards don't make particularly visible.
Recruitment teams understandably monitor time-to-hire, cost-per-hire, applications, submissions, offers and acceptance rates. But engineering leaders should probably be asking another question: How much engineering capacity are we consuming to make one successful hire?
That turns engineering hiring efficiency into more than an HR issue.
It becomes an engineering productivity issue.
When an engineering position remains open, increasing candidate volume feels logical.
Sometimes it is exactly what the company needs. A highly specialised role may have a genuine supply problem. The available talent pool may be small, compensation may be misaligned with the market, or the company may be looking for an unusual combination of capabilities.
But not every difficult engineering search is a sourcing problem.
Consider two companies hiring similar engineers:
Company A generated almost twice as many candidates. It also produced more shortlists and conducted more technical interviews.
Company B ultimately produced twice as many candidates who progressed.
If we looked only at sourcing activity, Company A might appear to have the stronger hiring engine. Once we look at what happens after technical evaluation, the picture changes.
More activity isn't necessarily more hiring effectiveness.
If Company A responds by sourcing another 100 candidates without understanding why eight out of ten technical interviews aren't progressing, it may simply create more work for recruiters and engineering teams.
Before expanding the top of the funnel, it helps to understand where the existing funnel is actually breaking.
One reason engineering hiring problems are difficult to solve is that very different underlying issues can produce the same visible outcome: the role remains open.
A useful first step is therefore to diagnose the problem before deciding what to change.
These problems require different interventions.
If there simply aren't enough relevant people entering the funnel, expanding sourcing may be exactly the right move.
If recruiters and engineering managers have different interpretations of what a strong candidate looks like, adding more sourcing capacity won't resolve the disagreement.
If apparently relevant candidates repeatedly fail as soon as meaningful technical evaluation begins, the company needs to examine the signals being used before that stage.
And if technically strong candidates reach the end but consistently decline, the problem may have little to do with sourcing or technical evaluation at all.
Calling all of these a “candidate quality problem” makes it difficult to fix any of them.
Candidate volume is easy to measure.
How many candidates did we source? How many applications did we receive? How many profiles were submitted?
Those numbers tell us how much activity happened. They don't necessarily tell us whether the hiring process is becoming better at identifying the right engineers.
For engineering roles, we believe two additional metrics can provide a more useful view of funnel quality.
The question behind this metric is straightforward:
What percentage of shortlisted candidates actually progress after the first meaningful technical conversation?
The calculation is simple:
Suppose 20 candidates are shortlisted and four demonstrate sufficient technical fit to move forward. The shortlist-to-technical-progression rate is 20%.
There isn't a universal percentage that makes a hiring process healthy or unhealthy. A founding AI engineer, a mid-level Frontend Engineer and a CTO will naturally have very different funnels.
The value comes from establishing your own baseline and watching what happens over time.
If the rate remains consistently low across multiple searches, that gives recruiting and engineering teams somewhere useful to investigate. Is the role defined clearly enough? Are recruiters and hiring managers aligned on what “good” looks like? Are candidates being sourced primarily through titles and keywords? Are years of experience being treated as a proxy for technical depth? Are the signals used during initial screening actually correlated with what the technical interviewer evaluates later?
These questions are considerably more useful than simply concluding that “we're not getting good candidates.”
The second metric looks at the same process from the engineering team's perspective:
If 12 candidates go through one-hour technical interviews involving two engineers, that's already 24 engineering hours. Add subsequent rounds and the number grows quickly.
Again, a high number isn't automatically bad. A senior or business-critical engineering hire may justify significant internal investment.
The objective isn't to drive interview hours as low as possible.
The objective is to understand where those hours are going.
If most are spent having serious technical conversations with strong candidates, the process may be working exactly as intended.
If a significant percentage is spent discovering obvious technical mismatches within the first 20 minutes, there may be an opportunity to improve the signal earlier in the funnel.
Together, these metrics shift the conversation away from:
How many candidates are we generating?
towards a more valuable question:
How efficiently are we turning candidate volume into worthwhile engineering conversations?
It would be easy to conclude that the solution is simply “more technical screening.”
That's incomplete.
By the time a candidate reaches an assessment, several important decisions have already been made. The role has been defined, a search strategy has been created, candidates have been identified and profiles have been screened.
If the technical context behind those decisions is weak, adding another interview stage simply moves the problem around.
A stronger engineering hiring process starts by translating the requirement into something more useful than a technology checklist.
Take a typical requirement:
7+ years of experience. Java. AWS. Kafka. Microservices.
Those criteria help someone search. They don't necessarily explain what the company needs.
A stronger hiring brief answers different questions. What will this engineer actually own? What kinds of systems will they work on? At what scale? What technical decisions will they make independently? What problems should they have solved before? Which capabilities are genuinely non-negotiable? And what would distinguish an acceptable candidate from an exceptional one?
Now the recruiter has something much richer to work with.
Instead of searching only for someone who has “Kafka” on their CV, they can look for evidence of why and how the technology was used. Instead of filtering primarily by years of experience, they can look for ownership, complexity, scale and outcomes.
This is also why the answer isn't to turn recruiters into engineers.
A recruiter hiring Backend, Frontend, DevOps, Platform, Data and AI/ML talent cannot reasonably develop deep technical expertise across every discipline. Nor should that be the expectation.
Recruiters bring expertise in talent markets, sourcing, candidate engagement, communication, process management, compensation and closing. Engineering expertise contributes something different: understanding whether a candidate's experience and technical depth match the actual engineering problem the company needs them to solve.
The strongest engineering hiring process combines both.
And importantly, that collaboration needs to happen early enough to improve the quality of the funnel itself, rather than waiting until the internal engineering team has effectively become the final filtering layer.
None of this means companies should stop sourcing aggressively or try to eliminate candidates from the process as quickly as possible.
There will always be roles where more sourcing is required. Strong candidates will occasionally underperform in interviews. People with unconventional backgrounds may outperform what their CV suggests. Hiring will always contain uncertainty.
The objective isn't to create a perfectly predictable funnel.
It's to understand which problem you're actually trying to solve before adding more volume.
If you have a sourcing problem, expand the talent pool. If you have a calibration problem, improve the conversation between recruiting and engineering before the search begins. If you have an evaluation problem, introduce stronger technical signal earlier. And if engineering teams are spending an increasing amount of time interviewing candidates who are clearly misaligned, measure that cost rather than treating it as an unavoidable part of hiring.
At ProfoundIQ, this thinking shapes how we approach engineering hiring. We combine recruiting expertise with technical evaluation by experienced engineering leaders, with the objective of improving the quality of candidates reaching a company's internal interview process rather than simply increasing the number of profiles entering it.
But the broader principle applies whether a company hires entirely in-house or works with an external partner.
The next time an engineering role isn't closing, don't immediately ask:
“How do we get more candidates?”
First ask:
“Where are we losing the right candidates, and where are we letting the wrong ones progress?”
That question tells you far more about the health of an engineering hiring process.
Because the strongest engineering hiring process isn't necessarily the one with the biggest pipeline.
It's the one with the best signal-to-noise ratio.
