HitCVHitCV
← All guides

How to Put GitHub Projects on Your Resume: What Reviewers Actually Look At

Published 2026-10-15

For developer roles, a GitHub link on the resume is nearly standard — but the link itself adds nothing; what's behind it does. This guide covers what reviewers actually look at on GitHub, how to write project entries, and the most common ways to fumble it.

Reviewers actually look at three things

In order of how often they get checked:

  1. Pinned repositories: your GitHub profile is a second resume. Pin the 4–6 repos that best represent you — not the newest, not the most-starred.
  2. The first three screens of the README: if a repo can't explain "what this is, what problem it solves, how to run it" in 30 seconds, it gets closed. A README with an architecture diagram or a GIF demo roughly doubles attention time.
  3. The commit timeline: a year of solid green isn't required, but visible commits in the last three months shows the project is alive. A single "200 files committed at once" course-assignment pattern is instantly recognizable.

Star counts matter far less than people assume — most reviewers know stars track marketing more than engineering quality.

How to write a project entry

A solid entry = a name that says what it does + stack + one quantified outcome + link:

Shortify — self-hosted URL shortener (Go / PostgreSQL / Redis) Built for internal docs; P99 latency 18ms, serving 400k redirects/day, 14 months without incident. github.com/you/shortify

Three rules:

  • Lead with function: "self-hosted URL shortener" beats "Go-based microservice project".
  • At least one number: latency, users, cost saved, scale — whatever you have.
  • The link must work: click it yourself before sending.

Pick projects per JD, not per your pride

Applying for backend? Pin the high-concurrency service, not the flashiest frontend toy. Applying for infra? A CLI tool or CI pipeline may beat a product feature. Spend five minutes per application reordering pinned repos and project entries — those five minutes outperform starting yet another new project.

The classic fumbles

  1. Tutorial follow-alongs as "projects": "Udemy clone", "Vue e-commerce admin" — unless you meaningfully extended it (say what you extended).
  2. Dead links and empty repos: a 404, or a repo containing one README saying "work in progress".
  3. Missing or install-only READMEs: it says "I don't care whether others can understand this".
  4. Ten repos, none with a README or commits: volume doesn't compound. Three strong projects beat ten empty ones.

Where HitCV's GitHub import fits

HitCV can import your GitHub projects — repo descriptions, stacks and language breakdown — into the workspace, then drafts resume entries combined with the target JD. You still add the numbers (latency, users, cost): the AI doesn't know your production data. That's the division of labor we recommend: machines do the moving and structuring; you add the facts only you know.

Action checklist

  1. Pin your 4–6 strongest repos; give each a README that explains itself within three screens
  2. Check the last three months show visible commits (if not, maintain one project actively)
  3. Reorder entries per target JD and add one number to each
  4. Use HitCV's GitHub import to draft entries, then add your quantified outcomes