How to source software engineers on GitHub: a practical guide

GitHub has more than 100 million developer accounts, and a good share of the engineers you want to hire have left public traces of their work there. Unlike a CV, that work isn't self-reported: it's the code, the reviews and the discussions themselves. We explained why that matters in read the code, not the CV. This guide is the how: the method we used by hand before we automated it, step by step.

1. Describe what the person will build, not the title

"Senior backend engineer" is a title. GitHub doesn't index titles, it indexes code. So before searching, translate the role into what the person will actually build, and from there into signals you can find in a repository:

• The language and the ecosystem: Go, Rust, TypeScript, Python, and the main frameworks around them.
• The libraries: the dependencies your codebase relies on. Someone who has contributed to one of them knows it from the inside.
• The problem: a payments ledger, a real-time order book, a data pipeline, a design system. Problems show up in repository names, topics and READMEs.

Take "backend engineer for our payments API". In signals, that becomes: Go or Java, PostgreSQL, idempotency, double-entry ledgers, webhooks, maybe a payment provider's SDK. That list is your search, not the job title.

2. Search projects before people

The most common mistake is to start with GitHub's user search. It mostly matches names, logins and locations, which tells you very little. Start with the work instead.

Repository search finds the projects close to your problem. Combine qualifiers:

• topic:ledger language:go for projects tagged with the topic, in the right language;
• pushed:>2026-01-01 to keep only projects that are still alive;
• stars:10..500 to skip the giant projects where thousands contribute, and the empty ones.

Then, on each relevant project, look at the people:

• Insights, then Contributors: who has written the code, and how much of it.
• Pull requests: in the repository's search bar, is:pr is:merged lists merged contributions. A merged pull request on a project someone doesn't own is one of the strongest signals there is: another maintainer read the code and accepted it.
• Issues: the people who report precise bugs, with a reproduction, usually understand the internals.

The libraries you use are a goldmine. Open the repositories of the dependencies your team relies on and look at their contributors. These people already know part of your stack better than most candidates you will ever interview.

Dependents work the other way round. On a library's page, Insights then Dependency graph then Dependents lists the public projects that use it. It's a quick way to find teams and individuals building with the same tools as you.

3. Then narrow down with user search

Once you know what you're looking for, user search becomes useful to filter by place:

• type:user location:Paris language:go returns accounts that list Paris and whose repositories are mostly in Go;
• followers:>20 or repos:>10 remove most empty accounts.

Two limits to keep in mind. The location field is free text: "Paris", "Paris, France", "France" and "Île-de-France" are all different strings, so try several. And language is computed from the person's own repositories, not from what they contribute to elsewhere: a core contributor to a big Rust project may have no Rust repository of their own.

4. Read a profile in five minutes

Here is the order we read a profile in, to decide quickly whether someone is worth a closer look:

1. Pinned repositories: what the person chose to show. Open one, read the README, then a couple of files.
2. Contributions to other people's projects: search is:pr author:their-login -user:their-login is:merged. It lists the pull requests they got merged on repositories they don't own. This is where real collaboration shows.
3. Code reviews: reviewed-by:their-login shows the pull requests they reviewed. Reviewing well is a senior skill, and it's rarely visible anywhere else.
4. The code itself: tests, structure, commit messages that explain why and not only what. You don't need to be an engineer to notice whether a project has tests and a clear README.
5. Recency: the last few months of activity. A skill used last week says more than one listed in 2019.

Ignore forks with no commits of their own: they are bookmarks, not work.

5. Know what the profile doesn't tell you

Public code is evidence, not a full picture. Three traps:

• An empty profile proves nothing. Many excellent engineers spend their best years on private codebases, and many have no time or wish for side projects. Some show their private activity as anonymous squares on the contribution graph; most don't.
• Green squares can be gamed. A dense contribution graph can be made of tiny automated commits. Read what is behind it.
• Stars measure popularity, not skill. A well-marketed weekend project can have more stars than a rigorous library everyone depends on.

Use GitHub to find people you would otherwise miss and to start the conversation on something real. Keep your interviews for the rest.

6. Reach out the right way

GitHub is not a messaging platform, and engineers notice when they are treated as a list. A few rules:

• Use the contact the person chose to publish: the email on their profile, their personal website, or a professional address. Don't dig emails out of commits.
• Read GitHub's rules. Its Acceptable Use Policies forbid using information from the site for spam, including unsolicited emails. One personal message about someone's work is a different thing from a campaign, and it should stay that way.
• In Europe, the GDPR applies. Contacting someone for a job is usually done under legitimate interest: say where you found them, keep only what you need, and stop at the first "no".
• Open on their work. The project you found them through is the best first line you will ever have. We wrote a whole piece on it: the first email engineers answer.

7. Keep track, and know what it costs

Done properly, this takes time. Expect 15 to 30 minutes per good candidate between the project search, reading the profile and writing a message that isn't generic. For one role, that's a day or two to get a shortlist of twenty.

Keep a simple sheet per role: login, the project that brought you to them, what you noticed, the date of your message, the answer. After two or three roles, you'll know which searches work for your stack.

That day or two is exactly what Azerit automates. You describe the role in one sentence; it searches the projects and the contributions, ranks the engineers who have already built something close, shows the work behind each score, finds a professional email and drafts a first message about their own code. If you'd rather see it than do it by hand, try it on one of your roles.

Cheat sheet

• Projects on your problem: topic:<topic> language:<language> pushed:>2026-01-01
• Merged work in a repository: is:pr is:merged in that repository
• A person's merged work on other projects: is:pr author:<login> -user:<login> is:merged
• What a person reviews: reviewed-by:<login>
• People in a city: type:user location:<city> language:<language>
• Teams using a library: Insights, then Dependency graph, then Dependents