Tech Hiring in 2026 Is Bifurcated. Most Sourcers Are Targeting the Wrong Half.

Something strange is happening in tech recruiting right now. Companies are announcing layoffs while posting dozens of open engineering roles. LinkedIn is flooded with "available" engineers who can't get callbacks. Recruiting teams are working harder than ever and still missing their hire targets.

This is not a contradiction. It's a split market, and if you're sourcing engineers the same way you did two years ago, you're fishing in the wrong pond.

Here's what the numbers actually show: over 150,000 tech jobs have been cut in 2026 so far, with roughly 20% of those layoffs explicitly attributed to AI and automation (up from less than 8% in 2025). At the same time, job postings requiring experience with AI coding tools jumped about 340% between January 2025 and January 2026. Companies aren't done hiring engineers. They're done hiring the specific kind of engineer they used to hire.

The supply of generic software engineers has never been larger. The supply of engineers who can do what companies actually need right now has rarely been tighter. Your sourcing strategy needs to reflect that difference.

What "good" looks like in 2026

Entry-level software engineer job postings are down about 40% compared to pre-2022 levels. That stat reads as bad news for junior developers, which it is. But the flip side is what it means for hiring: companies are no longer looking for people who can execute specifications in code. AI handles an increasing share of that.

What companies are actually hiring for (whether they articulate it well in job descriptions or not) is engineering judgment. The ability to design systems, evaluate AI-generated output, make architectural tradeoffs, and understand why a system breaks at 3am in ways that aren't in any runbook. That's the job now.

The problem is that engineering judgment doesn't show up on a resume. "Led backend development for payments infrastructure" could mean someone who architected a fault-tolerant distributed system, or someone who wired up a Stripe integration following a tutorial. The resume says the same thing either way.

This is where the sourcing process breaks down for most teams. They're filtering on keywords that no longer predict what they're trying to predict.

Why resumes fail at this specific problem

Resumes were always a lossy signal. They're self-reported, they optimize for pattern-matching to job descriptions, and they reward people who've worked at recognizable companies regardless of what they did there. None of that has gotten better.

In 2026, the gap between resume signal and actual capability has widened in a specific direction. The engineers best positioned for how software development works now are people who've built real systems, made real architectural decisions, and worked at the intersection of AI tooling and production code. They're not necessarily the people who look best on paper.

A lot of them are contributors to open source projects. They've shipped real code that other engineers depend on. Their pull requests show how they think. Their commit messages show what they care about. Their choice of what to build in their own time tells you something their resume never could.

None of that shows up in a keyword search on LinkedIn.

The data that actually predicts fit

Sourcing teams tracking GitHub contributor hiring have found that engineers with three or more meaningful commits per week show 68% higher retention rates than average hires. That's not a small effect. People who contribute consistently to codebases outside of work have already demonstrated they're not just doing the job for a paycheck.

More useful for recruiters: personalized outreach based on a candidate's actual GitHub contributions gets response rates up to 5x higher than generic InMail. Engineers are used to recruiters copy-pasting a message that references their job title. When someone messages them about a specific PR they merged or a library they maintain, it reads as legitimate. It signals that you understand what they actually do.

This isn't just a nice-to-have for response rates. It changes the entire conversation. If your opening message references real work the candidate has done, you've established credibility before they've replied. That sets a different tone for everything that follows.

What good sourcing actually looks like right now

The engineers who can do what companies need in 2026 are building things. They're reviewing PRs in open source repositories. They're maintaining packages other people use. They're contributing to infrastructure projects, ML tooling, and developer tools. Some of them are doing this while employed somewhere that has no idea they're this capable.

Finding them requires looking at what they've built, not what they've written on a resume.

That means moving past "experience with X" as a filter. Job descriptions in 2026 are full of requirements like "proficiency with AI coding tools" or "experience with LLM-assisted development." Fine as signals, but almost impossible to verify from a resume or even a LinkedIn profile. What you can verify from actual code: whether someone has shipped production systems that required real architectural thinking, whether their codebase shows the kind of consistency that comes from engineering discipline, whether the problems they've chosen to solve are the kind your team faces.

It also means understanding what GitHub activity actually signals. Stars on a repo are a popularity metric, not an engineering metric. Commit frequency alone doesn't tell you much. What's worth looking for is the combination: high-quality contributions across multiple meaningful repositories, from someone who isn't already being aggressively recruited because they don't have 10,000 Twitter followers. The visible open source celebrities are expensive to recruit and often overvalued relative to less visible contributors who've done work just as good. I'd take the latter nearly every time.

And it means treating outreach as the first technical conversation. The message you send a strong candidate should demonstrate that you've actually looked at their work. Not "I noticed you work in Python and we're looking for Python engineers." Something that shows you read a PR, or understand what the project they maintain actually does, or noticed a specific technical decision they made. That's not just better for response rates. It's the right way to approach engineers who take their work seriously.

The structural problem with most sourcing tools

Most sourcing tools are still built around the same inputs: resume text, job title history, self-reported skills, LinkedIn connections. They're good at finding people who look like engineers. They're not good at finding engineers who are good at engineering.

A handful of tools have started to work from GitHub data directly. riem.ai, for instance, analyzes 30 million GitHub events per month to surface candidates based on what they've actually built. Natural language search lets you describe the kind of work instead of the keyword: "engineers who've built real-time data pipelines" rather than "Kafka OR Flink OR Spark." The "underrated" scoring is the part I find genuinely interesting: it surfaces candidates with high-quality contributions and low social visibility, which is a pretty accurate description of the engineers who tend to get overlooked.

This approach doesn't replace judgment. You still need to evaluate candidates. But it changes what you're starting from.

What this means for how you compete

The market for generic engineering talent is genuinely soft. The market for engineers with real architectural judgment and the ability to work effectively with AI tooling is still extremely competitive.

If your sourcing strategy treats those two markets as one, if you're using the same keyword-based Boolean searches for a principal engineer as you are for a mid-level hire, you're going to keep seeing the same result: lots of applicants who clear your filters, not many who clear your bar.

The teams hiring well right now have accepted that the bar has shifted. They're not looking for engineers who know the right tools. They're looking for engineers who've built things that required judgment, and they're looking for that evidence in places where it actually lives: in code, not on resumes.

That's a different sourcing workflow. It requires different tools, different outreach, and a willingness to look at candidates who don't pattern-match to the profile you've been using. But the candidates who do pattern-match to the old profile are the ones your competitors have already passed on.

The supply of engineers who can do what you need hasn't dried up. You're just looking in the wrong place.