Your GitHub is part of your application, so we read it too
If you put a GitHub link on your resume, somebody is going to click it. Here is what they find in the first thirty seconds, and what we tell you about it.
Original work, not forks
We separate repositories you actually built from the ones you cloned, because a reviewer does that immediately.
Whether it looks alive
The date of your last push, and whether anything moved in the past ninety days.
Whether anyone can tell what they do
How many of your repositories have a description, and what your profile readme says if you have one.
Languages and reach
The languages you actually ship in, your stars, and your most notable repositories.
Almost every resume tool stops at the document. For a developer that misses half the application, because the link you included is the part a technical reviewer trusts most. A resume says you know Python. A repository shows what you do with it.
What a reviewer actually looks at
Not your commit graph. The green squares get talked about far more than they get looked at, and plenty of excellent engineers have sparse ones because their work is in a private repository at a job. What a reviewer does in the first half minute is narrower than that.
- Is any of it yours? A profile of thirty repositories where twenty eight are forks reads as a profile of two. This is the first thing we separate, because it is the first thing a reviewer separates.
- Can I tell what these are? A repository with no description is a closed door. We count how many of yours have one.
- Has anything moved recently? We report your last push and whether there was activity in the last ninety days. Dormant is not disqualifying, but a profile linked from a resume that has not moved in three years invites a question.
- What do you actually write? The languages across your repositories, which sometimes disagree with the skills list on the resume. That disagreement is worth knowing before an interviewer finds it.
- Does the front page say anything? A profile readme is the one piece of your GitHub you fully control. Most people do not have one. We tell you what yours says, or that there is nothing there.
Stars are reported because people ask, but they are the weakest signal here. A tutorial repository with four hundred stars tells a reviewer less than one original project with a clear readme.
What this is not
It is not a code review. Nothing here reads your source and judges your architecture, and any tool claiming to do that from a profile scan in a few seconds is not doing it. What this does is read the public surface of your profile the way a human reviewer reads it, quickly and from the outside, and tell you what that surface says.
It is also not a ranking of you as an engineer. A quiet GitHub often means a busy job with private repositories. The useful question is narrower: if somebody follows the link on your resume, do they find something that helps you or something that raises a question?
The most common things we report back
| What we find | Why it matters |
|---|---|
| The link on your resume is broken | A 404 is worse than no link. It happens after a username change and nobody notices. |
| Almost everything is a fork | A reviewer reads the original count, not the total, and yours is lower than you think. |
| No descriptions anywhere | Each repository is a guess. One line each is twenty minutes of work for a visibly better profile. |
| No profile readme | The one surface you fully control is blank, on a profile you are inviting people to visit. |
| Languages disagree with the resume | The resume leads on one stack and the repositories are mostly another. Worth reconciling before an interview. |
If you are a designer rather than a developer
The same thing happens with a portfolio link. If your resume links a portfolio on a host we recognise, we read what is reachable there too and tell you whether the page loads, what it appears to be, and whether it backs up the document. The principle is the same: a link on your resume is part of your application, so it should be checked before somebody else checks it.
Questions people ask
- Can I review a GitHub profile without uploading a resume?
- Not at the moment. The profile is read from the link on your resume, so the document is what starts the check. If the GitHub review is the part you want, make sure your profile URL is on the resume before you upload it.
- Do you need access to my private repositories?
- No. Nothing is connected and no permission is requested. Only your public profile is read, which is exactly what a recruiter following your link would see.
- Does a sparse commit history count against me?
- No. Plenty of strong engineers have quiet public profiles because their work is private. We report when you last pushed as a fact, not a verdict, because a reviewer will notice it and you should know what they are seeing.
- Do you review the actual code?
- No, and nothing that scans a profile in seconds genuinely does. This reads the public surface of your profile the way a human skims it: what is original, what is described, what is active, what you write in.
- What if my GitHub link is wrong on my resume?
- We tell you, which is one of the more useful things this catches. A broken profile link is common after a username change and it is worse than having no link at all.
See what your GitHub says about you
Put the link on your resume, upload it, and get both read at once. First one free.
Upload mine →First one free · one payment, never a subscription
Read next
- What makes a developer resume differentThe sections that carry weight, and the ones that waste the page.
- Check your resume reads properly in five minutesBefore anything else, make sure your file parses at all.
- Keywords, without writing for a robotWhy recruiters search the database, and what to do about it.