Read it in this order: what they recently shipped, where they shipped it, and only then how it looks. Recent activity comes first, because a strong profile that stopped two years ago is a different candidate. Then look for pull requests merged into other people's projects, which is reviewed work and the strongest public signal. Their own repositories show what they choose to build and in which languages. Stars, followers and the green contribution graph are the easiest parts to read and the least reliable.
The ten-minute reading order
- Last activity. The contribution graph and the most recent repositories say whether they are still writing code in public.
- Merged work in other projects. In GitHub's search,
is:pr author:USERNAME is:merged -user:USERNAMElists the pull requests they got accepted into repositories they do not own. - Their own repositories, sources only. Filter out forks in the repositories tab. What is left is what they started.
- Pinned repositories and the profile README. What they want you to see, which is useful precisely because they chose it.
- The languages bar of their repositories. A rough read of what they write, weighted by size, so a single large generated file can skew it.
Signals that hold up
- Pull requests merged by someone else. A maintainer read the code and accepted it.
- Code review comments. Someone who reviews others' code is trusted with judgement, not just output.
- Issues they opened or answered. How they explain a problem is close to how they will work with your team.
- Steady activity over months. Better than a burst, and better than a total.
Signals that mislead
- The contribution graph. It counts default-branch commits, pull requests and reviews, and it can be gamed with scripts. It also hides private work unless the person opts in, so an empty graph often means a day job in private repositories.
- Stars. They measure attention on a project, they never expire, and a single tutorial can collect thousands. Our page on stars as a hiring signal goes further.
- Followers. Influence, not building.
- Achievement badges. Gamification, with no bearing on skill.
In our index, 54% of developers pushed code in the last 90 days and 19% have contributed to a reference project of their ecosystem. Most profiles you open will be neither, which is why reading them in this order saves time.
Questions to bring to the first call
A profile raises questions rather than answering them. Ask about the merged pull request you found, what review it went through, and what they would do differently. Ask what the empty months were: often private work, sometimes a change of field. Both answers say more than the profile does.
Where this answer does not hold
A GitHub profile shows public work only. Most engineers write most of their code in private repositories, so a thin profile is not a weak engineer; it is an unknown one.
Frequently asked questions
Does an empty contribution graph mean someone is inactive?
Not necessarily. Private contributions are hidden unless the developer chooses to show them, so many active engineers have a nearly empty public graph.
What is the strongest signal on a GitHub profile?
Pull requests merged into projects the person does not own: the work was reviewed and accepted by someone else.
How do you see a developer's merged pull requests?
Search GitHub for is:pr author:USERNAME is:merged, and add -user:USERNAME to exclude their own repositories.
Do stars and followers matter when hiring?
Little. Stars measure attention on a project and followers measure influence; neither says what the person built recently.
Profiles ranked on the signals that hold up
StarHunt ranks on recent work and contributions, never on followers.
Try StarHunt for free