What you'll learn
Quick Answer
Pinned repos, README quality, and commit message hygiene are the mistakes most guides already cover, and they matter. This list covers nine different, less obvious ones: private best projects, commits that don't link to your account, dead forks burying real work, missing licenses, broken badges, empty bio fields, zero open-source interaction, work trapped in an organization account, and a GitHub link that never actually gets clicked.
Repo-Level Mistakes That Bury Your Best Work
Before the less obvious mistakes, one quick note: if you haven't yet sorted your pinned repositories, written real READMEs with a screenshot and run instructions, or cleaned up vague commit messages, start there. Priodemy has two full guides on exactly that ground, building a GitHub portfolio and what recruiters actually check first. Everything below assumes you've already done that, and covers what those guides don't.
- Your best project is still private. It happens more than you'd think: you build something genuinely good, keep the repo private out of habit or nerves about the code being "not ready," and forget to flip it public before sharing your profile. A private repo is invisible to anyone without direct access, no README, no pin, no commit history, nothing. Check the visibility setting on your best two or three repos before you send your profile anywhere.
- Old forks are burying your real work. Forking a big open-source project to poke around in it, or forking a course's starter repo, is completely normal. The mistake is leaving a dozen of these unpinned and unarchived, so anyone who clicks past your pinned section into the full repository list sees a wall of "forked from X/Y" tags before they reach anything you actually built. Archive what you're done exploring.
- There's no LICENSE file on your finished projects. It's a one-click addition on GitHub (Add file, choose a license, MIT is the standard default for personal projects), and skipping it reads as unfinished to anyone who's shipped real software, where a license is a basic, unglamorous expectation. It also technically means nobody, including a hiring team evaluating whether they could use or build on your approach, has a clear answer to "am I allowed to do anything with this code?"
Mistakes That Break the Paper Trail
- Your commit email doesn't match your GitHub account. If you commit using an email address that isn't added and verified on your GitHub account, GitHub can't link that commit to you, it shows up with a generic gray avatar instead of your profile picture, isn't clickable, and doesn't count toward your contribution graph. This usually happens silently, often because a work laptop or a fresh install has a different global
git configthan the one tied to your account. Rungit config user.emailin each project and check it against the emails listed in your GitHub account settings. - Your README has a badge that's been failing for months. A build-status or test-coverage badge is a nice touch, until the build has been red for half a year and nobody fixed it. A permanently failing badge sitting at the top of your README is a worse signal than no badge at all, because it's proof, in your own project, that you noticed something broken and didn't fix it. Either fix the pipeline or remove the badge.
Profile Fields Nobody Fills In
- Your bio's website or social links are empty, or lead to a dead page. The "Edit profile" screen has fields for a personal website, X/Twitter, and LinkedIn. Most students leave them blank, which is a missed, free way to give a reviewer one more path to you. Worse than leaving them blank is filling in a link to a personal site that 404s or a LinkedIn profile that hasn't been touched since a school project, a broken link actively costs you more than an empty field, because it signals neglect rather than absence.
- You have zero activity outside your own repositories. Every contribution on your profile is to a project you started yourself, no issue comments, no pull requests to someone else's codebase, nothing. That's not disqualifying for a fresher, but it does mean you have no visible evidence you can work inside a codebase you didn't write. Even one small, real pull request, a typo fix in a library's documentation, a small bug fix in an open-source tool you actually use, is worth more than it looks, because it's the only entry on your profile that proves you can operate inside someone else's rules.
Work That's Invisible From Your Personal Profile
Real project work is sitting only inside a college or company GitHub Organization account. If you built something substantial as part of a college club, a hackathon team, or an internship, and the repository lives under an organization's account rather than your personal one, it usually won't show up in your pinned repos or your contribution graph by default, even though you wrote real code and it was genuinely valuable. Link it explicitly: add it to your profile README with a short description, or fork or mirror a version, where licensing and permissions allow, so it's actually visible on the profile people are looking at.
The Mistake That Undoes Everything Else
Your GitHub link never actually gets opened. You can fix all eight mistakes above and it won't matter if your resume has "GitHub: github.com/yourname" as plain, unlinked text in a PDF that most applicant tracking systems mangle anyway, or if it's simply missing from your LinkedIn profile and your resume both. Make it an actual hyperlink wherever it appears, and put it in your LinkedIn "Contact info" section too, a polished profile that nobody clicks does exactly as much for you as no profile at all.
