> Index of everything AyHire publishes for agents: https://ayhire.com/llms.txt # How to find engineers on GitHub (sourcing guide) https://ayhire.com/blog/find-engineers-on-github · 20 October 2026 · 4 min read · Walid Boulanouar > Search for the work, not the people: find engineers on GitHub through the repos they built, read a profile in ten minutes, and reach out without spam. The engineers you most want to hire have never sent you a CV. They have written code, and a lot of it is public. This guide shows how to find them on GitHub by hand, whether you are a recruiter on a technical search or a founder hiring your first engineers, and where the hand method runs out. ## Search for the work, not the people GitHub's people search matches what people write about themselves: a name, a bio, a location. Many strong engineers leave their bio empty. So searching people for "Rust" mostly finds people who typed "Rust" into their bio. Search for the work instead. Ask what the person you need would have built, or helped build, and find those projects first. The people come from the projects. ## Step 1: find the repos Use GitHub's repository search with qualifiers. These do most of the work: - `topic:key-value-store` finds repos their owners tagged with a topic. - `language:rust` keeps repos whose main language is Rust. - `stars:>200` drops toy projects. Stars are a rough sign that people use something, nothing more. - `pushed:>2026-07-01` keeps repos someone still works on. For a founding infra engineer who knows storage engines, a first search might be: ``` storage engine language:rust stars:>200 pushed:>2026-07-01 ``` Run three or four searches from different angles: the problem ("write-ahead log"), the tool ("rocksdb"), the category ("key-value store"). Write each one down. You will want to run them again in a month, and on an agency search, the next client with a similar role will need them too. ## Step 2: find who wrote the code The owner of a repo is often not the person who wrote most of it. Open the repo's contributors page (`github.com/OWNER/REPO/graphs/contributors`) to see who committed the most, and when. Look past the first name. The second and third contributors are often less known and easier to reach. Leave out bots, and people whose commits all stopped years ago, unless that history is what you need. Pull requests say more than commits. In a repo's pull requests, `is:pr is:merged author:USERNAME` shows what one person got merged, and `reviewed-by:USERNAME` shows whose code they reviewed. Someone who reviews other people's storage code usually knows storage code well. Pull requests are also where you can [assess AI fluency](/blog/ai-fluency-interview-github): whether someone checks what their coding agent wrote. ## Step 3: read a profile in ten minutes For each person, open their profile and look at four things: 1. **What they built.** Their pinned repos, and their biggest contributions to other people's projects. Does anyone use it? 2. **Whether they still ship.** The contribution graph and recent activity. A quiet year can mean a job with private repos, not a lack of skill. 3. **How they write.** READMEs that say what a repo does and how to run it. Commit messages and pull request descriptions that say what changed and why. 4. **Whether they might be open to work.** A bio or profile README that says so, a personal site, a recent change on LinkedIn. Keep the links as you go. When you write to someone, the specific commit or pull request is what makes your message worth reading. ## What public work can't tell you Be fair about the limits: - Most professional work happens in private repos. Missing evidence is not evidence of weakness. Ask about it on the call. - Stars measure attention, not skill. Some excellent engineers have none. - A profile says little about how someone works with a team. That is what the interview is for. - Where someone lives should never change how you read their work. ## Reaching out GitHub has no direct messages. Use the public email on a profile, a personal site or LinkedIn. Write one message per person: name the work you read, say why it matters for the role, and keep the ask small, such as a 20-minute call. If a profile says no recruiters, respect it. Never bulk-email people you found on GitHub. GitHub's Acceptable Use Policies forbid using information from GitHub to send unsolicited bulk email, and it doesn't work anyway. ## Where the hand method runs out Everything above works. It is also slow, which is what [GitHub recruiting tools](/blog/github-recruiting-tools) try to fix. One role can mean four searches, thirty repos, sixty profiles and a spreadsheet of links, and most of that time goes to reading, not deciding. If you are moving off Fetcher, which retired on 16 October 2026, our [Fetcher alternatives for engineering recruiting](/blog/fetcher-alternatives) compares six tools. Hiring for agent or LLM work? [How to hire AI engineers](/blog/hire-ai-engineers) applies this method to the projects AI engineers build. AyHire does the reading. You describe the role in one sentence. AyHire plans the searches and shows them to you before they run, finds the people who wrote most of the most-starred matching repos, and judges them against [the role's criteria](/guides/writing-criteria) from their public work, with a link behind every judgement. It checks who is open to work and tells you [who to talk to first](/blog/how-ayhire-decides), why, and what to check. It never contacts anyone for you: you send the intro yourself. [Start a 14-day free trial](/pricing), no card needed, and paste the job description you are working on. Or use AyHire from [Claude Code, Cursor or ChatGPT](/guide).