Most candidates imagine a hiring manager reading their code line by line. The reality: your GitHub gets a 60–90 second skim, usually by a recruiter first and an engineer later, each looking for different things. Knowing what each pass checks — and in what order — lets you optimize the profile for how it's actually read.
Pass one: the recruiter skim (60 seconds)
Recruiters are not reading code. They're pattern-matching signals they can report upward:
- The contribution graph — not for volume, but for consistency. A steady green rhythm reads as "actively coding"; a two-year gap raises a question you'll be asked about.
- Pinned repositories — the six tiles are your shop window. Unpinned, GitHub shows your most-starred forks, which tells a recruiter nothing about you.
- The profile README and bio line — role, stack, location, and whether you look hireable (contact route, link to a fuller page).
- Follower/star counts — weak signals, but visible ones; they function like social proof.
Pass two: the engineer look (5–10 minutes, if you pass the skim)
- README quality of one or two pinned repos: can they understand what it does, run it, and see a screenshot without cloning?
- Commit messages — "fix stuff" ×40 versus messages that explain intent. This is read as a preview of how you'll work in their codebase.
- Real-world hygiene: tests, CI badges, issues handled politely, PRs to projects you don't own. Contributions to established open source outweigh a dozen solo toy repos.
- Recency over totality — what you wrote this year matters more than your whole history.
What almost nobody checks
Total repo count, language percentages, achievements badges, and whether you committed every single day. Grinding the graph with empty commits is a known trick — interviewers discount streaks that don't correspond to real projects, and some treat obvious graph gaming as a negative signal.
The 6 fixes that change the skim's outcome
- Pin six repos deliberately: your best project, a contribution to a known project, and things that match the roles you want.
- Give each pinned repo a one-line description and topics — the tiles show them.
- Write a profile README: who you are, stack, two highlights, one contact link.
- Clean the bio line: role + specialty, a location, and a link to your fuller page.
- Archive dead experiments so they stop diluting the picture.
- Route the skim somewhere you control: a bio page that adds the context GitHub can't show — experience, projects with outcomes, and a way to reach you.
GitHub is the evidence — not the argument
A GitHub profile can prove you code; it can't present you. That's why the strongest candidates link their GitHub to a page that frames it: a whomi.bio profile streams your live GitHub activity (plus Stack Overflow, LeetCode and npm) next to your experience, case studies and a structured contact inbox — so the 90-second skim ends on a page built to convert it. Claim your handle free, or read GitHub README vs Developer Bio Page for how the two work together.
Sources & further reading
- Pinning and profile customization: GitHub Docs — pinning items to your profile
- Profile README setup: GitHub Docs — managing your profile README
- Companion guide: Developer Portfolio Examples: What Great Ones Do