How to source passive software engineers who aren't on LinkedIn

The best engineers you could hire are not looking for a job. They are not on job boards. Many have not updated their LinkedIn profiles in years. But they pushed code to GitHub last week. They reviewed a pull request this morning. They merged a feature branch on Friday and will open a new one on Monday. They are building, constantly, and they are invisible to the tools most recruiters depend on.

According to LinkedIn's own Talent Solutions research, 70-75% of the global workforce is passive, not actively seeking new employment. Among software engineers, the number skews even higher. Stack Overflow's Developer Survey data consistently shows that only 15-20% of developers are actively looking at any given time. The engineers with the most options are the least likely to be searching. They get recruited; they do not apply. This is the central challenge of technical sourcing in 2026, and it is getting harder, not easier.

The gap between where recruiters look and where passive engineers actually are has widened. The tools built for sourcing (job boards, LinkedIn Recruiter, ATS keyword searches) are optimized for people who want to be found. The engineers you most want to hire are not among them. Closing that gap requires a different kind of sourcing entirely, one built on behavioral signals rather than self-reported profiles.

What makes a software engineer a "passive candidate"?

The term "passive candidate" gets used loosely. The spectrum matters, because the sourcing strategy for each segment is different.

Actively looking (15-20% of engineers). These engineers are applying to jobs, updating their LinkedIn profiles, responding to recruiter messages, attending career fairs. They are the easiest to reach and the most competitive to close, because every other recruiter can reach them too. Job boards, LinkedIn InMails, and career pages are designed for this group.

Open to opportunities but not looking (45-50%). This is the prize. These engineers are employed, generally satisfied, but would consider the right opportunity if it found them. They are not searching. They are not updating profiles. They are not on job boards. But they would respond to a compelling, personalized outreach that demonstrates you understand what they do. According to AIHR's sourcing benchmarks, this segment represents the largest pool of potential hires and the one with the highest average quality.

Not interested at all (25-30%). These engineers are happy where they are, recently promoted, recently started, or simply not in a position to consider a move. No amount of outreach will move them right now. The key insight is that people move between these segments over time. The engineer who is not interested today may be open in six months after a reorg or a strategy shift at their current company.

The "open to opportunities" bucket is where technical recruiting creates the most value. These engineers will not find you through job postings or applications. They will respond to outreach that demonstrates genuine understanding of their work. They tend to be higher quality on average, not because passive status causes quality, but because they are employed, performing well enough to not need a new job, and building things that make them attractive. Active candidate pools include strong engineers in transition, but also a higher proportion of people who were let go or who struggle to stay employed. LinkedIn's Talent Solutions data indicates that passive hires are 120% more likely to want to make an impact and 56% less likely to need skill development compared to active hires.

Why traditional sourcing misses passive engineers

The tools most recruiters use were built for a world where candidates come to you. They work well for that world. The problem is that the candidates you most want to hire live in a different one.

LinkedIn depends on self-reported, actively-maintained profiles. A senior engineer who has been at the same company for three years often has a profile that is two years out of date. Wrong title, wrong tech stack, no recent activity, maybe a profile photo from 2019. LinkedIn's Boolean search returns profiles that match keywords. But the engineers who are too busy shipping features to update their summary section never appear in those results. When you search for "React" on LinkedIn, you find people who typed "React" into their profile. You do not find the engineer who has 200 commits to the React codebase but listed "Frontend Development" as their skill because they set up their profile in 2017 and never touched it again.

Job boards only reach active seekers by definition. Indeed, Glassdoor, and Wellfound are distribution channels for job postings. They are effective at reaching the 15-20% who are looking. They do not reach the 50% who would consider a move but are not searching. Posting a job and waiting for applications is a strategy for hiring active candidates. It is not a sourcing strategy for passive ones.

Referral networks are strong but limited. Employee referrals are the best source of quality hires. Referred candidates have higher acceptance rates, faster time-to-hire, and longer tenure. But referrals are bounded by who your current employees know, which is typically 100-300 engineers per person. If you are hiring for a niche technology (real-time collaboration, WASM runtimes, GPU compilers), the odds that someone on your team personally knows the right candidate are low. Referrals are a complement to sourcing, not a substitute.

This is the gap: the tools most recruiters use are optimized for people who are actively seeking employment, which is the opposite of who they want to hire. The contrast between LinkedIn's profile-based approach and contribution-based sourcing illustrates this disconnect clearly. LinkedIn tells you what someone says they can do. Contribution data tells you what they have actually done.

Where passive engineers actually leave signals

Passive engineers are not invisible. They are invisible to recruiting tools. In the places where they actually work, writing code, reviewing pull requests, filing issues, publishing packages, they leave a continuous trail of behavioral signals. These signals are richer than any profile because they are generated by doing the work, not by describing the work after the fact.

GitHub. This is the largest and most reliable signal source. With 120 million-plus developers and 30 million-plus events per month, GitHub captures an enormous breadth of engineering activity. Every commit, pull request, code review, and issue comment is a data point. Engineers who have not opened LinkedIn in two years may have pushed code yesterday. The signal quality is high because it is behavioral. You cannot fake a meaningful contribution to kubernetes/kubernetes or a substantive code review on a complex pull request. GitHub data tells you what someone works on, how frequently they contribute, whether they do code review or just push commits, and whether they contribute to projects beyond their employer's repos.

Open source contributions. Engineers who maintain or contribute to open source projects are visible through their work, not their marketing. Contributing to a popular repository (not a drive-by typo fix, but substantive feature work or bug fixes) is a strong quality signal. It tells you the engineer can work in an unfamiliar codebase, communicate through pull request descriptions, and get code past maintainers who have no professional obligation to accept it. Understanding the seniority signals embedded in contribution patterns makes this data even more useful for sourcing.

Conference talks and blog posts. Technical content creation signals expertise and intellectual engagement. An engineer who gives a talk at a conference about a specific technology has deep knowledge of it. A developer who writes detailed blog posts about debugging production issues demonstrates the kind of systems thinking that is difficult to assess from a resume. The limitation is that this only captures engineers who enjoy public speaking or writing, which is a subset. Many excellent engineers never write a blog post or submit a conference proposal.

Stack Overflow and technical communities. Active answerers in specific tags (e.g., [kubernetes], [rust], [webrtc]) often have deep domain expertise. Their answers are public, detailed, and demonstrate how they think through problems. But mining this data manually is time-consuming, and the overlap between "active on Stack Overflow" and "available to hire" is unclear.

Package registries. Engineers who publish and maintain packages on npm, PyPI, crates.io, or RubyGems are often senior. Publishing a well-adopted package requires coding skill, documentation, API design, versioning discipline, and responsiveness to issues. A package with 10,000 weekly downloads is a stronger credential than most resume bullets.

What all of these sources have in common: they are behavioral signals, things engineers do naturally as part of their work. The signal exists whether or not the engineer is looking for a job.

How to source passive engineers from GitHub

GitHub is the highest-signal source for passive engineering candidates. I think it is underused by most recruiting teams, partly because the manual process is tedious and partly because recruiters were never trained to read contribution data. Here is the tactical playbook for sourcing from it manually, followed by why manual sourcing breaks down at scale.

Step 1: Identify target repositories. Start with the technology you are hiring for and find the repositories that matter. If you need React experience: facebook/react, vercel/next.js, remix-run/remix, radix-ui/primitives, shadcn/ui. If you need Kubernetes expertise: kubernetes/kubernetes, helm/helm, istio/istio, argoproj/argo-cd. If you need real-time collaboration: yjs/yjs, automerge/automerge, ProseMirror/prosemirror, tiptap/tiptap. The specificity of your target repos determines the quality of your candidate pool. Broad repos (e.g., facebook/react) give you volume. Niche repos (e.g., ProseMirror/prosemirror) give you precision.

Step 2: Find contributors. Go to the repository's Contributors tab. These are people who have actually committed code to the project you care about. Not people who listed the technology as a skill on their profile. People who built it. Sort by recent contributions to prioritize currently active engineers. For larger repos, the top 50-100 contributors are usually a mix of core maintainers and significant external contributors. Both are worth evaluating.

Step 3: Evaluate contribution quality. Not all contributors are equal. A developer with 3 commits that fixed critical bugs in the query optimizer is a stronger signal than someone with 30 commits that updated documentation formatting. Look at: number and recency of commits, type of work (features, bug fixes, performance improvements vs. typo fixes and dependency bumps), quality of pull request descriptions, code review engagement (do they review others' code or only submit their own?), and whether their contributions were accepted or frequently rejected. Specific patterns in contribution history reliably indicate engineering seniority: breadth across repos, code review activity, and the complexity of accepted PRs.

Step 4: Check their profile. A GitHub profile tells you: current employer (company field), location, bio, personal website, pinned repositories, and contribution activity. Pinned repos reveal what the engineer considers their best work. The contribution graph shows consistency. A steady stream of activity is a different signal than a burst followed by months of silence. Are they at a company where they might be open to a move? Are they in a location or timezone that works for your team?

Step 5: Find contact information. GitHub profiles sometimes include an email address or Twitter/X handle. Some engineers link to personal websites with contact forms. Cross-referencing their GitHub username with LinkedIn can provide professional context and an InMail channel.

The problem with manual sourcing. This process works. It also takes 1-2 hours per candidate. Identifying target repos, browsing contributor lists, evaluating commit histories, checking profiles, and finding contact information is labor-intensive research. At the scale a recruiter needs — reviewing 50-100 candidates to find 10 worth reaching out to — manual GitHub sourcing requires 50-200 hours of work. For a single search. When you factor in the full cost per hire for software engineers, that labor cost often exceeds the price of tooling that automates it. That is why most recruiters who try GitHub sourcing do it for one or two searches and then abandon it. The signal quality is excellent. The time cost is prohibitive.

Scaling passive sourcing with contribution data

The manual process described above is what tools automate. The best developer sourcing tools take the same fundamental approach (analyzing contribution data to find engineers) and make it possible to do in minutes what would otherwise take days.

Tools like riem.ai automate the GitHub sourcing pipeline end to end. They scan 30 million-plus monthly GitHub events, score candidates by contribution quality and relevance to your search, rank results by match strength, and surface engineers you would never find manually. Instead of browsing contributor tabs on individual repos, you describe the engineer you need in natural language ("senior developer who has contributed to real-time collaboration tools like ProseMirror or Tiptap") and get ranked results based on actual contribution patterns.

The best output of contribution-based sourcing is what we call the "underrated" developer: engineers with high contribution quality but low social visibility. They have few GitHub followers. They do not have popular personal repos. They are not on Twitter. But they have been quietly shipping high-quality work to the repositories that matter for your search. These are the passive candidates that no other recruiter is reaching out to, because no other recruiter can find them. They do not appear in LinkedIn searches. They do not appear on any job board. They appear in contribution data.

The scoring behind this approach is multidimensional. A candidate who contributed directly to a target repository gets a higher relevance score than someone who contributed to a similar but different project. Recent activity scores higher than historical activity. Engineers who do code review in addition to writing code signal seniority. Contributors to multiple relevant repos show breadth. External contributions (to repos outside their employer's organization) show initiative. The combination of these signals produces a ranked list that maps closely to what a recruiter would conclude after hours of manual research, delivered in seconds.

How to write outreach that passive candidates respond to

Finding passive engineers is half the problem. Getting them to respond is the other half, and honestly, this is where most sourcing efforts fall apart. The approach to outreach for passive candidates is fundamentally different from messaging active job seekers, because the psychology is different. An active candidate wants a job. A passive candidate has a job. They do not need what you are offering. They need a reason to consider it.

Reference their actual work. This is the single highest-leverage change you can make to outreach. "I noticed your contributions to [repo], specifically the [feature/fix] you shipped in [month]" tells the engineer immediately that you are not sending a bulk template. It demonstrates that you know what they work on and that your opportunity is relevant to it. Generic outreach ("I came across your profile and thought you'd be a great fit") gets deleted. Specific outreach ("I saw your PR that refactored the query planner in [repo]. We are working on a similar challenge with our distributed query engine") gets read.

Keep it short. Under 150 words. Passive candidates are busy. They are the people who pushed code last week, remember. A three-paragraph email about your company's mission, culture, and benefits package will not get read. Lead with what is interesting about the technical problem, mention why their specific background is relevant, and ask a simple question. Two to three sentences of context, one ask.

Lead with the problem, not the company. Passive engineers are motivated by interesting technical challenges, not company pedigree. "We are building a distributed CRDT system that needs to handle 100K concurrent editors" is more compelling than "We are a Series B startup backed by [name-brand VC] that has raised $40M." The former describes a problem they might want to solve. The latter describes a company they have never heard of.

The numbers support specificity. According to recruiting industry benchmarks from Gem and Lever, generic cold outreach to developers gets a 4-8% response rate. Outreach that references specific code contributions gets 15-20%. That is a 2-4x improvement from a single change: making the message about their work instead of about your company. The engineers who respond to contribution-specific outreach are also more likely to convert through the interview process, because the match between their skills and your needs has already been validated by real data.

Do not ask them to apply. Passive candidates will not fill out an application form. They will not upload a resume. Ask if they would be open to a 15-minute conversation about what you are building. Remove every possible point of friction between reading your message and saying yes. The goal of the first outreach is not to hire them. It is to start a conversation.

Building a passive sourcing pipeline

The biggest mistake in passive sourcing is treating it as a one-time activity. You search when you have an open req. You stop when the req is filled. Six months later you start over from scratch. This is the equivalent of only networking when you need a job. It works, but it is dramatically less effective than maintaining relationships continuously.

Source before you need to hire. The best time to build a relationship with a passive candidate is before you have an open req. When you reach out with no urgency and no ask ("I noticed your work on [repo], wanted to connect because we work in a similar space"), the interaction feels collaborative rather than transactional. Six months later, when you do have an opening, you are not cold-emailing a stranger. You are following up with someone who already knows who you are.

Monitor contributions to repos in your stack. Set up a systematic process for tracking new contributors to the repositories that matter for your hiring pipeline. When a new engineer starts contributing substantively to a project in your tech stack, that is a sourcing signal. They are actively engaged with the technology you need. Tools that index GitHub events continuously make this monitoring possible without manual effort.

Maintain a watchlist. Create a list of 20-30 engineers you would love to hire, even if they are not available today. Check in quarterly. Follow their GitHub activity. When they change companies, start a new open source project, or show signs of decreased activity at their current employer, that is a signal that their receptiveness to outreach may have shifted.

Play the long game with warm leads. When a passive candidate responds positively but says "not right now," that is not a rejection. It is a timing issue. Stay in touch. Share something relevant to their work every few months: a blog post, a conference talk, a new open source project your team released. When the timing shifts on their end (a reorg, a funding change, a new manager they do not like), you want to be the recruiter they think of first. According to research from Lever, the average passive candidate takes 2-3 touchpoints over 3-6 months before engaging in a formal interview process.

Measure pipeline health, not just conversion. Track how many passive candidates are in your pipeline at each stage: identified, contacted, responded, in conversation, interviewing, offer. A healthy passive sourcing pipeline always has more candidates in the early stages than you need for current openings. If you only have candidates for positions that are open right now, you do not have a pipeline. You have a list.

The complete guide to recruiting from GitHub covers the tactical details of building this pipeline step by step, from identifying target repos to closing passive candidates.

Frequently asked questions

What percentage of software engineers are passive candidates?

According to LinkedIn Talent Solutions data, approximately 70-75% of the global workforce is passive, meaning they are not actively looking for a new job. Among software engineers specifically, the percentage tends to be even higher because demand for their skills gives them more options and less urgency to search. Stack Overflow's Developer Survey data consistently shows that only about 15-20% of developers are actively looking at any given time, with the remainder either passively open or not interested.

How do you find passive developers who aren't on LinkedIn?

The most reliable method is analyzing behavioral signals from platforms where developers are active regardless of their job search status. GitHub is the largest source, with 120M+ developers and 30M+ events per month. Every commit, pull request, code review, and issue comment is a public signal of what an engineer is working on and how they work. Tools like riem.ai automate this analysis, scanning GitHub contribution data to surface engineers based on actual code activity rather than self-reported profiles.

Do passive candidates make better hires?

Research suggests passive candidates tend to perform better on average. LinkedIn's own data indicates that passive candidates are 120% more likely to want to make an impact in their new role and 56% less likely to need skill development compared to active candidates. This is partly selection bias: passive candidates are currently employed and performing well enough to not need a new job. Active candidate pools include strong engineers in transition, but also a higher proportion of underperformers. The key difference is that passive hires tend to have longer tenure and higher satisfaction scores.

What response rate should I expect from passive developer outreach?

Generic cold outreach to passive developers typically gets a 4-8% response rate. Personalized outreach that references a candidate's specific technical work (a particular open source contribution, a feature they built, a code review pattern) achieves 15-20% response rates, according to recruiting industry benchmarks from Gem and Lever. The single biggest factor in response rate is specificity: engineers can immediately tell whether you actually looked at their work or sent a template.

Is it legal to source developers from GitHub?

Yes. GitHub profiles and contribution activity are public data that developers have chosen to make visible. Sourcing from public GitHub data is comparable to sourcing from public LinkedIn profiles, which is standard recruiting practice. Under GDPR, processing publicly available professional data for legitimate business interests (recruiting) is permitted under Article 6(1)(f). Best practice is to provide an opt-out mechanism and to only use the data for its intended professional purpose. Contacting developers through publicly listed email addresses on their GitHub profiles is standard practice.

How long does it take to hire a passive software engineer?

Hiring passive engineers typically takes longer than hiring active candidates. Expect 6-12 weeks from first outreach to accepted offer, compared to 3-6 weeks for active candidates. The additional time comes from the relationship-building phase: passive candidates need to be convinced to consider the opportunity before the formal interview process even begins. However, passive hires tend to have higher acceptance rates once they reach the offer stage, because they have already been thoroughly sold on the opportunity through the extended courtship process.