Your InMails Are Going to the Wrong Inbox
If you recruit engineers at any volume, you know the pattern. You buy the LinkedIn Recruiter seats, build careful boolean strings, write thoughtful InMails, and watch reply rates slide a little further every quarter. For senior engineers in competitive markets, silence is now the default response.
Your messaging isn't the problem. You're fishing where every other recruiter fishes, in a pond where the fish learned to ignore the bait years ago.
The developers you actually want are somewhere else: GitHub, where more than 100 million of them do their daily work. Not their polished career narrative. The work itself.
Most talent teams never source there, and it comes down to one sentence: "I'm not technical. I can't judge code."
You don't need to. You need to know what a handful of signals mean in plain English, and you need a workflow that doesn't eat your week. That's what this post covers.
Why GitHub Beats LinkedIn for Technical Sourcing
LinkedIn shows claims. GitHub shows evidence.
A LinkedIn profile is a self-authored marketing document. A GitHub profile is a byproduct of real work: every project, contribution, and code review is timestamped and public. Nobody can backfill three years of consistent activity the night before a job search.
That changes what you can know about a candidate before you ever speak to them:
| GitHub | ||
|---|---|---|
| Skills | Self-declared, unverified | Visible in actual projects |
| Activity | "Open to work" badge | Contribution history, updated daily |
| Seniority | Job titles (inflated or modest) | Scope and quality of real output |
| Competition | Every recruiter on earth | A fraction of your competitors |
| Passive talent | Ignores InMails | Reachable with specific, relevant outreach |
The best engineers barely exist on LinkedIn
Many senior developers keep a skeleton LinkedIn profile or none at all. They don't need one; opportunities find them through their work and their network. Those same people maintain active GitHub accounts, because that's where the work lives. If your sourcing starts and ends with LinkedIn, this entire tier of the market is invisible to you.
Less noise, better replies
Developers get far less recruiter traffic through GitHub-sourced channels than through InMail. And when your message references a specific project someone built, it reads as research, not spam. Recruiters who source from GitHub consistently report better reply rates for a simple reason: the message proves you looked.
"But I Can't Read Code"
You're not evaluating code. You're evaluating evidence of professional behavior, which is what recruiters do all day.
Five signals tell you most of what you need. None of them require programming knowledge.
1. The contribution graph (the green squares)
Every profile shows a year of activity as a grid of green squares. You're looking for consistency, not intensity. Regular activity over months signals an engaged, working developer. A blank graph isn't disqualifying, since plenty of great engineers work in private company repositories, but a dense one is a strong positive.
2. Recency
When did they last push code? Someone active this month is currently engaged with their craft. A profile that's been dormant for two years may belong to someone who moved on, changed careers, or went fully private.
3. Original projects vs. tutorial copies
Scan their repository names and descriptions. To-do apps, "my-first-portfolio," and tutorial follow-alongs are learning artifacts. A repository that solves a specific problem, with a written description and documentation, signals real capability. You can judge this from titles and READMEs alone.
4. Community signals
Stars are endorsements from strangers who found the work useful enough to bookmark. A repository with 100+ stars, or a profile with 50+ followers, carries community-validated credibility.
5. How they write
Open any of their projects and read the README or a few commit messages. Clear writing predicts clear communication in a distributed team, and you're better qualified to judge writing than most engineers are.
Want to go deeper? How to Find Top Developers on GitHub covers search operators, evaluation checklists, and outreach templates in detail. For the signals most recruiters miss entirely, see Underrated Developer Traits.
The Catch: Manual GitHub Sourcing Doesn't Scale
Now the bad news. Doing this by hand is slow.
GitHub's search was built for finding code, not people. Sourcing manually means learning query syntax (language:python location:"Kuala Lumpur" followers:>50), running dozens of variations because developers write locations inconsistently ("KL", "Kuala Lumpur", "Malaysia"), then opening every profile and evaluating it one by one.
The math for a hiring team:
| Task | Time |
|---|---|
| Learning search syntax and building queries | Hours, once |
| Reviewing one profile properly | 5-10 minutes |
| Building a shortlist of 25 qualified candidates | A full working day, per role |
Hiring one engineer? Maybe acceptable. Filling 15 engineering roles a quarter across three offices? A non-starter. This is exactly where most TA teams bounce off GitHub and retreat to InMail.
The Fast Path: A Ranked Shortlist in Under Five Minutes
This is the problem GitHunt was built to solve. It runs the whole manual workflow above (search, location matching, activity analysis, tech stack scoring, ranking) automatically, and hands you the result the way a recruiter needs it: a ranked shortlist.
Step 1: Describe the role (30 seconds)
Go to githunt.ai and pick a role and location from the dropdowns. No boolean strings, no syntax. Have a job description? Paste it, and GitHunt's AI extracts the role, skills, and location for you.
Step 2: Get ranked results (about a minute)
GitHunt searches GitHub, reconciles location variants, filters out inactive accounts and tutorial-only profiles, and scores every candidate on tech stack match, activity, and repository quality. You get a ranked list, best matches first, with the signals from this article already evaluated for you.
See it with a live search:
Each link runs a real search, right now.
Step 3: Generate an AI report for the shortlist (2-3 minutes)
For the role you're actively filling, generate an AI report: a deep-dive on the top candidates covering tech stack, activity, and contact information where it's publicly available. A free account includes one AI report per month, so you can test the workflow on a real vacancy before spending anything. See pricing for team plans.
Step 4: Vet individual candidates (1 minute each)
Got an inbound applicant or a referral with a GitHub link? Paste the username into the profile analyzer for an instant plain-English assessment: strengths, activity level, seniority signals, best-fit roles. You can check three profiles a day without creating an account.
That's the whole loop. Job description to evidence-backed shortlist in minutes, repeatable across every role on your req list.
Outreach: What to Do With Your Shortlist
GitHub sourcing gives you an edge at the outreach stage, because you know what each candidate has actually built. Use it.
The rule: reference their work, specifically, in the first two sentences.
Weak (this is every InMail they ignore):
"I came across your profile and was impressed by your background. We have an exciting opportunity..."
Strong:
"Your event-streaming library caught my attention. We process similar volumes at [Company] and are hiring a backend engineer in London to own that layer. Worth a 20-minute chat?"
The second message took one extra minute, because the shortlist already told you what they built. That minute is the difference between being deleted and getting a reply.
Three etiquette rules for GitHub-sourced outreach:
- Contact them off-platform. Use the email on their profile or cross-reference to LinkedIn. Never open a GitHub issue on someone's repository to pitch a job.
- One thoughtful message beats three follow-ups. Developers talk to each other, and spammy recruiters get screenshot.
- Be upfront about role, location, and range. Engineers respond to specifics.
Frequently Asked Questions
Is it okay to recruit people from GitHub? Yes. GitHub profiles are public professional portfolios, published in the knowledge that they're visible. What matters is how you reach out: use the channels they expose (profile email, linked website, LinkedIn), keep it relevant, and take no for an answer. Under GDPR, sourcing from public professional data for recruitment is generally recognized as a legitimate interest, but be transparent about where you found them and honor deletion requests.
Do I need a GitHub account to source there? Not to browse public profiles. GitHunt doesn't require one either; it works from your role and location requirements directly.
How do I contact a developer who lists no email? Check their profile for a personal website or linked socials, or cross-reference their name on LinkedIn. GitHunt's AI reports include publicly available contact information where it exists, which removes most of this legwork.
What if a great candidate has an empty GitHub profile? It happens. Plenty of strong engineers work entirely in private repositories, so an empty profile is never negative evidence. GitHub sourcing is a channel for finding people you'd otherwise never see, not a filter for rejecting the ones you already have.
The Bottom Line
LinkedIn Recruiter isn't going away, and it shouldn't. But if it's your only sourcing channel for engineers, you're competing with every other recruiter for the same visible slice of the market, using messages most senior developers have trained themselves to ignore.
GitHub is where the evidence lives. You don't need to be an engineer to use it. You need five plain-English signals and a tool that does the heavy lifting.
The fastest way to see it: run a search for a role you're hiring right now, and have a ranked shortlist before your next meeting starts.