What if the engineer you’re trying to hire barely exists?


In a nutshell
  • A difficult engineering search does not automatically mean the company needs more recruiters or a larger sourcing funnel. Sometimes the market is the specification, not the search.
  • The more requirements a company combines — stack, domain, seniority, industry background, location — the smaller the intersection of people who can satisfy all of them at once.
  •  Skills-first hiring can broaden the search, but only when engineering and recruiting agree on which capabilities are genuinely essential and which requirements are proxies for them.
  • Adjacent experience does not have to mean a lower technical bar. It can mean looking for a different path to the same underlying capability.
  • When a talent market repeatedly fails to produce the expected profile, that evidence should influence the requisition, geography, team design, or hiring model before the company simply searches harder.

 When a difficult search is telling you something

A difficult technical requisition usually creates a predictable response. The role stays open longer than expected, the strongest candidates satisfy most but not all of the requirements, and the hiring team concludes that it needs a wider search. Then, another recruiter gets involved, another sourcing channel opens, and the geography expands. More profiles enter the funnel.

Sometimes that is exactly what the company needs. But specialized engineering hiring creates another possibility that is easy to miss: the search may be working perfectly well, and the market may be returning an answer the company does not want to hear.

The combination of skills in the requisition may be much rarer than expected. Several requirements may be describing the same capability in different ways. A technology that looked non-negotiable when the job description was written may turn out to be learnable. Or the company may have combined responsibilities that realistically belong to more than one person.

That distinction matters because the market for technical skills is already moving quickly. The World Economic Forum's Future of Jobs Report 2025, based on responses from more than 1,000 employers, found that 63% considered skills gaps a major barrier to business transformation, while almost 40% of skills required on the job are expected to change by 2030.

The problem is not only finding people with scarce skills. Engineering organizations also need a better way to determine which skills they actually need to buy from the market in the first place.

The intersection can be much smaller than the talent pool

Imagine a team searching for someone with deep distributed-systems experience, knowledge of a particular infrastructure stack, previous work in a regulated industry, eight or more years of experience, strong customer-facing communication, and availability in one location.  A technical role can become exceptionally difficult to fill even when every individual requirement looks reasonable, because the problem is the intersection, not any single requirement.

That is the distinction Jason Gingrich makes in Episode 2 of Hacking Borders. Gingrich, Head of Recruiting at Fab2 (formerly Atomic Semi), has recruited across robotics, AI, and semiconductor environments where the relevant talent population can become extremely constrained.

His point is not that specialized people are impossible to find. In some cases, finding the obvious profiles is relatively straightforward because everyone in the market already knows who they are. The harder part is what the company does after discovering that there may be only a handful of exact matches.

 

A job description captures a moment. The work keeps moving.

Gingrich describes the job description and the résumé as snapshots. Each captures one moment: what a hiring manager believed the team needed when the role was opened, and what a candidate chose to record about previous work. Neither document can fully describe the work that will happen after the person joins.

That is why one of his most useful recruiting questions is not whether somebody satisfies every bullet in the requisition, but what the person actually needs to drive once hired.

This is increasingly relevant as more employers experiment with skills-first hiring. An OECD report published in 2025 found that skills-first approaches can broaden talent pools, improve job matching and make labor markets more adaptable, while also warning that employers still face genuine challenges in assessing and validating skills consistently.

LinkedIn's 2025 Future of Recruiting research points in the same direction. Ninety-three percent of surveyed talent-acquisition professionals said accurately assessing candidates' skills was crucial to improving quality of hire, and LinkedIn reported that companies conducting the most skills-based searches were 12% more likely to make what the platform defines as a quality hire.

Those findings do not mean employers should remove technical requirements or replace experience with vague claims about potential. They make the opposite argument more useful: if skills matter, companies need to become more precise about which skills the work actually depends on.

Separate the capability from the proxy

A useful way to pressure-test a specialized requisition is to ask what each requirement is intended to tell the company.

Requirement in the requisition Question worth asking
Exact job title What responsibility does that title represent?
Experience with one technology Does the work require that tool on day one, or the underlying technical capability?
Background at a particular type of company What experience are we trying to infer from that pedigree?
Specific industry experience Is the domain knowledge essential, or can it be acquired during ramp-up?
Eight or ten years of experience Are we actually trying to measure judgment, autonomy, scope, or technical depth?
One location Does the work require physical proximity, or a specific collaboration model?

This is not an argument for stripping requirements out until the role becomes easy to fill. It is a way of distinguishing a capability from one familiar signal that somebody possesses it.

A senior infrastructure role, for example, may initially be defined through an exact cloud platform, orchestration stack, and experience at companies above a certain scale. Once the search begins, however, the stronger signal may be whether candidates have designed resilient distributed systems, diagnosed performance under load, and made infrastructure decisions with incomplete information. The stack still matters; it simply may not define the entire capability.

That same responsibility-first logic already appears in CodersLink's Mexico Tech Talent by Role analysis: the useful starting point is not simply which title to open, but what responsibility the team needs someone to own. 

Role calibration adds one more step: once the responsibility is clear, use market evidence to test whether the specification built around it is realistic.

Adjacent skills are useful when the underlying problem transfers

When the exact profile is scarce, adjacent experience becomes useful only if it maps back to the work.

A candidate may not have used the exact technology in the requisition, but may already have solved a similar reliability, infrastructure, performance, or systems problem in another environment. The question is not whether the résumé looks familiar. It is whether the underlying capability transfers.

That is where recruiting and engineering need each other. Recruiting can show where relevant experience exists in the market; engineering has to decide whether that experience is technically transferable to the role.

The same logic should shape the interview process. If the company is willing to look beyond exact credentials, it also needs a way to test the capability underneath them. Otherwise, “skills-first” simply replaces one proxy with another.

 

A recruiting funnel can become market research

The first version of a requisition does not need to be the final one.

A company can define the role, test it against the market, observe what keeps happening, and bring that evidence back into the hiring decision. Over time, the process becomes less linear:

  • Define the role. Start with the business outcome, the capabilities required, and the assumptions behind the initial profile.
  • Search the market. Test that profile against the candidates who actually exist, not only against the people the team expected to find.
  • Observe the patterns. Look for repeated signals: the same small candidate pool, strong profiles missing the same requirement, compensation moving beyond the planned range, or relevant expertise clustering in another geography.
  • Recalibrate the assumptions. Decide whether a requirement is truly essential, whether an adjacent skill can transfer, or whether the role, compensation, location, or team structure needs to change.
  • Search again. Return to the market with a better-defined profile and see whether the new hypothesis produces a stronger match.

None of those signals automatically means the requisition is wrong. They mean the company has learned something it did not know when the role was written.

That is one reason recruiters who act as market advisors, not just sourcers, become more valuable in technically constrained markets. If recruiting is measured only by how many qualified résumés it produces, the natural response to a weak funnel is more sourcing. If the function is also expected to understand the talent market, a weak funnel can produce something more useful: evidence that helps the business decide whether the profile, compensation, location, or team structure should change.

 For engineering leaders, this matters because a wider funnel cannot manufacture a capability that barely exists. 

 When a hiring problem becomes a team design problem 

A difficult requisition can reveal more than a sourcing problem. Sometimes the role itself has absorbed too many forms of ownership: deep specialization, execution, mentoring, stakeholder communication, and perhaps even knowledge of a specific market or product environment. That can lead to several different decisions:

  • A highly specialized responsibility may stay with one senior hire while broader execution sits with the rest of the team.

  • Part of the capability may be developed internally.

  • The search may expand geographically.

  • A bounded workstream may be supported through external engineering capacity while the most specialized ownership remains inside the company. 

That same relationship between talent availability and team design is explored in Hacking Borders’ Follow the Talent, Then Design the Team.

From there, the hiring decision starts to overlap with engineering capacity planning. The same logic appears in our comparison of in-house hiring and staff augmentation for engineering growth: specialization, expected duration, demand certainty, and management capacity all influence which model makes sense.

Geography works the same way. Mexico can support a wide range of engineering hiring strategies, but role depth, seniority, specialization, and city-level concentration still shape the actual market. That is why our Mexico Tech Talent Ecosystem 2026 analysis treats Mexico as a collection of distinct talent markets rather than one interchangeable pool.

For specialized hiring, the better question is not whether a country has developers. It is whether the capability the team needs exists there with enough depth and operating fit to support the work.

Before you search harder, ask what the market has already told you

Some technical roles are genuinely difficult to fill. The capability may be rare, the ramp-up may be limited, and the right decision may still be to compete for one of the few people who match the original profile.

The difference is how the company reaches that conclusion. A stronger sequence is:

Business outcome → Core capability → Must-have skills → Transferable skills → Market evidence → Geography → Hiring model

That process may confirm the original requisition, or it may reshape it. Either way, the hiring team ends up with something more useful than a larger funnel: a clearer understanding of what the role actually requires and what the market can support.

 For specialized engineering teams, that is where recruiting becomes more than sourcing. It becomes part of the decision-making process behind the role itself. That is the same question Jason Gingrich explores in Episode 2 of Hacking Borders: how the market should change the way a company defines the role. 

 

Key takeaways
  • Define the role by what the person must drive. A job description is a snapshot of what the team believed it needed when the role opened; the work keeps moving after the hire.
  • Pressure-test every requirement. Titles, pedigree, years of experience, and single-tool expertise are often proxies. Ask what capability each one is meant to signal before treating it as non-negotiable.
  • If you look beyond exact credentials, change the interview too. Adjacent experience only helps when engineering confirms the underlying problem transfers, and when the assessment tests that capability directly.
  • Run the funnel as a feedback loop. Define, search, observe, recalibrate, search again. A shrinking candidate pool, the same missing requirement, or compensation drifting past the range is market evidence, not a cue for more sourcing volume.
  • Decide the hiring model last. When the capability is truly scarce, the answer may be splitting the role, developing skills internally, expanding geography, or adding external capacity, rather than searching harder.
FAQs