Should you put GitHub on your resume?

Every developer has the same question at some point: should my GitHub profile be on my resume? The answer is not a blanket yes. It depends on what's there, what role you're targeting, and whether your profile actually makes you look better or worse than a resume alone would.

I've reviewed hundreds of engineering resumes. When a GitHub link is good, it's the single best signal on the page. When it's bad, it's worse than not having one at all. Let's figure out which camp you're in.

When GitHub helps (and when it hurts)

GitHub on a resume works when it provides evidence that your resume can't. A resume says "Built a CLI tool that reduced deploy time by 40%." GitHub shows the actual code, the commit history, the test coverage, the README that explains the architecture. One is a claim. The other is proof.

GitHub helps when:

• You have meaningful open-source contributions. PRs merged into well-known projects (React, Kubernetes, VS Code, Rails) are gold. They show you can navigate a foreign codebase, follow contribution guidelines, and get code past a demanding reviewer.
• You've built real tools that people use. A CLI with 200 stars, an npm package with 500 weekly downloads, a GitHub Action used in production workflows. Usage is the best signal.
• You're early-career and need to compensate for thin work experience. If you have one internship and no full-time experience, a strong GitHub profile can be the difference between a phone screen and a rejection. See our software engineer resume guide for how to structure this.
• You're applying to developer-tools companies, infra teams, or open-source-oriented orgs. Companies like HashiCorp, Vercel, Supabase, and Cloudflare actively look for open-source contributors. For these roles, GitHub is basically required.

GitHub hurts when:

• Your profile is mostly forked repos you never modified. This tells a recruiter you clicked "Fork" and walked away. It's worse than an empty profile because it suggests you wanted to look active without doing the work.
• Your repos are all tutorial clones. A "React To-Do App," a "Weather App Tutorial," and a "FreeCodeCamp Projects" repo tell a hiring manager you can follow instructions. They already assumed that.
• Your last commit was 18 months ago. A stale profile raises questions. Are you still coding? Did you lose interest? An inactive GitHub linked on a resume feels like a LinkedIn profile with a blurry 2015 photo.
• Your code quality is poor. No tests, no error handling, 500-line functions, commit messages like "fix" and "stuff" and "asdfg." A hiring manager will see this and mentally dock you before the interview starts.

What recruiters actually look at on your GitHub

When a recruiter or hiring manager clicks your GitHub link, they spend 30 to 90 seconds forming an impression. Here's what they look at, in order:

1. Your pinned repositories

This is the single most important thing. GitHub lets you pin up to six repos at the top of your profile. These are your storefront. A recruiter will click into one, maybe two. If those two are impressive, you've won. If those two are tutorial projects or empty READMEs, you've lost.

What makes a pinned repo impressive:

• A clear, well-written README with what the project does, why, how to run it, and maybe a screenshot or demo link
• Meaningful commit history (not one giant "initial commit" with all the code)
• Evidence of engineering practices: tests, CI config, linting, typed code
• A deployed version if applicable (link to a Vercel/Netlify/Fly.io deployment)

2. Your profile README

If you have a profile README (the special username/username repo), recruiters will read it. Keep it short. A one-liner about what you do, what you're interested in, and maybe your current role. Skip the animated GIF badges, the "visitor counter," and the auto-generated stats cards. They look like MySpace in 2006.

3. The contribution graph

The green squares. Recruiters glance at it, but experienced ones know it's noisy. It counts commits to private repos differently, doesn't distinguish between a one-character typo fix and a 2,000-line feature, and can be trivially gamed. A consistent, moderate contribution pattern is fine. A barren wasteland raises eyebrows. A perfectly solid grid of dark green raises different eyebrows.

4. Commit messages and code quality

The hiring managers who really dig in will click into a repo and scan commits. They're looking for:

• Conventional commits or at least descriptive messages. feat: add retry logic with exponential backoff vs. update stuff. The former says "this person ships production code." The latter says "this person codes alone at 2 AM."
• Reasonable PR/commit size. Small, focused commits that tell a story. Not a single commit with 47 files changed.
• Code organization. Sensible directory structure, clear naming, separation of concerns. They're pattern-matching against production code.

How to list GitHub on your resume

Where you put your GitHub link matters. There are three legitimate placements, and the right one depends on how central GitHub is to your candidacy.

Option 1: In your contact header (most common)

This is the standard approach for most software engineers. Your header contains your name, email, phone, LinkedIn, and GitHub. It signals "I'm a developer and here's my code" without over-emphasizing it.

Keep the URL clean. Use github.com/username without the https:// prefix. Make it a hyperlink in your PDF so it's clickable. Never use the full URL with https://www. — it wastes space and looks cluttered. For more header formatting tips, see our ATS resume guide.

Option 2: In your Projects section (for highlighting specific repos)

If you want to draw attention to a specific project rather than your whole profile, link individual repos in your Projects section. This is especially effective when a project is directly relevant to the role you're applying for.

This approach works well if you have two or three standout projects. It's how most experienced engineers present side work. See staff engineer resume examples for more patterns.

Option 3: In your Skills section (least common)

Some developers include GitHub in a "Links" or "Profiles" subsection within Skills. This is fine but it buries the link. Only do this if GitHub is supplementary and you don't want it prominently placed.

How to optimize your GitHub profile before linking it

Before you put that link on your resume, spend an afternoon making your profile presentable. Think of it like cleaning your apartment before having people over. Here's the checklist:

Pin your six best repos

Go to your profile page. Click "Customize your pins." Select six repos that represent your best work. Prioritize:

1. Original projects over forks (unless you've made substantial contributions to the fork)
2. Projects with clear READMEs over undocumented code
3. Projects relevant to the roles you're applying for. Applying for backend roles? Pin the Go microservice, not the React weather app.
4. Projects with some traction (stars, forks, npm downloads) over zero-activity repos

Write real READMEs

Every pinned repo needs a README that answers four questions:

1. What does this do? One paragraph. Plain English.
2. Why does it exist? What problem does it solve? Why did you build it?
3. How do I run it? Installation steps, prerequisites, a quick start.
4. What's interesting about the implementation? Architecture decisions, performance characteristics, trade-offs you made.

Add a screenshot or GIF for anything with a UI. Add a link to the deployed version. If it's a library, show a code snippet of the API. A good README is more impressive than the code itself, because it shows you can communicate about technical work — which is what the job actually requires.

Clean up your commit history

You don't need to rewrite history. But for repos you're pinning, make sure your recent commits have descriptive messages. If you're starting a new project specifically for your resume (totally legitimate), use conventional commits from the start: feat:, fix:, docs:, refactor:, test:.

Archive or hide old repos

That jQuery plugin from 2018? The half-finished Hackathon project? The repo where you were learning PHP? Make them private or archive them. Your public repos are a curated portfolio, not a diary. Go to Settings on each repo and either toggle visibility to Private or click "Archive this repository."

Set up a profile README

Create a repo named exactly your username (e.g., janechen/janechen). Add a README.md. Keep it minimal:

• One line about what you do ("Backend engineer at Stripe. Previously infra at Datadog.")
• One line about what you're interested in ("Working on distributed systems, database internals, and developer tools.")
• Optional: links to your blog, website, or a talk you gave

Do not add: animated SVG stats cards, "technologies I use" icon grids, visitor counters, or auto-generated contribution graphs. These are noise. They make your profile look like a README template, not a human being.

GitHub vs. portfolio site: when each is better

Developers often ask whether they need a GitHub profile, a personal portfolio site, or both. The answer depends on what you're trying to communicate.

GitHub is better for:

• Showing code quality and engineering rigor. A portfolio site can't show your commit history, test coverage, or how you structure a monorepo. GitHub can.
• Open-source contributions. If you've contributed to popular projects, your GitHub contribution history is the proof. A portfolio site would just be linking back to GitHub anyway.
• Backend and infrastructure roles. These roles care about how you write code, not how things look. A CLI tool or a database driver doesn't benefit from a portfolio page with screenshots.
• Demonstrating consistency. An active GitHub with regular contributions over months signals sustained interest, not a weekend sprint before job applications.

A portfolio site is better for:

• Frontend and full-stack roles. If you build UIs, show them deployed and running. A live site on Vercel or Netlify is more compelling than a README.
• Telling a narrative. A portfolio lets you explain the context, constraints, and impact of your work. "This saved the company $200K/year in infrastructure costs" is a story GitHub can't tell.
• Deployed products. If you've shipped products that people use, a portfolio with screenshots, demo videos, and metrics is more compelling than a repo link.
• Non-code contributions. System design documents, architecture diagrams, blog posts about technical decisions. These live better on a portfolio site.

The ideal setup

For most software engineers applying to competitive roles: have both. Your resume header links to both github.com/username and username.dev. Your portfolio site links to your GitHub repos. Your GitHub READMEs link to deployed demos on your portfolio. They reinforce each other.

If you can only pick one, pick the one that's more relevant to the role. Infrastructure engineer? GitHub. Frontend engineer? Portfolio. Full-stack? Whichever one is stronger right now. For help writing strong achievement-oriented bullets to accompany your project links, see our guide.

What NOT to do with GitHub on your resume

These are the mistakes I see most often. Each one makes a negative impression:

Don't link an empty profile

If you have zero repos, zero contributions, and a default avatar, do not put GitHub on your resume. It's the equivalent of listing "Spanish: conversational" and then not being able to order lunch in Madrid. A hiring manager will click the link, see nothing, and wonder why you included it.

Don't fill your profile with tutorial repos

A GitHub full of "react-todo-app," "node-weather-api," "fcc-responsive-web-design," and "udemy-complete-javascript" tells a hiring manager exactly one thing: you completed tutorials. That's fine for learning, but it's not a portfolio. If you have tutorial repos, make them private before linking your profile.

Don't list forked repos you never contributed to

Forking React, TensorFlow, or Linux doesn't mean you contributed to them. Recruiters can see the fork badge and the "0 commits ahead of upstream" indicator. If you forked a project, made meaningful changes, and submitted PRs, that's great — but the fork alone means nothing.

Don't game the contribution graph

There are scripts that generate fake commits to fill in your contribution graph. Experienced reviewers can spot this instantly — perfectly uniform green squares with empty repos is a tell. It's worse than a sparse graph because it signals dishonesty.

Don't use GitHub as a code dump

Pushing all your homework assignments, interview prep solutions, or random experiments to public repos without READMEs, without meaningful commit messages, and without any organization makes your profile look chaotic. If it's not polished enough to show a hiring manager, keep it private.

Don't link to a private repo

This happens more than you'd think. Someone puts github.com/username/secret-project on their resume without realizing the repo is private. The recruiter clicks, gets a 404, and moves on. Always verify your links work in an incognito window.

Real examples: 3 ways to reference GitHub on your resume

Here are three concrete examples showing different approaches, each suited to a different situation. Use these as templates for your own resume.

Example 1: Header placement (senior engineer)

This is the standard approach for experienced engineers. GitHub is one of several links. The resume does the heavy lifting; GitHub is supplementary proof. Marcus's pinned repos probably include internal tools he's open-sourced or side projects that show depth. See more patterns like this in our software engineer resume examples.

Example 2: Projects section (early-career engineer)

For early-career engineers, the Projects section is where GitHub shines. Each project has a direct repo link, a social proof metric (stars, downloads), and achievement-oriented bullets that describe what's technically interesting. This is far more effective than listing "JavaScript" and "Python" in a skills section.

Example 3: Skills section (career changer)

For career changers, GitHub goes in the Skills section as a "show, don't tell" supplement. David's resume focuses on his transferable experience, and GitHub provides evidence that he can actually code. The portfolio link alongside GitHub shows he's serious about the transition. See our resume examples for more role-specific formats.

FAQ

Should I put GitHub on my resume if I only have tutorial projects?

No. A GitHub full of to-do app tutorials and course exercises signals that you followed instructions, not that you can build software. Either level up a project into something original, or leave the link off entirely. An empty Projects section is better than one that undermines your credibility.

Where exactly should the GitHub link go on my resume?

In your contact header, right next to your email and LinkedIn URL. Use the format github.com/username — no need for the full https:// prefix. Make it a hyperlink in your PDF so it's clickable. If you only want to highlight a specific project repo rather than your whole profile, put that link in your Projects section instead.

Do recruiters actually look at GitHub profiles?

It depends on the role and the recruiter. For frontend, infrastructure, and developer-tools roles, many technical recruiters and nearly all hiring managers will click through. For enterprise Java or data-analyst roles, it matters less. The real audience is the engineer who does your technical screen — they almost always look.

Should I link GitHub or a personal portfolio site?

Link both if you have both. A portfolio site is better for showing polished, deployed work with screenshots and context. GitHub is better for showing code quality, contribution patterns, and technical depth. They serve different purposes and complement each other.

Does my GitHub contribution graph (green squares) matter?

Less than you think. Experienced reviewers know that the contribution graph is noisy — it counts private repo commits differently, doesn't reflect code quality, and can be gamed. What matters more is the quality of your pinned repos: clean READMEs, meaningful commit messages, and code that looks like it was written by someone who ships production software.

Should I clean up or delete old repositories before linking my GitHub?

Yes. Archive or make private any repos that are embarrassing, incomplete, or don't represent your current skill level. Recruiters will browse beyond your pinned repos. You don't need to delete everything — just make sure the first 10 to 15 visible repos tell a coherent story about what kind of engineer you are.