What does your GitHub
say to recruiters?

They aren't reading your code. A recruiter's first pass at a GitHub is a skim, measured in seconds rather than minutes, and most of it goes to the surface signals. They check whether your pinned projects sound real, whether the READMEs explain them in plain language, whether anything shipped recently, and whether a live link proves it runs. Engineers who join later interview rounds go deeper: tests, CI, commit messages, how the project is structured. And the thing both groups reward most is coherence, a GitHub that backs up exactly what the resume claims. That's why the score above weighs documentation, recency, and engineering practices the way it does.

Not stars. A project earns a place on your resume when a stranger can understand it in thirty seconds: a README that says what it does and why, evidence it runs (a deployment, a Docker file, a demo link), and signs that you maintained it after the first commit. One real project beats six abandoned tutorials, which is why the analysis picks a standout instead of counting repositories. If your best work is a class project, that's fine. Write it up like it mattered, because it did.

The usual suspects: repositories with no description, READMEs that stop at 'my project for CS 361', forks padding the profile, and six months of silence before a job search. None of these are fatal. All of them are fixable in an afternoon, and the opportunities list above tells you which afternoon to spend first.

Every number on this page is computed from public evidence: repositories, READMEs, file signals like tests and CI configs, language bytes, stars, and dates. The AI writes sentences only from that evidence, and when we don't have a real number, the bullet simply doesn't claim one. Scores aren't flattery. A thin profile scores low with a low-confidence label, because a tool that tells everyone they're great would be useless to the people it's for.