Stars Cost $0.03. A Merged PR Doesn't. Verify Engineers in 10 Minutes

Your AI sourcing tool hands you a shortlist of engineers before lunch, and you spend the afternoon working out which of them can actually do what their profiles say. In TestGorilla's August 2026 survey (covered by HR Dive on Oct 16, with the Business Wire release on Oct 19), more than 2 in 3 US recruiters said they spend an hour or more checking a candidate's credentials by hand. This post shows how to get that down to about 10 minutes for engineers. It covers which open-web signals are hard to fake, which are noise, and how to write a one-line proof a hiring manager will accept.

Why did AI make sourcing faster but not more trustworthy?

AI tools made finding candidates faster, but they also made profiles look more alike. The slow part of sourcing is now checking people, not finding them. TestGorilla surveyed 1,428 US talent pros. 72% said AI made sourcing faster over the past year, but a third of that group saw no gain in confidence that they'd found the right person, and 18% said their confidence fell.

TestGorilla CEO Wouter Durville named the cause: "Recruiters got a better search engine and a worse index in the same 12 months." AI-written profiles read alike. Every backend engineer is "passionate about scalable distributed systems," and every candidate lists the same tools. The search got sharper while the text it searches got blurrier.

Here is what that costs:

• More than 2 in 3 recruiters spend an hour or more checking a candidate's credentials.
• 30% spend two hours or more.
• 57% named verifying resume skills as a top-three sourcing challenge. It still ranks first, as it did in TestGorilla's 2025 report.
• In a UK follow-up of 483 respondents, 87% said candidates whose profiles claimed AI skills had, at least sometimes, shown weaker skills at interview than the profile suggested.

2 in 3

Skills verification stayed at number one through a full year of AI adoption. Better search can't fix that, because the problem was never finding a candidate. The problem is that claims cost nothing to make.

Which GitHub signals are cheap to fake?

Anything that sits on the candidate's own profile is cheap to fake. That covers stars, the contribution graph, skill tags, and even issues and pull requests on their own repositories. These are usually the first things a recruiter looks at, and they are the least reliable.

Stars. A star is a one-click bookmark that any GitHub account can give any repository. The StarScout study by Hao He, Bogdan Vasilescu, and Christian Kästner (Carnegie Mellon, with NC State and Socket, ICSE 2026) found about six million suspected fake stars across 18,617 repositories, from roughly 301,000 accounts, between 2019 and 2024. At the July 2024 peak, 16.66% of repositories that gained at least 50 stars that month were linked to suspected fake-star campaigns. Star farms (paid services that sell stars from bot or low-quality accounts) charge $0.03 to $0.90 per star depending on account quality, according to one tool's README.

The contribution graph. The green-square activity graph is built from commit timestamps, and the commit author sets those timestamps. Open-source scripts use the GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables to backdate a year of commits. One generator, Shpota/github-activity-generator, has 3.7K stars of its own.

Issues and PRs on your own repo. One paid-star vendor's public packages list up to 6,000 stars, 600 forks, 400 watchers, and 60 issues and pull requests as campaign deliverables. When the candidate owns the repo, they also decide what gets opened and merged.

Skill tags. A skill tag is a self-reported label on a profile. Nobody checks it.

The inflation is worst in AI. AI and LLM repositories received 177,000 fake stars in the StarScout data, and AI skills were the claims UK recruiters saw fall short at interview.

What is the one question that separates real signals from noise?

Ask "Who other than the candidate approved this?" If the answer is nobody, the signal is weak. If a stranger with no stake in the candidate's job search had to review and accept the work, the signal is strong.

A merged pull request into someone else's repository is a code change that the project's maintainers reviewed and chose to accept. That's what makes it hard to forge. The candidate can't merge it themselves. Someone outside their job search had to read the diff and say yes. The same logic covers package maintainership (a co-owner granted publish rights), conference talks (a program committee picked them), and issue threads where maintainers engaged with the candidate's technical argument.

The table also shows how the hour gets wasted. The top four rows are the most visible things on a profile, so it's easy to spend the whole hour scrolling repos and squinting at graphs. Only the bottom two rows answer the question.

How do you verify a software engineer's experience in 10 minutes?

Check one claim against evidence a third party approved, in a fixed order, and stop as soon as you find proof. Here's the sequence, with a time budget for each step.

1. Pick the claim that matters (1 minute). Take the one skill the hiring manager can't compromise on, such as "production Rust." Ignore the other tags.
2. Search merged PRs outside their own repos (3 minutes). In GitHub search, run is:pr is:merged author:HANDLE -user:HANDLE. This lists PRs that other people's projects accepted. Open two and check the language, the size of the diff, and whether a maintainer left review comments.
3. Check the package registry for their stack (2 minutes). If they're listed as a maintainer or co-owner of a package other people depend on, someone gave them publish rights.
4. Look for talks and issue threads (2 minutes). Search their name with the technology and "talk" or a conference name. Then scan their comments on projects they don't own to see whether maintainers treat them as a peer.
5. Write the one-line proof (2 minutes). Use the format further down.

If steps 2 through 4 turn up nothing, don't let the search grow into an hour. Mark the claim "unverified, ask in screen" and move on. A first-round technical question tests the claim more cheaply than 50 more minutes of browsing.

The slowest part of those 10 minutes is usually matching a name to the right GitHub handle and registry account. That's the part Refolk is built to shorten. You describe the evidence you want in plain English, and the shortlist comes back already linked to the GitHub, registry, and open-web footprint behind each person.

Where does verification pay off most?

Verification pays off most in rare-skill pools, where a common tag tells you almost nothing and every wrong pick costs you a scarce candidate. In Refolk's index of professional profiles, US Software Engineers who list Python outnumber those who list Rust by 91.8 to 1.

A Python tag on one of 55,086 profiles doesn't set anyone apart, and you'll test it in the screen anyway. Rust is different. There are 36.3 US technical recruiters for every Rust-tagged software engineer, so the pool is tiny compared with the number of people who could be pitching it. Misjudge someone there and you can't easily replace them. The tags are self-reported either way, which is why checking matters most where the pool is small.

600 hours

That is the real cost of spending an hour per candidate. On a hard-to-fill role, checking the whole pool by hand takes longer than a quarter, and all that time the role stays open while the hiring manager waits for a shortlist.

Is a thin GitHub profile a red flag?

No. A thin public GitHub is a reason to check other sources, not a reason to reject someone, especially for engineers at large companies. In a 25-profile sample of US Rust-tagged engineers in Refolk's index, Meta was the most common employer, with 7 of 25.

Engineers at large companies often do most of their work in private codebases, so their best Rust may never show up on a public graph. That's an inference from the employer mix, not a measured fact, but it should change how you read an empty profile. Compare Oxide Computer Company, with 2 of the 25, which does much of its engineering in the open. An Oxide engineer will probably have merged PRs to show. A Meta engineer working on the same problem may not.

When the public GitHub is empty, use these fallbacks in this order:

• Package registries. A maintainer or co-owner listing shows someone granted them publish rights, whatever their day job.
• Conference and meetup talks. A program committee chose them, and the recordings let you judge their depth for yourself.
• Issue threads on open-source projects they use at work, where they report bugs and propose fixes.

If all three are empty, the claim moves to the technical screen. It doesn't disqualify the person.

How do you write the one-line proof a hiring manager will accept?

Write one sentence that names the claim, the evidence, who approved it, and when, with a link. A hiring manager should be able to check it in under a minute without having to trust you.

The template:

[Skill]: [evidence] approved by [third party], [recency], [link].

For example: "Async Rust: two PRs merged into a widely used open-source runtime by its maintainers within the last year (links)." Or: "Python packaging: listed co-maintainer of a package other projects depend on (link)."

This format matters most for agencies. In a sample of the 21,805 US technical recruiters and sourcers in Refolk's index, staffing firms such as K2 Partnering Solutions and Experis were the most common employers. An agency sends shortlists to a client who has every reason to discount the agency's own judgment. A link to a merged PR settles the question because the client doesn't have to take the recruiter's word for it. Someone outside the hiring process accepted the work.

Don't tell the hiring manager the candidate is strong. Show them which stranger already decided that.

Once you've written the proof line, you can reuse it in the ATS note, the client submission, and the outreach message. "I saw your merged work on [project]" shows you read the work. "Your profile caught my eye" shows you didn't. Refolk keeps the evidence attached to each name for this reason, so writing the proof line is mostly copying, not research.

FAQ

Can GitHub stars or contribution graphs be faked?

Yes, and cheaply. The StarScout study found about six million suspected fake stars across 18,617 repositories between 2019 and 2024, and star farms charge $0.03 to $0.90 per star. Contribution graphs can be backdated with the GIT_AUTHOR_DATE and GIT_COMMITTER_DATE variables, and public scripts do it automatically. Give weight to a pull request merged into someone else's project instead, because the candidate can't approve it themselves.

Should I reject a candidate whose skills I can't verify online?

No. Mark the claim "unverified, ask in screen" and test it with a first-round technical question. A thin public profile often reflects where someone works rather than what they can do. Meta was the most common employer in a 25-profile sample of US Rust-tagged engineers in Refolk's index, and a lot of large-company work happens in private codebases. Missing evidence moves the claim to the interview. It doesn't disqualify the person.

How common are fake job candidates, and does an evidence check catch them?

Keep the measured numbers separate from the forecasts. In a 2Q25 Gartner survey of 3,000 job candidates, 6% admitted taking part in interview fraud. Greenhouse's Real Talent checks, as reported by a secondary source, flagged one in four candidates for review and failed one in 33 at identity verification across more than 10.2 million checks. Gartner's prediction that one in four candidate profiles worldwide will be fake by 2028 is a forecast, not a measurement. An evidence check doesn't replace identity verification, because it confirms the work exists, not that the person in your interview did it. It does filter out cheap fakes early, since a fabricated persona can buy stars but not a history of PRs merged by strangers. In the interview, ask the candidate to walk through one of the PRs you linked. Whoever wrote it can explain the reviewer's objections.