Last month I looked at 23 GitHub profiles from developers who were actively job hunting and asked a hiring engineer friend to skim them for 90 seconds each. He stopped on 4. The ones he stopped on had something in common: you could understand what the person built within about 10 seconds without clicking anything.
The rest had either nothing pinned, or 6 pinned repos with names like “practice-problems” and “test-project-v3” and commit messages that said “update” or “fix stuff”. Real commit history from someone who was clearly learning. But the profile made no argument for why you’d want to talk to this person.
That’s fixable. Here’s how.
The profile README is not optional anymore
GitHub renders a special README when you create a repo with the same name as your username. Most developers know this exists. Most developers either don’t have one or have one that says “Hi I’m [name], I like to code” with a bunch of badges from shields.io showing languages they’ve used once.
A README that works does a few things:
- Says specifically what you build (not “passionate full-stack developer” — something like “I work on backend APIs in Go and React frontends, mostly for fintech and logistics tooling”)
- Links to 2-3 things you’re most proud of (projects, blog posts, talks, open source contributions — your choice, doesn’t have to be code)
- Has a contact path (email or LinkedIn, one of them)
It doesn’t need to be long. A tight 4-paragraph README is better than a 20-section one with empty sections. The badges are fine if you like them but they don’t move hiring decisions. I’ve never heard a recruiter say “the language percentage chart sold me.”
Pinned repos: curate, don’t dump
You can pin up to 6 repos. The question is which 6.
The instinct is to pin your biggest projects. That’s mostly right, but “biggest” doesn’t always mean what people think. A 30,000-line project with no README and a commit history of “wip” and “more stuff” communicates less than a 200-line project that has a clear problem statement, a working demo link, and readable code.
For each pinned repo, check:
- Does the repo description (the little text under the name) say what it does in one sentence?
- Does the README explain what problem it solves, what the tech stack is, and how to run it?
- Is there a demo link, screenshot, or GIF showing it working? (This matters more than people think. A recruiter who can see the thing immediately is more likely to keep reading.)
- Are the commit messages coherent, or is the visible history “fix”, “fix2”, “final”, “final2”?
You don’t need 6 great projects. Three good ones are better than six mediocre ones. The GitHub Octoverse report notes that repository documentation quality is one of the leading factors in whether a project gets engagement from other developers. The same principle applies to recruiters: they follow signals of quality, and documentation is a visible quality signal.
Commit history and what it says about you
Hiring managers do look at commit history. Not all of them, and not in depth, but a spot check is common enough that it’s worth thinking about.
The most damaging thing isn’t sparse commits. It’s commits that suggest you don’t think about the next person who reads your code (even if that person is future you). Messages like “asdfgh” or “temp” or “why won’t this work” are genuinely noticed.
Conventional commit format is worth adopting, something like: feat: add pagination to search results or fix: handle null case in user auth middleware. It’s not that recruiters know the convention. It’s that reading a commit log like that tells a coherent story. Reading “update update update fix” does not.
Using feature branches is also worth the habit. A main branch with 47 commits all directly from one author looks different from a main branch where you can see PRs merged in from feature branches. It suggests you know how real teams work, even if the project is solo.
The contribution graph: more signal than people admit
The green squares. People debate how much they matter. My honest opinion is that they matter a modest amount and probably not in the way most people think.
A completely empty graph for the last 6 months during a job search reads as “this person has not been writing code.” That’s not a disqualifier but it’s a neutral-to-slightly-negative signal. A very dense graph can be gamed and most hiring engineers know it.
What actually reads well: consistent but not robotically perfect activity. Some weeks more, some weeks less. Commits spread across different repositories rather than 200 commits to one repo in one week. It looks like someone who codes as part of their actual life, which is the point.
(Side note: GitHub counts commits to private repos in the graph if you enable that setting. If you do meaningful work in private repos, turn that on. It’s not cheating.)
One thing recruiters actually use that most developers miss
The “pinned” section is visible on your profile. But your profile’s general repository list is searchable from a recruiter’s perspective. If someone is looking for a Python developer and your repos have no topics or language tags, your profile is less likely to surface.
Add topics to your repos. GitHub has a topic tag system (the little colored pills under the repo description). Tags like machine-learning, rest-api, typescript, react help with discoverability. Almost no one does this for their older repos. Five minutes of tagging across your main projects is probably underrated as a ROI-per-minute improvement.
The LinkedIn Economic Graph research on hiring consistently shows that signal clarity matters at every stage of the funnel. A GitHub profile that makes its author’s skills immediately legible is a clearer signal than one that requires investigation. That’s the goal.
None of this is complicated. The gap between a profile that gets noticed and one that gets skipped is usually 3-4 hours of work spread across a weekend. It’s one of the better investments you can make per hour if you’re actively looking.