A technical hiring manager who wants to shortlist a backend engineer will often open GitHub before they open the resume attached to the application. Not instead of, necessarily, but before: the profile loads faster than a conversation, and it shows something a resume can't fake nearly as easily, a record of actual work, timestamped, in public. GitHub now hosts more than 100 million developers and over a billion public contributions. That scale is exactly why activity there functions as a filter: there's enough of it that a recruiter skimming a profile can tell, in under a minute, whether they're looking at someone who builds things or someone who has a GitHub account.
An estimated 68% of top-tier engineers get discovered, at least in part, through their GitHub activity rather than through a resume or a job board. If that's roughly true, then a GitHub profile isn't a nice-to-have next to your CV. For a lot of engineering roles it's functioning as the actual CV, and the resume is the follow-up document. Worth treating it that way.
What a recruiter is actually looking at
Nobody is reading your code line by line in the first pass. A recruiter or hiring manager scanning a profile is looking at a handful of signals in a very short window: what's pinned at the top, whether the contribution graph shows a pattern or a single spike, whether the READMEs explain anything, and whether the commit history looks like a real working process or a project assembled the night before an interview. Getting those signals right matters more than adding more repositories.
Six things worth fixing before anyone looks
- Pin what shows independent thinking, not coursework. The six repos pinned at the top of your profile are the ones a recruiter sees first, and often the only ones they see. A tutorial project or class assignment tells them nothing about how you think. A project you scoped, built, and finished yourself, even a small one, tells them a great deal more.
- Treat forks as a liability unless you've actually contributed. A profile with dozens of forked repositories and no commits inside them doesn't read as curiosity, it reads as a collection of things you meant to get to. If a fork isn't backed by real commits or a merged pull request, it's doing you more harm than good sitting on your profile.
- Write the README like it's the only thing anyone will read. Often it is. Explain what problem the project solves and why you built it, not just installation steps. A recruiter who can't tell what a project does in the first two sentences of the README will move on before they open a single file.
- Let the commit history show years, not a weekend. This is the single biggest factor separating a real signal from a manufactured one. A contribution graph with a steady scatter of activity across years reads as someone who builds things as a habit. A graph that's empty for months and then lights up for two weeks right before job applications go out reads exactly like what it is.
- Keep the history honest. Squashing every commit into one, or force-pushing over a project's real history right before sharing it, removes the one thing that made the history valuable: an incremental, timestamped record of how the work actually happened. A messy but real commit history is more convincing than a suspiciously clean one.
- If you reach out, or someone reaches out to you, get specific. Outreach that references a particular pull request or a specific design decision in a specific repo performs meaningfully better than outreach that doesn't. Personalized messages anchored to real GitHub activity see response rates in the range of 25 to 40%, compared with roughly 10 to 15% for generic LinkedIn InMail. The same logic runs in both directions: a candidate emailing a hiring manager about a specific piece of that company's open-source work will get read before a form cover letter does.
None of this requires a portfolio of twenty polished projects. A recruiter spending sixty seconds on a profile is looking for a pattern, not a museum. Two or three real, finished, well-explained projects with a commit history that spans years will do more for you than fifteen forks and a single burst of green squares from last week.