ConnectDevs

Tag: GitHub sourcing

  • X-Ray Search for Recruiters: Google Strings That Still Work in 2026

    X-Ray Search for Recruiters: Google Strings That Still Work in 2026

    X-Ray Search for Recruiters: Google Strings That Still Work in 2026

    X-ray search for recruiters means using Google’s site: operator to search inside LinkedIn, GitHub, Stack Overflow and other sites from outside their own search boxes. For years it was the cheapest way to find passive candidates. Since early 2024 it has been less reliable on LinkedIn, but it still works well on developer sites.

    This guide gives you copy-paste strings, explains what changed, lists the mistakes that return empty results and shows when it is time to stop typing operators and use AI sourcing instead.

    TL;DR

    • X-ray search is a Google query pattern: site: plus quoted keywords, a location and exclusions.
    • It works best on GitHub and Stack Overflow. On LinkedIn it returns thinner results than it did before 2024.
    • Most failures come from small syntax errors: a space after site:, a lowercase OR or missing parentheses.
    • X-ray finds names, not contact details or outreach. Plan for a separate enrichment and outreach step.
    • Switch to AI sourcing when you run the same search across several platforms every week.

    Table of Contents

    What is X-ray search?

    X-ray search is a way to search a specific website through Google by adding the site: operator to a query. Instead of using LinkedIn’s search, you ask Google to return only pages from linkedin.com/in that match your keywords. The same idea works for GitHub profiles, Stack Overflow user pages, university sites and public PDF resumes.

    It is a form of Boolean search. If you need a refresher on operators like AND, OR and NOT, start with our guide to Boolean search for recruiters. X-ray adds one idea on top: the site restriction.

    The basic formula is:

    site:[domain or path] "keyword 1" "keyword 2" "location" -exclusion

    Google operators recruiters use

    Google’s own search help page documents fewer operators than recruiters use in practice, so test each string before you rely on it. These are the ones that matter:

    Operator What it does Example
    site: Limits results to a domain or path site:github.com
    " " Matches an exact phrase "machine learning"
    OR Matches either term (use capitals) ("Django" OR "FastAPI")
    - Excludes a term -jobs -directory
    intitle: Term must appear in the page title -intitle:repositories
    inurl: Term must appear in the URL -inurl:status
    filetype: Finds a file type such as PDF filetype:pdf "resume"
    * Wildcard for a missing word "senior * engineer"

    Some old operators no longer work. Pin’s X-ray search guide reports that Google retired related: in 2023 and cache: in 2024. If a string copied from an old blog post returns nothing, an outdated operator is a likely cause.

    Copy-paste X-ray strings

    Swap the bracketed parts for your own role, skills and location. These patterns are adapted from the examples in Pin’s guide and 100Hires’ LinkedIn X-ray guide.

    GitHub: developers by skill and city

    site:github.com "Python" ("Django" OR "FastAPI") "Berlin" -intitle:repositories

    The -intitle:repositories exclusion removes repository listing pages, so you see more user profiles. Our full walkthrough on finding passive candidates beyond LinkedIn covers what to do once you land on a profile.

    Stack Overflow: people who answer questions in your stack

    site:stackoverflow.com/users "java" "toronto"

    User pages show the topics someone answers about, which is useful evidence of depth in a specific technology.

    LinkedIn: public profiles (reduced results)

    site:linkedin.com/in ("software engineer" OR "backend engineer") "austin" -jobs -directory

    Expect fewer and less complete results than the same search in LinkedIn Recruiter. More on why below.

    Public resumes: PDF files

    filetype:pdf "software engineer" "Python" "Chicago" -jobs -template -sample

    The exclusions remove job ads and resume templates. Resumes found this way can be years old, so check the candidate’s current role before you reach out.

    University project pages

    site:*.edu filetype:pdf "resume" "computer science" "machine learning"

    Useful for early-career roles and research-heavy teams.

    How to build your own string in five steps

    1. Pick the platform. Choose where your candidates leave public evidence. Engineers leave code on GitHub and answers on Stack Overflow. Designers and marketers are more likely to appear on portfolio sites.
    2. List the title variants. Candidates write “Software Engineer”, “SDE” or “Backend Developer”. Put the variants in one parenthesis group joined with OR.
    3. Add two or three skills. Use the terms a candidate would write on their own profile, not the wording from your job post.
    4. Add a location. A city name filters well. For remote roles, leave it out and filter later.
    5. Exclude noise. Add -jobs, -intern or -recruiter one at a time and check the results after each change.

    Why LinkedIn X-ray got worse

    Sourcing experts documented a change in early 2024: Google began indexing fewer fields from public LinkedIn profiles. According to Pin’s guide, Google can no longer see work history, education, skills or most location data on many profiles. A search that once matched a skill in the middle of a profile now only matches the headline and a few visible fields.

    Public profiles can also take weeks or months to refresh in search engines, so a title you see in Google may be out of date. LinkedIn also does not publish a feed of changes for Google to follow. Treat every X-ray result as a lead to check, not as a confirmed current profile.

    If you also pay for LinkedIn Recruiter, see our comparison of LinkedIn Recruiter alternatives for cheaper options.

    Common mistakes that return empty results

    • A space after the colon. site: github.com breaks the operator. Write site:github.com.
    • Lowercase OR. Use OR in capitals.
    • Missing parentheses. Without them, OR can scramble the logic of the whole query.
    • Job-post language. “Seeking an experienced engineer” is not how people describe themselves. Search for the terms they actually write.
    • Too many exclusions. Each minus term can hide real candidates. Add them gradually.
    • Typos in the path. linkedin.com/il returns nothing. The profile path is /in.

    Long strings can also be cut short. 100Hires reports that Bing limits queries to 10 terms, so the end of a long string may be ignored. Keep strings short and test in Google first.

    Limits and compliance

    X-ray search is useful, but it has real limits:

    • Exact-match dependence. It misses people who describe the same skill in different words.
    • One platform at a time. You run, review and de-duplicate each site’s results by hand.
    • Partial coverage. Pin’s own index analysis, a vendor figure, suggests fewer than 13% of software engineering profiles have a public GitHub. Many strong engineers never appear in a GitHub X-ray.
    • No contact data and no workflow. You get a name and a link. Email lookup, outreach and tracking are manual. Read our guide on recruiter outreach response rates before you start messaging.

    Public does not mean free to use however you like. Check the terms of each platform you search, and follow privacy rules such as GDPR if you store candidate data. Ask your legal or compliance contact before you build a database from scraped results.

    X-ray search vs Boolean search vs AI sourcing

    X-ray search Boolean in a sourcing tool AI sourcing
    Where you search Google, one site at a time Inside one platform Across a profile database
    How you query Operators and exact phrases Operators and filters Plain-language criteria
    Handles synonyms Only if you list them Only if you list them Usually, by design
    Contact data No Sometimes Often through enrichment
    Cost Free Tool subscription Tool subscription
    Best for Niche, one-off searches Precise control Repeat searches at volume

    For a deeper look at the trade-off, read our comparison of Boolean search vs natural language search.

    When to switch from X-ray to AI sourcing

    Keep X-ray in your toolkit for rare skills and quick checks. Move to an AI sourcing tool when:

    • you repeat similar searches every week for different roles;
    • you spend more time cleaning results than contacting people;
    • you need email addresses and a place to track replies; or
    • your candidates are not on GitHub or Stack Overflow.

    ConnectDevs Scout searches a published 800M+ public-profile graph and returns ranked evidence for recruiter review. Missing emails can be filled in with candidate enrichment. Plans start free, with paid tiers listed on the pricing page. You still review every shortlist yourself.

    FAQ

    What is X-ray search in recruiting?

    X-ray search is a Google search that uses the site: operator to find profiles on one website, such as GitHub or LinkedIn, using keywords, locations and exclusions.

    Does LinkedIn X-ray search still work in 2026?

    It still returns some public profiles, but results are thinner than before 2024 because Google indexes fewer profile fields. Use it for leads and verify them.

    Is X-ray search free?

    Yes. Google search costs nothing. Your costs are time and the tools you need for email lookup and outreach.

    Is X-ray search against LinkedIn’s rules?

    Searching Google for public pages is different from scraping LinkedIn. Automating collection or copying profile data at scale can breach platform terms and privacy law. Check the current terms and ask your legal team.

    Why did my X-ray search stop working?

    The usual causes are a retired operator, a syntax error such as a space after site:, too many exclusions, or Google’s reduced LinkedIn indexing.

    Can AI write X-ray search strings?

    Yes, a chat assistant can draft strings quickly. Test each one, because assistants sometimes use retired operators or break the parentheses.

    Conclusion

    X-ray search is still worth learning. It costs nothing, it works well on GitHub and Stack Overflow, and it teaches you how candidates describe themselves. Use it for narrow, one-off searches, and accept that LinkedIn results are now partial. When the same work repeats weekly, a tool that searches intent instead of exact strings will save you the hours.

    Tired of rebuilding strings for every role? Explore AI candidate sourcing and run your next search on a live role.

  • How to Source Developers on GitHub: A Recruiter’s Step-by-Step Guide

    How to Source Developers on GitHub: A Recruiter’s Step-by-Step Guide

    How to Source Developers on GitHub: A Recruiter’s Step-by-Step Guide

    Knowing how to source developers on GitHub gives you a pool of engineers who are not answering recruiter messages on LinkedIn. It also gives you proof of work, which a resume never will. The catch is that GitHub is built for code, not hiring. You need the right search qualifiers, a way to read profiles without writing code, and clear rules on what you can and cannot do with the data.

    This guide covers all three. It goes deeper than our overview of how to find passive candidates beyond LinkedIn, which only touches GitHub briefly.

    TL;DR

    • Search GitHub for repositories first, then find the people behind them. It beats searching profiles alone.
    • Stack qualifiers such as language:, location:, followers: and repos: to cut thousands of profiles to a shortlist.
    • Judge a developer on recent, relevant, collaborative work. Raw star counts and green squares mislead.
    • GitHub’s Acceptable Use Policies bar using its data for spam, and GDPR adds duties when you contact people. Personalize every message and keep it low-volume.
    • AI sourcing helps with discovery and ranking. A human still has to read the work and write the message.

    Table of Contents

    Why GitHub works for developer sourcing

    GitHub sourcing means finding developers through their public code, contributions and collaboration instead of their job-board profile. You see what they build, how they talk to other engineers, and what they care about.

    The pool is huge. GitHub’s Octoverse 2025 report says the platform passed 180 million developers and 630 million repositories. It also reports TypeScript overtook Python as the most used language in August 2025.

    Size creates its own problem. Most accounts are not candidates, and most profiles are thin. Your job is to filter hard and read closely.

    Who you will and will not find

    GitHub skews toward open-source contributors, front-end and back-end engineers, infrastructure and data people. Engineers who work mostly in private company repos look quiet here. Many strong developers have almost nothing public.

    So treat GitHub as one channel. A thin profile is not a negative signal.

    Step 1: Search with GitHub qualifiers

    Search qualifiers are keywords such as language: or location: that filter GitHub results to match specific criteria. Use them in the GitHub search bar, then switch the result type to Users or Repositories.

    These user qualifiers come from GitHub’s documentation on searching users:

    Qualifier What it does Example
    type:user Personal accounts only, no organizations type:user
    language: Matches the languages used in the person’s repositories language:javascript location:russia
    location: Matches the location in the profile repos:1 location:iceland
    followers: Filters by follower count followers:>=1000
    repos: Filters by number of repositories repos:10..30
    created: Filters by account creation date created:<2011-01-01
    in:name / fullname: Finds a person by name fullname:nat friedman
    in:email Searches public email addresses data in:email

    Combine them. A starting query for a Go engineer in Berlin could look like this:

    language:go location:berlin followers:>20 repos:>5 type:user

    Limits you should know

    • Location is free text. People write “Berlin”, “Berlin, Germany” or “DE”. Run several variants.
    • Email search is restricted. GitHub states that for privacy reasons you cannot search by email domain name.
    • Results are capped. The search API documentation says it returns up to 1,000 results per search. Narrow your query instead of paging forever.
    • Followers are a weak proxy. A senior infrastructure engineer may have 12 followers and a brilliant career.

    Step 2: Start from repositories, not profiles

    Repository-first sourcing means searching for projects that match your tech stack, then reviewing the people who maintain and contribute to them. It finds stronger candidates than profile search, because the work is the filter.

    Repository qualifiers, per GitHub’s repository search docs:

    Qualifier Use it to Example
    topic: Find projects tagged with a technology or domain topic:kubernetes
    language: Limit to one language language:rust
    stars: Filter by popularity stars:10..500
    pushed: Keep only recently active projects pushed:>2026-01-01
    archived: Drop dead projects archived:false
    forks: Spot projects others build on forks:>=5
    good-first-issues: Find projects welcoming new contributors good-first-issues:>2 javascript

    A practical query: topic:kubernetes language:go stars:10..500 pushed:>2026-01-01 archived:false. Update the date to within the last six months when you run it.

    From a repository to candidates

    1. Open a promising repo and check the Contributors list on the right.
    2. Skim the Pull requests tab for merged work by people outside the core team.
    3. Look at who reviews code. Reviewers are often your senior hires.
    4. Open each candidate profile and run the checks in the next step.

    Mid-popularity projects work best. Famous projects attract recruiters from everywhere. A repo with 200 stars and three active maintainers is far less crowded.

    Step 3: Read a profile without coding skill

    Reading a GitHub profile means checking whether someone’s recent public work matches your role, using signals you can judge without reading code. You are not grading syntax. You are looking for fit, activity and collaboration.

    Signals worth trusting

    • Recent, relevant activity. Work in your stack within the past year.
    • Merged pull requests to other people’s projects. It shows they can work inside a team’s standards.
    • Clear README files. Good documentation often tracks good communication.
    • Tone in issues and reviews. Read a few comments. Are they patient, specific and useful?
    • Ownership. Maintaining a project over time beats ten abandoned weekend experiments.

    Signals that mislead

    • The contribution graph. GitHub says that by default the graph shows only public-repository activity, and commits count only if the author email is connected to the account. A quiet graph can mean private work.
    • Star counts. A starred repo can be a tutorial clone or a viral side project.
    • Forks. A forked repo with no changes is just a bookmark.
    • Commit volume. Quantity says nothing about quality or difficulty.

    A two-minute profile checklist

    1. Read the bio, location and linked site.
    2. Check pinned repositories. They show what the person wants you to see.
    3. Open one pinned repo and read the README.
    4. Scan recent activity for your target stack.
    5. Check for contributions to other projects, not only their own.
    6. Decide: reach out, save for later, or skip.

    If you cannot judge technical depth, bring in an engineer for ten minutes on your top five. Our guide to reducing time to hire for technical roles shows where that review fits in the wider process.

    Step 4: Find a legitimate way to reach out

    The cleanest way to contact a GitHub developer is through details they chose to make public, such as a profile email, a personal website, or a linked social account. Do not guess, scrape or reverse-engineer private addresses.

    Be careful with commit emails. GitHub lets users keep their email private and assigns a noreply address for web-based operations, so many commits will show no usable address. Older commits may still carry a real address, and that does not mean the person wants recruiter email there.

    Better options, in order:

    1. A public email on the profile.
    2. A contact link on their personal site or blog.
    3. A public social handle listed on the profile.
    4. A thoughtful comment on a project, only when it is relevant and non-promotional.

    That last one deserves a warning. Use it rarely. GitHub’s policies restrict advertising in other users’ accounts, as covered below.

    Sourcing on GitHub is allowed, but GitHub’s Acceptable Use Policies restrict how you use its data, and privacy law adds duties once you hold a person’s details. This is not legal advice. Check current terms and ask counsel for your situation.

    What GitHub’s policies say

    The GitHub Acceptable Use Policies include these points relevant to recruiters:

    • Scraping. The policy defines scraping as extracting information via an automated process such as a bot or webcrawler, and it limits what you may do with scraped data. Use the official search and API instead, and respect rate limits. GitHub’s docs list 30 authenticated search requests per minute for most endpoints.
    • Spam. You may not use information from the service for spamming purposes, including sending unsolicited emails to users or selling personal information.
    • Privacy. Personal information you collect may only be used for the purpose the user authorized, in line with GitHub’s Privacy Statement.
    • Advertising. You may not advertise in other users’ accounts, such as by posting excessive bulk content in issues.

    The practical reading: personal, relevant, low-volume outreach sits on the safer side. Mass-mailing a harvested list is the behavior the policy targets. Read the full policy yourself, because wording changes.

    GDPR and privacy law

    If you source candidates in the EU or UK, privacy law applies even to public data. Article 14 of the GDPR covers personal data not obtained from the person directly. It requires you to tell them who you are, why you hold their data, the legal basis and their rights. You must do this within a reasonable period and at the latest within one month, or at the time of first communication if you contact them.

    That has simple workflow consequences:

    • Put a short privacy notice or link in your first message.
    • Collect only what you need for the role.
    • Delete data on request and when it is no longer needed.
    • Record where each candidate came from.

    Ethics beyond the law

    Developers talk. A bad recruiter message gets screenshotted. Do not use someone’s open-source work as a hook if you did not read it. Do not reference private details. Do not email people ten times.

    Step 5: Outreach angles that get replies

    The best GitHub outreach cites one specific piece of work and explains why it matters to the role. Generic flattery gets deleted.

    Four angles that work

    1. The specific contribution. “Your pull request adding retry logic to the queue client is close to a problem our team is solving.”
    2. The technical problem. Lead with the hard problem, then the company.
    3. The stack match. Name the exact tools they use, not a keyword list.
    4. The honest context. State level, location, pay range if allowed, and remote policy upfront.

    Message rules

    • Keep it under 120 words.
    • Mention one real detail from their work.
    • Ask a small question, not for a call.
    • Offer an easy opt-out.
    • Follow up once, then stop.

    For more on getting replies, see our breakdown of LinkedIn Recruiter alternatives in 2026, which compares channels beyond InMail.

    Where AI sourcing helps

    AI sourcing tools search large public-profile datasets with natural-language queries, then rank matches so you review fewer, better candidates. They help most where manual GitHub work is slowest.

    Task Manual on GitHub Where AI helps
    Finding candidates Stack qualifiers, test variants, repeat Describe the role in plain language and get ranked matches
    Profile review Open dozens of tabs Summaries of relevant work
    Contact details Hunt through sites and profiles Enrichment of public data
    Outreach Copy, paste, track Sequenced follow-ups with tracking
    Judging quality Needs human judgment Still needs you

    ConnectDevs approaches this in three parts. AI candidate sourcing (Scout) runs natural-language search over a published graph of 800M+ public profiles and returns ranked matches with reasoning. Candidate enrichment fills in contact and profile data. Pilot runs multi-touch outreach from your own Gmail. None of it replaces an ATS, and none of it replaces reading the candidate’s work.

    For a realistic view of what automation covers, read what AI recruiting agents actually automate, and what still needs a human. If you are comparing tools, our SeekOut alternatives in 2026 roundup is a good next stop.

    FAQ

    Is it legal to source developers on GitHub?

    Yes, viewing public profiles is allowed. The limits are on how you use the data. GitHub’s Acceptable Use Policies bar spamming and unsolicited bulk email using its data, and GDPR applies if you hold EU or UK personal data. Ask counsel about your case.

    Can I scrape GitHub for developer emails?

    You should not. GitHub’s policies restrict using information from the service for spam and limit scraping. Use the official search, respect rate limits, and only contact people through details they made public.

    How do I find developers on GitHub by location?

    Search with the location: qualifier, for example language:python location:london type:user. Location is free text, so test spelling variants and nearby cities.

    How do I judge a developer on GitHub if I cannot code?

    Check recent activity in your stack, merged pull requests to other projects, README quality and tone in issues. Ignore stars and commit counts. Ask an engineer to review your shortlist.

    Does a quiet GitHub profile mean a weak developer?

    No. The contribution graph shows only public-repository activity by default, and many engineers work in private repos. Treat a quiet profile as unknown, not negative.

    Do I need a paid tool to source developers on GitHub?

    No. Free GitHub search handles everything in this guide. Paid and AI tools save time at scale, but the method works without them.

    Conclusion

    To source developers on GitHub well, search repositories first, filter people with qualifiers, read recent collaborative work, and reach out through public channels with one specific, honest message. Stay inside GitHub’s policies and privacy law, and keep volume low.

    The manual method works, but it is slow. That is where AI sourcing earns its place: discovery and ranking at speed, with your judgment on the final call. To see how this fits a fuller process, read our guide to screening high-volume job applicants next.

    Ready to find developers faster? Start sourcing candidates with AI candidate sourcing and describe your ideal engineer in plain language.