GitHub on Your Resume: 7 Checks Recruiters Run First (2026)

Recruiters do not just look at your resume. They open the GitHub link in a second tab. According to GitHub Octoverse 2025, 180 million developers are now on the platform, a new one joins every second, and TypeScript just overtook Python as the most-used language. The 2025 Stack Overflow Developer Survey put GitHub at 81 percent usage across professional developers. Your GitHub is no longer optional context. For engineering roles in 2026, it is the second page of your resume whether you intended it or not.

This post is the recruiter-side checklist applied to your profile, in order. The 7 checks below run in the first 30 seconds of a profile visit. There is also a new 2026 tell to fix that almost nobody is talking about: the Copilot co-author line that VS Code now adds to your commits by default. Fix that first, then run the rest.

Should you put GitHub on your resume at all?

Not every engineer should. The honest answer depends on three things: what bucket of work you actually have public, what role you are applying to, and how recently you have shipped anything outside work.

Yes, include it if you are a new grad, bootcamp graduate, career switcher into tech, applied researcher, open source maintainer, developer-advocate, or anyone whose public work is the strongest proof you can write code. For these roles GitHub is the difference between a callback and silence. The portfolio is the credential.

Probably include itif you are a mid-level engineer with at least three or four real public projects, a few merged PRs to other people's repos in the last year, and a profile that reads as professional. The link is a soft positive. It will not get you the job but it will not cost you the screen.

Skip itif your last public commit was in 2022, your pinned repos are all bootcamp clones, your username is a teenage gamertag you have not changed in five years, or all your real work lives in private company repositories you cannot share. An empty or stale GitHub link is worse than no link, because it answers the recruiter's "can this person actually build?" question with a no. A senior engineer at a closed-source shop with nothing to publish is a normal case. Describe the work in the experience section instead, in the language of outcomes the bullet-point guide spells out.

An empty GitHub link is worse than no GitHub link. The link is a promise. The empty profile is a broken one.

The 7 checks recruiters run on your GitHub

The order below is the order most engineering recruiters move through a profile. The first three checks take five seconds each. If any one of them fails, the rest stop mattering.

Check 1: Username, photo, and name match

The first thing a recruiter compares is your resume name against your GitHub identity. If your CV says Alex Morgan and the GitHub profile reads xX_alexkilla_Xx with a default identicon avatar and no display name, the recruiter cannot verify the profile belongs to you in under two seconds. That uncertainty alone is enough to close the tab.

Fix this before you send the next application. Set your GitHub username to a variation of your real name (alexmorgan, alex-morgan, amorgan). Add a real photo, not a cartoon. Fill in the display name field so it reads "Alex Morgan" below the avatar. If your old username appears in published projects you cannot rename, link to the GitHub profile that does match your real name and explain the alternate username in the README.

Check 2: The six pinned repos (your highlight reel)

GitHub lets you pin up to six items to the top of your profile. The limit is hard-coded, six and only six, per GitHub Docs. Those six are the only repos most recruiters will open. The rest of your profile is the contribution graph plus a scrollable repo list almost nobody scrolls.

Pin with intention. A pattern that works for most engineers:

1. One project you own, end to end, with a live link and tests (your strongest public artifact).
2. A second owned project in a different stack or domain (signals you are not a one-language coder).
3. One project you contributed to but did not start (your merged PRs show on the repo, collaboration is visible).
4. One small but published library or CLI tool that other people actually use (npm, PyPI, Homebrew, anything with a download count above zero).
5. One repo that ties to the job you are applying to (a Next.js repo if the role is Next.js, a Rust repo if Rust, a notebook repo if data science).
6. One optional fun or recent project (a hackathon win, a weekend prototype, something that signals you still write code when you do not have to).

Three to five is also fine. Six is the ceiling. What you should never pin: a starter template you forked and did not finish, a tutorial-clone calculator app, an empty repo with only a README, or an "awesome-lists" collection. Those four signal the opposite of what you want.

Check 3: The profile README

The profile README is the special repo named after your username. When it exists, it renders at the top of your profile above the pinned repos. Recruiters scan it in about 15 seconds. If yours is missing, you are leaving the most valuable real estate on GitHub empty.

Keep it short. Six to ten lines. State the role you are targeting in one sentence, the stack you work in, two or three of your strongest projects with one-line summaries and links, and one way to contact you. Use plain Markdown headings, no more than two emoji, no animated GIFs that take seven seconds to load. If your README has a snake eating your contribution graph and seven badge widgets and a Spotify-now-playing embed, you have the wrong README. Recruiters want signal, not a developer-cute homepage.

Check 4: The contribution graph (read it honestly)

The contribution graph is the green grid below your README. It is also the most over-weighted signal on GitHub. The recruiter glance at the graph takes under five seconds and looks for two things: is there activity in the recent six months, and is there a suspicious burst right before this application.

A graph with consistent gaps is normal. Engineers take vacations, do paid work in private repos, switch jobs, have babies, finish degrees. What reads as a red flag is empty for eight months, then a wall of green in the two weeks before the resume goes out. That pattern is recognizable, and tools that "fill your contribution graph with fake commits" are recognizable too. Anyone who can read commit timestamps and diff sizes can see the pattern in 20 seconds, and on a resume it is the same as the patently fake one-month-each career timeline.

If most of your real work is in private repos at your employer, GitHub has a setting for this. Go to your profile, click Contribution settings above the calendar, and toggle private contributions visible. The graph then shows the count of your private commits per day, without revealing the repo name, commit message, or any code. The graph turns from sparse to honest, and recruiters can see you have been writing code, just not in public.

Check 5: The Languages bar

Click any of your pinned repos and you see a colored bar across the top showing the language breakdown for that repo. On the profile page, GitHub aggregates this across your public repos. If your top language reads as HTML at 60 percent or CSS at 45 percent because of an old portfolio site and a bunch of GitHub Pages experiments, recruiters scanning for a backend or systems role will close the tab.

There are two fixes. One: archive or delete the static-only portfolio repos so they stop dominating the language stats. Two: in repos where the real work is in one language but the repo also ships a build artifact (a minified JS bundle, a notebook with HTML output, a docs site), add a .gitattributes file with *.html linguist-vendored=true or *.html linguist-generated=true to tell GitHub to skip those files for language detection. Both are documented on GitHub. Both take 10 minutes.

Check 6: At least one merged pull request outside your own repos

This is the highest-impact signal on the entire profile and most candidates skip it. One merged PR to a popular project, even a small one, says you can read a stranger's codebase, follow their contribution guide, open a clean PR, respond to review, and ship. That is the entire job.

Do not list one-word typo fixes. A README typo PR does not count. What counts: a bug fix with a test, a new option on a CLI, a docs page that explains a feature that was previously undocumented, a translation file for a popular i18n library, a small feature for an open source tool you actually use. The bar is "the maintainer thanked you and merged it."

On the resume, a real merged PR earns its own line in the projects section in the XYZ format: "Shipped a SQLite adapter to react-query-persist(open source, 14k stars), merged after one round of review, used by ~80 downstream projects per npm download stats." If the PR is to a project the hiring manager recognizes, that one line is worth ten bullets of generic work history.

Check 7: A README and a live link in every pinned repo

When a recruiter clicks into a pinned repo, the README is the first thing they see. A repo with no README, or with the auto-generated "# project-name" one-line placeholder, reads as abandoned. A repo with a real README that explains what the project does, how to run it, and what the result looks like reads as a shipped thing.

Each pinned repo should have, at minimum: a one-paragraph description, a screenshot or live demo link, a Tech section listing the stack, and a Run section with the install command and the start command. If the repo is a hosted app, the deployed URL goes at the top in the "About" sidebar field, where GitHub renders it as a clickable link next to the topic tags. A live link is the highest-converting element on the page. Hiring managers click it.

If you can, add a small GitHub Actions workflow that runs tests on push. The green check next to commits, and a CI badge at the top of the README, both signal that you understand quality engineering and not just code-on-paper. For a junior or mid candidate, this one detail moves you a whole tier above peers who have not bothered.

The Copilot co-author tell (the 2026 fix nobody is talking about)

Here is the 2026 detail recruiters are starting to notice and almost nobody is fixing. If you use GitHub Copilot in VS Code, your commit messages may include a Co-authored-by: Copilot trailer. This started with VS Code 1.117 in April 2024. The setting git.addAICoAuthor defaulted to all, which means every commit you made while Copilot was suggesting code got the co-author line attached.

On a personal project, this is invisible. On a public portfolio repo a recruiter just clicked, every recent commit on the master branch now visibly co-credits a bot. The signal you want to send is "I built this." The signal a Copilot trailer sends is "I prompted my way to this." Worse, if you use the Copilot Coding Agent and squash-merge its PRs, the author on the merged commit on master is github-copilot[bot], not you. From the outside, your contribution graph and commit history credit a bot for code you in fact reviewed and shipped.

The fix takes one minute. In VS Code, open Settings (Cmd+, or Ctrl+,), search for git.addAICoAuthor, and set it to off. For Coding Agent PRs, when you squash-merge, edit the commit message to set yourself as the author or add a Co-authored-by: Your Name <you@email> line so your name appears on the commit. Going forward, your public commit history credits you for your work. Do not edit history on shipped repos to retroactively remove Copilot, just fix the setting and move forward cleanly.

Your commits credit whoever GitHub renders as the author. Default that to you, not to a bot.

How to put the GitHub link on the resume itself

The link goes in the header, on the same line or one line below your name, next to your email and LinkedIn. Format it as plain text in the form github.com/yourusername, and hyperlink the same text in the PDF. ATS parsers extract text, not anchor metadata, so the text form is what the keyword and contact extraction see. The PDF stays clickable for the human recruiter who opens it after the parser pass.

Do not put your GitHub URL behind a button, an icon, or a QR code. Do not write "Available on request." Do not use a URL shortener (recruiters do not trust them, and ATS systems flag them). The same parser logic the ATS resume guide walks through is what extracts the link, and it has been trained on the plain-text pattern for a decade.

Two small extras that work, when they apply. If you have a personal site, put both the site and the GitHub URL. If you have a published npm or PyPI package, link to the package page next to the GitHub link, because npmjs.com/~yourname is a one-click jump to your published work and most recruiters appreciate the shortcut.

Five mistakes that drop your profile a tier

• The gamertag username. A 20-character handle from your Xbox Live days does not read as a professional engineer. Rename to a variation of your real name and update the URL on your resume.
• The pinned tutorial clones. A pinned calculator app, todo app, or weather-API wrapper from a YouTube course signals junior even when you are not. Pin shipped work or pin nothing.
• The day-before commit burst. Empty graph for most of a year, then a wall of green the week before you send applications. Recruiters who look at any timestamps at all see this pattern. Do not do it.
• The fork-only profile. Twelve forks of tutorial repos, no original work, no contributions to the upstream. Forking is fine when it precedes a real PR. Forks on their own count for nothing.
• The GIF-stuffed README. Animated banners, snake games eating your contributions, four widgets of stats, a typing animation, a quote of the day. The recruiter closes the tab during the loading animation. Plain Markdown wins.

FAQ

Should I put GitHub on my resume if my GitHub is empty?

No. An empty profile link reads worse than no link, because it answers "can this person ship?" with a public no. Spend two weekends pinning three projects with READMEs and a live link, fix the username, then add the URL. Or skip GitHub and put the work on a personal site instead.

Do recruiters actually click the GitHub link?

For engineering, applied research, ML, and developer-advocate roles, yes, almost always, especially for junior and mid candidates where the resume alone is thin. For senior and staff candidates, the link is checked less often but is still opened by the hiring manager once your resume passes the recruiter screen. For non-engineering roles, recruiters do not usually open it.

Should I show private contributions on my profile?

Yes, if most of your work is in private repos at your employer. The toggle is in your profile contribution settings. It shows a count of private commits per day, never the repo name or any code. The graph turns from sparse to accurate without leaking anything you are not allowed to share.

What if all my code is in private company repos?

Build one public side project, however small, that you can speak to in an interview. Make it a working tool you actually use, not a tutorial. Pin it. The rest of the case for your engineering ability lives in the experience section of the resume, in concrete outcomes (latency cut, throughput moved, incidents reduced) the recruiter can read without source code. Pair the public project with strong bullets, and the GitHub link becomes a soft credibility add rather than the whole case.

Will Copilot in my commit history hurt my chances?

Increasingly, yes, for senior roles where independent ownership is the bar. A pattern of every recent commit carrying Co-authored-by: Copilot reads as you prompting rather than building. Turn off the git.addAICoAuthor setting in VS Code, write commit messages yourself, and on Coding Agent PRs make sure the squash commit lists you as the author.

Read next

If your resume is the part you are debugging next, the 80-plus bullet examples give you the XYZ patterns for the projects section, including how to phrase a merged PR or an open source maintainer line without sounding like a stuffed resume. For the ATS side, the ATS resume guide walks through the parsers that read your link and your skills section. If your application is going through Greenhouse, which most engineering pipelines do, the Greenhouse Real Talent walkthrough explains the five buckets the recruiter sees before they ever open your file. And if you are using ChatGPT, Claude, or Gemini to rewrite the rest of your resume, the can-recruiters-detect-AI piece is the seven tells to avoid, the Copilot co-author line being a related signal from the same family.

Key takeaways

• Include GitHub on the resume only if your profile passes the 7 checks. An empty or stale link is worse than no link.
• The 6 pinned repos are your highlight reel. Pin shipped work, not tutorial clones. The pattern: three owned, one contributed, one published library, one role-relevant.
• Recruiters glance at the contribution graph for under 5 seconds. They are checking for activity in the last 6 months and for the suspicious pre-application burst.
• If your real work is in private repos, toggle on private contribution visibility. The graph counts the commits without revealing the code.
• One merged PR to a popular project outranks ten side projects of your own. The bar is "the maintainer thanked you and merged it." Skip the typo fixes.
• Turn off the VS Code git.addAICoAuthor setting. On Copilot Coding Agent PRs, make sure the squash commit credits you as the author, not the bot.
• Put the link in the resume header as plain text, github.com/yourusername, hyperlinked in the PDF for humans and parseable as text for ATS.

If you have built a few public projects and want to see how your resume reads against a real job description before you send the next application, the free CV score gives you the keyword gap and the parser readout in 90 seconds. If you want the bullets in your projects section rewritten using the same XYZ patterns recruiters actually respond to, the Glow Up rewrite does it in one pass on a free preview, including the merged-PR and open source maintainer bullet patterns from the 7-check rule above.

And if you are in the middle of the search and want to read how other engineers and career switchers got past the rejection loop, the CVHive stories page collects five long-form interviews on what they changed and what stopped working. The shipped-work-first patterns there are the same patterns the GitHub checks above are built on.