How to Source Software Engineers in 2026: The Signals That Still Work

The engineering demand that came back is the hardest demand there is. Indeed's Hiring Lab reported in July 2026 that US software development postings have grown almost 15% since late February 2025, and that 71% of the increase between May 2025 and May 2026 came from senior roles. Another 37% came from jobs with AI in the title. So the reqs landing on your desk are heavier at the top, and they landed at the exact moment the public evidence you use to judge engineers became much harder to read.

Both halves of that matter. Knowing how to source software engineers used to be mostly a reach problem: find the profile, find the address, write something decent. In 2026 it is a judgement problem first. Public code volume has inflated across the board, so the heuristics most desks still run on, the busy contribution graph and the long repo list, sort people much worse than they did three years ago.

This is what still sorts them.

The reqs coming back are senior, and senior engineers are not reading job ads

Hiring Lab's July 2026 analysis is the sharpest read available on where the recovery actually landed. Postings sit around 27.5% below their pre-pandemic level, but the growth that has returned is concentrated: 71% senior, 37% AI in the title. Staff and principal roles, and titles that did not exist in your ATS taxonomy two years ago.

Now put that next to who is available. In Stack Overflow's 2025 Developer Survey, fielded across more than 49,000 developers in 177 countries, 45.6% said they were not looking at all and 28.8% were considering a change somewhat. Only 14.8% were considering strongly.

Read the middle number again, because that is your market. The largest movable group is not applying to anything. They will not see the ad, they are not in the ATS, and they are not refreshing a job board. Reaching them is passive sourcing, and at the senior end it is close to the only game.

Why proof of work got harder to read

GitHub's Octoverse 2025, published October 2025, is the clearest picture of what happened to the evidence layer. More than 180 million developers now build on GitHub, over 36 million of whom joined in the past year, which works out at more than one new developer per second. They created 121 million new repositories in 2025, pushed nearly a billion commits, up 25.1%, and merged 43.2 million pull requests a month, up 23%. Eighty percent of new developers on GitHub use Copilot in their first week.

Every one of those is a volume number, and every one of them went up at once.

That is genuinely good news for the ecosystem, and it is a real problem for anyone using volume as a proxy for skill. A dense contribution graph in 2022 was a signal because producing it cost something. The cost fell. Repo count, commit count, streaks and stars all inflated together, which means they no longer separate the engineer you want from the one you do not.

The composition shifted too, and this part is useful. TypeScript overtook both Python and JavaScript in August 2025 to become the most-used language on GitHub. AI-related repositories reached 4.3 million, and 1.1 million public repositories now use an LLM SDK, 693,867 of them created in the past twelve months alone, up 178% year on year. If your search string was written before that, it is pointed at where the work used to be.

The signals that still sort engineers

The pattern is simple once you see it. Anything one person can generate went up. Anything that requires other engineers to grant something did not. Sourcing on the second category still works.

1. Review comments on other people's code. Writing code got cheaper. Being trusted to review someone else's did not. A profile with substantive review history on a repo the person does not own is telling you that other engineers rate their judgement.
2. Maintainer, triage or release rights on something other projects depend on. Not "has a repo with stars". Is anyone downstream of them? Check who imports the package, not how many people bookmarked it.
3. Work that survived contact with time. A repo maintained across three years, with issues answered, a changelog that admits breaking changes and a migration note for the people affected. That is operational maturity, and it is completely invisible in a keyword search.
4. The written record. RFCs, design documents, post-incident write-ups, deprecation notices, conference talks. Reasoning is the artefact that did not commoditise, and for senior roles it is the closest thing to a work sample you can read before you ever make contact.
5. What they moved toward. Someone whose public work moved into TypeScript, model runtimes or inference tooling in the last eighteen months is telling you where they want to work next. That is a targeting signal and an outreach hook in the same observation.

Notice that none of these are in a job title, which is the same conclusion the skills-based hiring shift is pushing from the other direction, and the practical reason keyword strings keep under-returning on engineering roles.

Where the engineers you need actually are

If the movable group is not applying, the sourcing question becomes where they leave traces on purpose.

• Conference and meetup archives. Accepted talks and CFP listings are a curated list of people who have already volunteered to explain their work in public, with the topic attached.
• Package registries and maintainer files. The maintainer list on a dependency your client already uses is a shortlist of people who know that stack at depth, and it is public.
• Written technical work. Engineering blogs, newsletters, long-form answers, spec and standards discussion. Search the reasoning, not the resume.
• Domain-specific hubs. For machine learning, model hubs, competition leaderboards and paper repositories carry more current signal than a profile page does.
• Alumni of the systems you care about. People who worked on a specific migration, platform or product line, found through the write-ups and talks about it rather than the company name.

There is a fair objection to all of this, and experienced sourcers raise it constantly: reading code and talks one profile at a time is slow, and a desk with fifteen live reqs does not have that time. That is true, and it is the actual argument for tooling. The judgement is what you should be spending your hours on. The collection should not be.

Writing to an engineer who does not need a job

The same Stack Overflow survey found that 84% of developers use or plan to use AI tools, up from 76%, and 51% of professional developers use them daily. It also found that trust moved the other way. More developers actively distrust the accuracy of AI output, 46%, than trust it, 33%, and only 3.1% highly trust it. The single biggest frustration, named by 66%, is output that is "almost right, but not quite".

That is the audience reading your first message. Professionally, daily, they practise spotting text that is plausible and slightly wrong. Generic outreach does not read as merely bland to them, it reads as a competence signal, and it is the wrong one.

What survives that reader:

• Name the artefact. The specific repo, talk, migration or write-up, and one sentence about why it is relevant to this role. Not "your impressive background".
• Be concrete about the technical reality. The stack as it actually is, including the parts that are old. Engineers assume a vague description is hiding something, and they are usually right.
• State the process up front. How many stages, whether there is a take-home, who they will meet. Senior candidates are protecting their time above all else.
• Say what is genuinely open. Scope, ownership, the argument they would get to have. That is what moves someone who is not looking.

Our templates for outreach that gets replies go deeper on structure. The rule for engineering roles is narrower: if the message could have been sent to a hundred people, it will be read as though it was.

Run it on one engineering req

Take a live senior role, ideally one that has been slow.

1. Rewrite the must-haves as evidence you could point at, not titles you could match.
2. Build the pool from where the work is visible, and let it reach two adjacent stacks you would not normally touch.
3. Score every profile the same way, and record which evidence satisfied which requirement.
4. Write to the top ten yourself, each message naming one specific thing that person built.
5. Compare reply rate and screen pass-through against your last three slates for the same role family.

One req, two weeks. The measurement is the point, because it converts a method argument into a number your hiring manager can see.

Want the collection handled so you can spend the hour on judgement? Instalent takes a plain-language brief and searches the web, GitHub and professional-network signals in parallel, then scores every profile against your criteria with the evidence attached, reading real work history, education and public code rather than keyword counts. Add verified enrichment from multiple sources and multichannel outreach and the whole chain sits in one place. Start free, or see how it fits an in-house team.

Sources

• Indeed Hiring Lab - AI and Job Postings: From Destruction to Creation? (July 8, 2026, Guillermo Gallacher: US software development job postings up almost 15% since late February 2025; 71% of the May 2025 to May 2026 increase from senior roles; 37% from jobs mentioning AI in the title; postings about 27.5% below pre-pandemic level)
• GitHub - Octoverse 2025 (October 28, 2025: more than 180 million developers, over 36 million joined in the past year, 121 million new repositories in 2025, nearly 1 billion commits up 25.1%, 43.2 million pull requests merged monthly up 23%, TypeScript most-used language since August 2025, 4.3 million AI repositories, 1.1 million public repositories using an LLM SDK with 693,867 created in twelve months, 80% of new developers use Copilot in their first week)
• Stack Overflow - 2025 Developer Survey, AI section (fielded May 29 to June 23, 2025, 49,000+ respondents across 177 countries: 84% use or plan to use AI tools, up from 76%; 51% of professional developers use them daily; 46% distrust the accuracy of AI output versus 33% who trust it; 3.1% highly trust; 66% cite "almost right, but not quite" as their biggest frustration)
• Stack Overflow - 2025 Developer Survey, Work section (45.6% not looking for a new role, 28.8% considering somewhat, 14.8% considering strongly)