Make your GitHub survive a recruiter's 90-second review
Recruiters spend about 90 seconds on your GitHub before forming a verdict. Here's exactly where those seconds go — and how to win each one.
Key takeaways
- Pin 3–6 repositories deliberately — the default view rarely shows your best work
- A README with a screenshot, setup steps, and decisions beats a bigger codebase without one
- Consistent commit history over months signals work habits; a pre-application burst signals panic
- Archive or hide tutorial clones — they dilute everything else
Where the 90 seconds actually go
When a recruiter or hiring manager opens your profile, the sequence is nearly universal: bio and profile README first, pinned repositories second, contribution graph third. If something catches their eye, they open one or two repos and skim the README. That's the whole review. Nobody reads your code at this stage — they read the signals around it.
That has a blunt implication: the quality of your actual engineering matters less at the screening stage than how legibly it's presented. A strong project that looks abandoned or undocumented loses to a modest project that explains itself.
Pin like a curator, not an archivist
GitHub shows six pinned slots. Treat them as your portfolio's front page. Lead with the project that best matches the roles you want — a deployed API for backend roles, a polished interface for frontend. Every pinned repo should have a description, topics, and a README that opens with what the project is and a screenshot or live link.
Everything that isn't pinned still speaks. Fork graveyards, half-finished tutorial follow-alongs, and repos named "test2" quietly undermine the pinned six. Archive what's dead, delete what's noise, and keep experiments in clearly labeled repos.
The README is the interview before the interview
A recruiter-grade README answers four questions in order: What is this? Can I see it? How do I run it? What was hard about it? A screenshot or live URL near the top does more than any badge wall. Setup instructions prove the project actually runs. A short "decisions" section — why this database, why this structure — is what separates an engineer from a tutorial-follower.
Write it for a smart person who has never seen the project. If your README requires the reader to open the code to understand the project, it isn't finished.
Commit history is a character reference
The contribution graph gets read as a proxy for work habits. Months of steady activity — even modest — reads as genuine interest. A dense green burst two weeks before you started applying reads as exactly what it is.
You can't retrofit consistency, but you can start it today: small, real commits with messages that describe the change. "Fix pagination off-by-one on empty result sets" tells a story; "update" tells on you.
Run the review on yourself
Open your profile in a private browser window and give yourself 90 honest seconds. What's pinned? What does the top of each README show? When was the last commit? That exercise finds most of the problems this guide describes.
For the version with a score attached: DevProfile runs this review the way a technical recruiter would — reading your repositories, scoring seven dimensions of the code itself, and telling you which fixes move the needle first.
Related roadmap
Backend Developer Roadmap
From your first language to production APIs — databases, auth, testing, and deployment in one staged path.
View the roadmap