How to Evaluate a Developer's GitHub Profile (A Guide for Recruiters)

A GitHub profile is the closest thing a recruiter gets to a work sample that was not written for the interview. It is also easy to misread. A green contribution graph looks impressive and means very little. A quiet profile looks weak and often means the candidate works in private repositories at their employer.

This guide shows what to look at, in what order, and how to avoid the common mistakes. You do not need to read code to follow it. You need to know which signals are hard to fake, and which are noise.

What a GitHub profile can and cannot tell you

GitHub shows public activity. That is a slice of a developer's work, and for many people a thin one. Most professional code lives in private company repositories, and none of it appears on a personal profile.

So treat GitHub as evidence that can raise your confidence, not as a verdict. A strong public record is a good sign. A thin one tells you almost nothing, and you should never reject a candidate because their profile is empty. Ask for a code sample, a short take-home task, or a walkthrough of a project they can discuss instead.

Step 1: Skip the contribution graph

The green squares count commits, issues and pull requests, but not their quality. They reward volume and are trivial to inflate: an automated script, a daily one-line commit, or a burst of activity in December can fill the graph. People also contribute in bursts because of work cycles, vacations and jobs that forbid personal projects.

Look at the graph only to spot extremes, such as years of total silence or thousands of commits in a day, and then move on to what the commits actually are.

Step 2: Check pinned and recent repositories

Pinned repositories show what the candidate wants you to see. Open two or three and check:

• Is there a README that explains the project? Someone who writes a clear README can usually communicate, which matters in a team.
• Is it their own work or a fork? A fork with no changes is a bookmark. A fork with a long list of their own commits is real work.
• Does the project run something useful? A small tool used by other people beats a tutorial copy, even if the tutorial copy has more stars.
• Are there tests? A folder named test or tests, or a CI badge in the README, shows the candidate cares whether their code keeps working.

Stars matter less than they appear to. A repository can collect stars from a single viral post. Treat them as a weak signal that other people noticed the project, not as a quality score.

Step 3: Read the pull requests, not just the commits

This is the most useful step, and the one most recruiters skip. On a candidate's profile, open the pull requests they made to other people's projects, especially merged ones.

A merged pull request means a maintainer who does not know the candidate reviewed the change and accepted it. That is outside validation, and it is much harder to fake than a personal project. Look at:

• Was it merged, or left open or closed? Merged is the signal. Many open or rejected requests are not a red flag on their own, because maintainers reject plenty of good work.
• How did they respond to review comments? A candidate who answers feedback politely, makes the requested changes and explains their reasoning is showing you how they will behave in code review at your company.
• How big is the change? A typo fix in documentation is fine as a first contribution but is not evidence of engineering depth. A bug fix in an unfamiliar codebase is.

The same goes for reviews they gave. Someone who leaves careful, constructive comments on other people's pull requests is demonstrating skills that no coding test measures.

Step 4: Look for sustained ownership

One impressive repository can be a weekend project, a copy of a tutorial, or a collaboration where someone else did the hard parts. Look for a pattern instead:

• Commits to the same project over months or years
• Bugs reported by users and fixed by the candidate
• Releases, changelogs or version tags that show the project was maintained
• Issues the candidate answered in a helpful way

Maintaining something over time is a stronger signal than building something once, because it involves the unglamorous work of fixing bugs and answering questions.

Step 5: Match the profile to the role

A profile is only useful against what you are hiring for. A backend engineer for a payments company should show evidence of careful, tested code and an understanding of failure cases. A frontend developer should show interfaces that real people can use. A data engineer might show pipelines and documentation.

Do not penalise a candidate for working in a different language than your stack. Good engineers move between languages. Do pay attention when the work is far from the role entirely, for example a profile that is all game mods applied to a role in infrastructure. That is not disqualifying, only a reason to ask about the gap.

Red flags, and things that look like red flags but are not

Real concerns:

• Repositories that are verbatim copies of other projects, with no changes and presented as original work
• A large codebase uploaded in a single commit with no history, which may have been copied
• Claims on the résumé that the public record contradicts, such as "maintainer of" a project the candidate has never committed to

Not real concerns:

• An empty profile, a short history, or private contributions only
• Messy early projects, which are normal for a learner
• Few stars, few followers, no blog

Be careful about AI generated code as well. Today many developers use AI assistants, and that is normal practice. You cannot reliably tell from the outside whether a particular file was written with help, and any tool that claims to detect it should be treated with suspicion. What you can check is whether the candidate understands the code they submitted, and that is what the next step is for.

Step 6: Turn what you found into interview questions

The profile is the starting point for a conversation, not the end of the evaluation. Pick one project or pull request and ask the candidate to walk you through it:

• "What problem were you solving, and why did you choose this approach?"
• "What would you do differently now?"
• "Where did the maintainer push back on your change, and how did you respond?"
• "What is the hardest bug you hit in this project?"

Someone who wrote and understood the code answers these easily and with specifics. Someone who copied it, or generated it without reading it, tends to stay vague. These questions are fair, because they are about the candidate's own work, and you do not need technical knowledge to hear the difference between a concrete answer and a rehearsed one.

Doing this at scale

Doing steps 2 to 6 by hand for each candidate takes time, which is why many recruiters stop at the contribution graph. Tools can speed up the first pass. DevEval, for example, reviews the code a candidate wrote, summarises merged pull requests and reviews given, and shows a confidence level on each score so you can see where it had little to go on. It reads public GitHub only, so it carries the same limit described above: a quiet profile produces a low-confidence report, not a bad one.

Whether you use a tool or your own eyes, the principle is the same. Look for evidence others accepted, look for work sustained over time, be honest about what you cannot see, and let the candidate explain their own code.

A quick checklist

1. Ignore the contribution graph, except for extremes.
2. Open two or three pinned repositories and check the README, the history and whether there are tests.
3. Read merged pull requests to other projects and how the candidate handled review.
4. Look for work that was maintained over months, not built once.
5. Compare the profile to the role, not to a stereotype of a "good" developer.
6. Treat a thin profile as missing data, not as a negative.
7. Prepare two or three questions about the candidate's own code.

Used this way, a GitHub profile makes your first screen sharper and your interviews more specific, without pretending to be more than it is.