GitHub is the closest thing to a portfolio that most engineers have, and it is badly misread by almost everyone sourcing from it. The green contribution squares are the most visible thing on a profile and among the least informative.
This guide covers what the signals actually mean, and how to search in a way that surfaces people other recruiters do not reach.
Set your baseline first
The single biggest mistake is assuming a strong developer has a busy profile. Across the largest skill populations in our index, the median developer has around 24 public repositories, 42 contributions in the last year, and 8 followers.
That is the middle of the market, not the bottom. If you are filtering for daily commits, you are excluding most working engineers — including a large share of the strongest ones, who write their best code in private repositories for their employer.
Medians also vary by population:
| Skill | Median contributions | Median repos | Median followers |
|---|---|---|---|
| JavaScript | 42 | 24 | 8 |
| Python | 44 | 22 | 8 |
| TypeScript | 69 | 27 | 9 |
| Java | 39 | 25 | 8 |
| C | 42 | 30 | 12 |
| Bash / Shell | 47 | 35 | 15 |
Sixty contributions is unremarkable for a TypeScript developer and well above median for a Java one. Always compare within the population, never across.
What each signal actually means
Contribution graph. Shows consistency, not quality, and only for public work. Someone with a sparse graph may be committing daily to a private monorepo. Read it for recency, not volume — activity in the last six months tells you they are still actively coding, which is the genuinely useful part.
Repository count. Weak on its own. Many accounts are inflated by forks and tutorial projects. Filter to original repositories with actual commits before this number means anything.
Followers. A reputation signal within a community, not across them. C and Bash developers show medians of 12 and 15 against 8 for JavaScript, reflecting smaller and more tightly networked communities rather than greater ability. Comparing follower counts across languages is meaningless.
Stars received. Popularity of a project, which correlates with marketing as much as engineering. A widely-starred tutorial repository says less than an unstarred library with careful tests.
Account age. A reasonable proxy for experience. created:<2018-01-01 is a rough filter for at least several years in the field, though plenty of senior engineers made accounts late.
Language breakdown. Derived from bytes of code, so a single large vendored file can skew it. Treat as a hint, then verify by opening a repository.
Reading a profile in two minutes
A workable routine that catches most of what matters:
- Sort repositories by recently updated. Ignore the pinned ones — those are curated, and you want the working reality.
- Open the most substantial recent repository that is not a fork.
- Read the README. Can they explain what the thing does and why? This is the closest free proxy for communication skill you will find.
- Look at the commit history. Meaningful messages or 200 commits titled "update"? Steady work or one weekend?
- Open two or three source files. You do not need to be an engineer for this. Is there structure? Are things named sensibly? Are there tests?
- Check issues and pull requests they have filed on other projects. How someone behaves in another maintainer's repository is the single best free signal about how they will behave on your team.
Step 6 is the one almost nobody does, and it is the most predictive. Public disagreement in an issue thread reveals more about collaboration than any interview question.
Search techniques that surface hidden people
Everyone runs language:python location:london. Here is what they do not.
Search contributor lists of libraries you depend on. Open the insights page of any dependency and read the contributor graph. These people already understand your problem domain and are almost never sourced.
Search by dependency rather than language. Finding repositories using a specific framework, then looking at who wrote them, identifies practitioners rather than people who once listed it.
Use created: ranges to defeat the result cap. GitHub caps user search at 1,000 results, so a broad query truncates silently. Splitting one search into several by account creation year gets you the whole market instead of an arbitrary slice.
Run every spelling of a location. location: is free text. "NYC", "New York", "New York City" and "Brooklyn" are four separate searches, and skipping three of them is how you miss most of a city.
Read the followers of engineers you already rate. People follow others working on similar things. One excellent candidate's follower list is a curated pool of similar people.
Look at who starred a niche repository. Anyone who starred a specialist library has at minimum evaluated it.
Where GitHub search runs out
Worth knowing the ceiling before you invest a week in it:
- The 1,000-result cap truncates without telling you.
- No recency filter. You cannot express "contributed in the last six months", which is the most useful filter in sourcing.
- No cross-source dedupe. The same person under multiple identities looks like several people.
- Location is unstructured and often empty.
- No contact information in results. You look each one up manually, at a few minutes each.
Our free sourcing guide covers workarounds. Past two or three concurrent roles the manual approach stops being the cheaper option, and our index covers the same public data with the activity and location filters GitHub search cannot express.
Contacting people you find on GitHub
Engineers are contacted constantly and have short patience for generic outreach. What works:
Name the specific repository and say what you noticed. The whole point of sourcing from GitHub is that you can see the work. Demonstrating you looked is the entire advantage — waste it and you are just another recruiter.
Do not compliment code you have not read. Engineers detect this instantly and it is worse than saying nothing.
Keep it short and include the salary range. Under 150 words, with a number.
Use their listed email, or the one in commit metadata. Both are public. Never add either to a bulk sequence.
Accept a no gracefully and ask for a referral. Engineers who are not looking frequently know someone who is, and referrals from respected engineers convert better than anything you will source cold.
To size a market before you start, the skill pages show developer counts by technology and the country pages break them down by location, both free to browse.