How do you source passive software engineers who aren't on LinkedIn?

Picture this: you've spent two weeks on LinkedIn searching for a senior backend engineer. The profiles you can find are two years out of date. The two people who respond want $215,000. And the engineer you actually need (the one quietly maintaining a 4,000-star open-source library, shipping code on evenings and weekends, answering questions on Stack Overflow that 80,000 people have read) doesn't have a LinkedIn profile at all.

This isn't a rare edge case. It's the norm in technical recruiting.

According to the 2025 Stack Overflow Developer Survey of over 49,000 developers, 45.6% of engineers are not actively seeking a new role, and another 28.8% describe themselves as only "somewhat open." That's roughly three in four developers sitting in passive territory. They're not on job boards. They're not answering InMails. But they're working, building, and leaving a public trail of technical output every day. You just have to know where to look.

The engineers who would genuinely improve your team are usually the ones not looking. Sourcing them requires going to where they actually spend their time, not where recruiters usually post.

Why LinkedIn misses most of the market

LinkedIn has around 1 billion members globally, but approximately 30% of software engineers don't have a profile at all, according to analysis from recruiter.daily.dev. Among those who do, profiles are often last updated when the engineer was actively job hunting, sometimes years ago. Stack, language preferences, and current work are underrepresented. There's no way to verify that someone who lists "Node.js" in their skills has shipped anything meaningful with it in the past three years.

LinkedIn InMail doesn't help. Response rates for cold outreach to technical candidates average 10.3%, according to LinkedIn's own benchmark data, and that's the optimistic figure. For unsolicited messages to engineers not marked "Open to Work," the real number is often lower.

LinkedIn is built for networking and job applications. Software engineers, especially experienced ones, treat it as a directory of past jobs updated every few years. Their actual work lives somewhere else.

Where passive engineers actually are

GitHub

GitHub has 180 million developers as of the 2025 Octoverse report, and 36.2 million new developers joined in 2025 alone (roughly one per second). Unlike LinkedIn, activity on GitHub is continuous and verifiable. Every commit, pull request, code review, and issue comment is timestamped and searchable.

The engineers you want are here. The challenge is finding them systematically.

GitHub's native search lets you filter by language, location (where users have self-reported it), and repository topics. A search like language:Python location:"San Francisco" returns developers who have public repositories in Python and list San Francisco in their profile. You can also search for contributors to specific repositories adjacent to your stack. Someone contributing to a major React library is almost certainly a skilled React engineer worth reaching out to.

Repository stars and fork counts are a rough proxy for quality and community standing. Developers who maintain repos with thousands of stars have earned public credibility from peers who know what good code looks like. A 2025 Beamery study found that 83% of technical hiring managers trust GitHub profiles more than traditional resumes.

For a methodical approach to reading what you find, what commit history actually tells you about a developer covers the specific signals worth looking at once you've found a profile.

Stack Overflow

Stack Overflow's reputation system is one of the most useful passive-sourcing tools in technical recruiting, and almost nobody uses it for that purpose.

Engineers who have accumulated 10,000+ reputation points have answered hundreds of questions that were vetted correct by other engineers. Their answers show communication clarity, depth of knowledge, and the specific technologies they actually work with, beyond what any resume field captures. You can filter by tag (React, Kubernetes, Rust, etc.) and sort by reputation to find the most active, most validated voices in a given technology area.

Stack Overflow lets anyone view a user's profile, top answers, and activity history. Users who include contact information or link to their GitHub are signaling at least some openness to professional contact. Even when they don't, the profile is enough to do the research before you reach out on another channel.

Developer communities: Discord, Slack, Reddit

The most active developer communities have migrated to Discord and Slack over the past several years. There are large active servers for communities like Reactiflux (React), the Rust Programming Language server, Elixir's Slack workspace, the Kubernetes Slack, and dozens more. Lurking in these communities gives you a real-time view of who's helping others, who's asking sophisticated questions, and who's building things worth watching.

Reddit is similar. r/programming, r/webdev, r/devops, and language-specific subreddits all surface engineers who are engaged enough with their craft to spend time discussing it publicly. The level of participation someone maintains in a technical community is meaningful signal about how much they care about what they do.

You're not there to spam DMs. You're there to observe, occasionally contribute, and reach out to specific people with specific, informed messages. The difference between "hey I saw your profile" and "hey I saw the answer you posted last week about Go concurrency, I'd love to talk about a role where you'd be doing a lot of that" is about 20 percentage points in response rate.

Open source contribution graphs

Beyond GitHub profiles, contribution graphs to specific well-known open-source projects are a sourcing channel most recruiters haven't fully tapped. Projects like React, Vue, Django, Kubernetes, and Terraform all have public contributor lists. A developer who has had code merged into a major open-source project has passed a real peer review process. These are engineers who have shipped real changes to it, vetted by the project's maintainers.

The contributor pages for major projects are publicly accessible. Sorting by recent activity surfaces engineers who are currently active, not just historically credited.

How to find passive engineers on GitHub: a practical approach

By language and location: GitHub's advanced search (github.com/search?q=language:TypeScript+location:Austin) filters by self-reported location. It's imperfect (not everyone fills in a location), but it's a starting point. Combining this with a minimum follower count (followers:>50) roughly filters for engineers who have built some public presence.

By repository topic: GitHub topics let you search for repositories tagged with specific technologies. Searching topic:nextjs stars:>100 surfaces actively maintained Next.js projects. The people maintaining these are worth looking at.

By recent activity: The GitHub Events API and tools that index public GitHub activity (including riem.ai) can surface engineers based on what they've actually done in the past 30–90 days: merges, reviews, starred frameworks, recent contributions. This recency signal is often more relevant than a profile that hasn't been touched in a year.

By organization membership: Many engineers list their current employer's GitHub organization in their profile. Searching for engineers at specific companies (a competitor, a company you admire technically, a startup that just shut down) is a targeted sourcing strategy that LinkedIn doesn't support as cleanly.

For context on what to look for once you've found a profile, how to tell if a developer is actually senior from their GitHub profile walks through the specific signals that separate senior engineers from mid-level ones in public GitHub data.

Reaching out when you find someone

Finding a passive candidate and actually getting a response are two different problems.

The engineers most worth recruiting are also the ones getting the most messages. A generic InMail about a "great opportunity" goes straight to the ignored pile. What works instead is specificity: reference something real and recent from their public work.

"I read through your PR on the authentication module for [project] — the approach to token rotation you proposed was really clean. We're building something similar at [company] and I think you'd find the problem interesting." That message demonstrates that you actually looked, it's relevant to what they care about, and it respects their time enough to say something specific.

Codility's technical recruiting team found that outreach referencing specific GitHub projects consistently generates a 30% response rate from passive candidates. Personalized messages tied to specific contributions can produce 5x higher response rates compared to generic outreach. Keep messages under 400 characters where possible. LinkedIn's own data shows this improves response rates by 22%.

The full mechanics of writing outreach that developers actually respond to are covered in how to write a cold recruiting email a developer will actually respond to. The principles apply equally to LinkedIn messages, GitHub profile contact links, and email.

Timing and cadence

Passive candidates are not in a rush. They're not refreshing their inbox waiting for your reply. A follow-up message two or three days later can double your response rate — but a third message within a week will almost certainly get you blocked.

The best approach is a two-message sequence. First message: specific, brief, focused on their work and the problem space. Second message (after 4–5 days): one sentence. Something like "Wanted to make sure this didn't get buried. Happy to share more context if timing is ever right." Then stop.

The developers most worth hiring are evaluating you just as much as you're evaluating them. A sequence that respects their time signals something about the company culture before they've even read a job description.

Building a pipeline, not a one-time search

One-off GitHub searches work, but the more sustainable approach is building a living pipeline of engineers you've already identified and bookmarked before a role opens. This takes more upfront effort and pays off significantly when you're under hiring pressure.

Bookmark GitHub profiles worth following. Keep a list of high-quality Stack Overflow contributors by technology. Set up job alerts or searches for specific repositories in your stack. Follow the release notes for frameworks your engineering team uses. The people writing those changelogs are usually remarkable engineers.

When a role opens, your first round of outreach goes to people you already know something about. You've probably already read their work. The message writes itself.

FAQ

What percentage of software engineers are passive candidates?

According to the 2025 Stack Overflow Developer Survey, 45.6% of developers are not actively seeking new roles, and 28.8% describe themselves as only "somewhat open." Combined, roughly 74% of the developer workforce sits in passive-candidate territory. Broader recruiting research from AIHR puts the global passive workforce at 70%. The practical implication is that if your sourcing strategy only reaches active candidates, you're seeing less than 30% of the available market.

How do you find software engineers on GitHub?

GitHub's advanced search supports filtering by programming language, location (self-reported), follower count, and repository topics. Searching language:TypeScript location:Seattle followers:>50 returns engineers with public TypeScript activity in Seattle who have some community following. You can also browse contributors to specific well-known repositories in your stack. Tools that index GitHub event data (commits, pull requests, code reviews) allow filtering by recency, surfacing engineers who are currently active rather than just historically credited.

What is the response rate for recruiting messages to passive developer candidates?

LinkedIn InMail averages a 10.3% response rate for technical candidates, according to LinkedIn's own benchmark data. By contrast, Codility found that outreach specifically referencing a candidate's GitHub contributions generates around 30% response rates. Keeping messages under 400 characters improves response rates by 22%. The primary driver of response rate is specificity: messages that reference real, recent work consistently outperform generic InMails by a wide margin.

Should I reach out to developers through GitHub directly?

Some developers include contact email in their GitHub profile bio. Others link to a personal website or Twitter where contact is possible. Direct GitHub messaging (via Issues or Discussions on their repos) is generally considered intrusive unless you have a relevant technical question. The better approach is finding a contact method they've explicitly made public (email, Twitter/X, LinkedIn link) and using that channel with a message that references their GitHub work.

How is GitHub sourcing different from Boolean search on LinkedIn?

Boolean search on LinkedIn matches keywords in self-reported profile fields. A developer can claim React expertise without ever shipping a React application. GitHub sourcing matches against actual public behavior: commits in a given language, pull requests to specific frameworks, code reviews showing architectural thinking, and contribution frequency showing sustained engagement. The signal is verified by the public record rather than self-reported. The tradeoff is that not all engineers have public GitHub activity; some work primarily in private repositories.