Screening on GitHub is not about becoming an engineer. It is about not wasting interviews on profiles that fall apart when you open a repository.
This is a recruiter-ready checklist you can run in two to five minutes per candidate.
Set the bar to the population
Across large skill groups in our index, the median developer has about 24 public repos, 42 contributions in the last year, and 8 followers. Daily-green graphs are not the norm.
If you reject everyone below "active every day," you are filtering for open-source lifestyle, not competence. Calibrate with the GitHub sourcing guide baselines.
The five-minute screen
1. Recency (30 seconds)
Sort repositories by recently pushed. Look for activity in the last 6–12 months.
Pass: ongoing work in the stack you care about. Fail: last meaningful push three years ago, unless the role is management-only.
2. Substance over count (60 seconds)
Ignore raw repo totals. Open the largest non-fork project with a real README.
Pass: describes what the project does and why; has structure.
Fail: dozens of empty tutorial repos named my-first-react-app.
3. Commit hygiene (60 seconds)
Skim recent commits on that project.
Pass: messages that explain intent; steady cadence.
Fail: 200 commits titled update on one weekend, then silence.
4. Code smell without being an expert (60 seconds)
Open two source files.
You are not grading algorithms. Check:
- Are names readable?
- Is there any test directory or CI config?
- Does it look copied wholesale from a course?
Pass: organised, intentional. Fail: single 2,000-line file with no structure, or obvious homework dumps only.
5. Collaboration signal (60 seconds)
Click Issues or Pull requests they filed on other people's projects.
Pass: clear bug reports, constructive review comments. Fail: only drive-by "thanks" comments, or hostile threads — note and probe in interview rather than auto-rejecting.
This fifth step is the one most screeners skip and the most predictive of how someone behaves on a team.
What to ignore
Follower count across languages. C and Bash communities show higher medians than JavaScript. It is network shape, not talent.
Stars on a viral toy. Popularity ≠ production quality.
Green squares alone. Private monorepo workers look "inactive" and may be excellent.
Long language lists. Fourteen languages usually means tutorials. Prefer depth in the two you need.
A simple scorecard
| Signal | Weight | Notes |
|---|---|---|
| Recency in target stack | High | Last 12 months |
| One substantial repo | High | README + structure |
| Commit quality | Medium | Intent, not spam |
| Tests / CI present | Medium | Especially for senior IC |
| External PRs / issues | Medium | Collaboration proxy |
| Followers / stars | Low | Context only |
Decide "advance / hold / reject" from this table before you write the email. Do not invent new criteria mid-pipeline.
After the screen
Advance: send a short, specific note naming the repo you liked — email templates.
Hold: good overall, wrong stack depth — keep for a different role.
Reject: no need to message. Spend the time on the next profile.
When GitHub screening is the wrong tool
- Role is primarily people management with little coding expected.
- Candidate works in a regulated environment that forbids public code.
- You already have a strong work trial ahead; then screen lightly and let the trial decide.
Otherwise, five minutes here saves fifty minutes in a wasted interview. Pair with Boolean search to build the list, then this checklist to cut it.