Start from the repositories, not from the people. Translate the job into the three to five open-source projects someone in that role would touch, then look at who has had pull requests merged into them recently. Use GitHub's user search, with qualifiers such as language: and location:, only to widen or narrow that list, because it matches what people wrote about themselves rather than what they built. A Google search restricted to github.com finds profiles GitHub's own search misses. Then read each profile before writing to anyone.
Step 1: turn the job description into repositories
A job description lists skills. GitHub is organised by projects. The translation is the whole craft: a "senior backend engineer, Python, event-driven, AWS" is someone who works on projects like Celery, FastAPI, boto3 or an open-source Kafka client, not someone who wrote "Python" in a bio.
To find those projects without being technical, search repositories rather than users. A
query such as topic:fastapi stars:>500 pushed:>2026-06-01 returns the
maintained projects of an ecosystem, most starred first. Keep the ones that are alive (recent
pushes, issues answered) and that match the job's level: a large framework for platform
roles, a focused library for specialist ones. Three to five is enough.
Step 2: pull the people who recently shipped
Every repository has a contributors page, under Insights, ranked by all-time commits. All-time is the trap: it surfaces people who built the project years ago and have moved on.
Recent merged pull requests tell you who is working on it now. In the repository's pull
requests tab, a search like is:pr is:merged merged:>2026-04-01 lists what
was accepted in the last months, and each one carries its author. A merged pull request is
work a maintainer reviewed and accepted, which is a stronger statement than any profile
field.
Step 3: search profiles to widen or narrow
GitHub's user search filters on what people put in their profile: their main language, their free-text location, their follower and repository counts, words in their bio. It is useful to widen a short list ("who else in Berlin writes Go?") or to narrow a long one, and the open-source GitHub sourcing guide keeps a copy-paste cheat sheet of the qualifiers.
Three things to keep in mind. Location is free text, so "Paris" misses "Paris, France" and
"Île-de-France"; search a few variants. language: is the main language of
someone's repositories, not of their job. And every query stops at 1,000 results without
warning you, so a broad search silently truncates.
Step 4: use Google to find what GitHub search misses
Google indexes a large share of public GitHub profiles, and searching it with
site:github.com, often called an X-ray search, reaches text that GitHub's user
search ignores, such as a profile README.
Start simple and add terms: site:github.com "Berlin" "Rust", then exclude the
pages that are not profiles with -inurl:issues -inurl:pull -inurl:blob -inurl:tree,
which removes code and discussions. Results are partial and can be months old, so treat them as
leads to open, not as a list.
Step 5: shortlist, then contact
Open every profile before writing. Recent activity, merged work in other people's projects and the languages in their own repositories matter more than stars or followers; our guide to reading a GitHub profile as a recruiter walks through them. Use only the contact details people chose to publish, as covered in how to find a developer's email on GitHub, and say in the first line what they built that made you write.
How long this takes, and where it stops
Done by hand, the method works and teaches you how an ecosystem is organised. It costs time: each profile is opened, read and qualified one by one, locations are normalised by eye, and the same person turns up across several repositories. In our own index, 54% of profiles pushed code in the last 90 days, which means a large part of any raw list is people who have since stopped.
That is the part StarHunt automates: the repositories per technology are already mapped, contributors are ranked on recent work, and locations are normalised to metro areas. The method above is still the right way to understand what the tool does.
Where this answer does not hold
This page is about finding people. It does not cover evaluating code in depth, which is the hiring team's job, or private work, which GitHub does not show and which is the majority of most engineers' output.
Frequently asked questions
Can you search GitHub users by location?
Yes, with location:"City" in the user search. The field is free text, so search a few spellings of the same place and expect to miss people who left it empty.
Why does GitHub search stop at 1,000 results?
GitHub Search returns at most 1,000 results for any query, and does not say when it truncated. Split a broad search by location or language to see more.
What is a GitHub X-ray search?
A Google search restricted to github.com, such as site:github.com "Berlin" "Rust". It finds profiles by text GitHub's own search ignores, with partial and sometimes outdated results.
Is it better to search people or repositories?
Repositories first. Contributors to the projects that define a technology are evidence of skill; a profile search only matches how people describe themselves.
Skip the manual part
Describe the role; StarHunt starts from the repositories and ranks who recently shipped.
Try StarHunt for free