The Portfolio Audit: What to Remove Before You Start Applying

TL;DR - A messy GitHub portfolio can eliminate you before anyone reads your resume. Audit it before you start applying. - Remove (or hide) abandoned repos, tutorial completions, hello-world projects, and anything you can't explain. - Clean up broken README links, dead deployed URLs, and repos with no README at all. - Pin your 3 to 6 best projects. Make that selection thoughtful. - Write a GitHub bio that says who you are and what you're looking for in two sentences or fewer.

Most candidates prepare their resume before they start applying. Fewer think to prepare their GitHub portfolio. That's a mistake, because for technical roles, your GitHub profile is often reviewed before, or instead of, your resume.

Recruiters, hiring managers, and technical screeners can see every public repo you have. When they look at a profile full of half-finished projects, tutorial repos, and three-year-old assignments, they form a quick impression. That impression is rarely favorable.

The good news: cleaning up your portfolio takes a few hours, not weeks. And the effect is disproportionate. A clean, focused portfolio makes every project you do have look stronger.

What to Remove (or Hide)

GitHub lets you make repos private or archived without deleting them. You lose nothing by hiding work. Start here.

Tutorial completions

A repo called udemy-react-course or the-odin-project-exercises tells a reviewer that you completed someone else's instructions. That's fine for learning. It's not a portfolio piece.

This includes: - Completed online course repos - Chapter-by-chapter exercise repos - Anything where the commits are mostly "completed lesson 14"

Make these private. If you're proud of a specific project you built during a course (something genuinely original, not the prescribed end-of-chapter project), you can keep that. But the rest goes hidden.

Hello-world and starter projects

my-first-react-app, flask-hello-world, learning-typescript — these accumulate when you're exploring a new technology. They served a purpose. Now they make your profile look like a beginner's scrapbook.

Make them private. No exceptions.

Abandoned projects

A repo with 3 commits, no README, no deployed version, and a last commit date of 18 months ago signals something unflattering: you started something and gave up. Every developer has unfinished projects. You don't have to show all of them.

If the project has interesting bones and you're willing to finish it before applying, consider doing that. If not, archive or hide it.

The threshold question is simple: if an interviewer said "walk me through this project," could you give a confident, informed answer? If the answer is no, the repo shouldn't be visible.

Forks without meaningful contribution

Forking a popular open source project is fine. Having 10 forked repos with zero commits on top of them tells reviewers nothing about you. It doesn't signal open-source involvement. It just adds noise.

Keep forks only if you have actual commits or a specific reason to reference them. Otherwise, unstar and unpin.

Homework assignments and school projects

Academic repositories are a mixed case. Some school projects are actually impressive (a compiler, an OS, a database engine). If yours falls in that category, keep it. Write a README that explains what it is.

Most school assignments don't clear that bar. A data structures homework repo, a web dev class final project, a SQL assignment. These look like what they are. They're not portfolio work. Make them private.

What to Clean Up

Beyond removing things, there's a category of work worth keeping that just needs to be fixed before you show it to anyone.

READMEs

Every pinned project needs a README. Every project you plan to reference in an interview needs one. A repo with no README forces reviewers to read your code cold, without context, which most won't do.

A minimal README covers: - What the project does (one sentence) - How to run it locally - A link to the deployed version (if it's deployed) - The tech stack

A stronger README also covers why you built it and the most interesting technical decisions you made. See how to write a README that helps your portfolio for the full guide.

Broken deployed links

If your README says "Live demo: [link]" and the link is dead, that's worse than having no link at all. It suggests you deployed something once, stopped paying attention to it, and haven't looked at your own portfolio recently.

Go through every pinned project and every project you plan to mention in interviews. Click every link. If the deployed version is down, either fix it or remove the link from the README.

Inconsistent or missing commit messages

Commit history tells a story about how you work. Commits that say "fix," "asdf," "update," "changes," or "wip" (work in progress) throughout a repo suggest careless habits.

You can't rewrite the entire history of a repo without consequences. But for your main portfolio projects, it's worth doing a squash or rebase to clean up the recent history, especially if there are embarrassing commit messages near the top.

Going forward, write commit messages that describe what changed and why. See commit hygiene for your portfolio for a detailed walkthrough.

Dead branches

A repo with 15 stale branches named things like test2, new-feature-v3, and backup-main looks chaotic. Delete branches that are merged or abandoned. Keep main and any active feature branches.

What to Pin: The 3-6 Rule

GitHub lets you pin up to 6 repositories at the top of your profile. These are the first things any visitor sees. Make the selection deliberate.

Pin 3 to 6 projects. Fewer than 3 can look sparse. More than 6 isn't possible, but filling all 6 with weak projects is worse than showing 3 strong ones.

What makes a project worth pinning:

You can explain every part of it
It has a clear purpose (solves a real problem, demonstrates a specific skill, or shows technical depth)
It has a README
Ideally, it's deployed

What the mix should look like:

If you're going for full-stack web roles, show at least one project with a backend, one with a database, and one where the frontend does something interesting. If you're going for frontend roles, show range across state management, performance, or UI complexity. If you're aiming at backend or infrastructure roles, show something with API design, data processing, or systems thinking.

Don't pin 6 versions of the same kind of app. A reviewer who sees three CRUD apps with different names won't see three projects. They'll see one project built three times.

One strong project with a deployed link and a thorough README is worth more than four mediocre repos. If you only have one project you're proud of right now, pin that one and keep the others hidden while you build more. See how to pick a portfolio project for guidance on what's actually worth building.

Write a GitHub Bio That Works

GitHub gives you a few lines of profile real estate: a name, a bio, a location, a website link, and sometimes a status. Most developers leave these blank or write something vague like "software developer | learning things."

Your bio should do two things: describe what you do and signal what you're looking for.

What to include: - Your focus area (full-stack, frontend, backend, mobile, data) - Your primary tech stack (2-3 technologies) - A clear signal that you're open to opportunities

Example bios:

Weak: Full-stack developer. Passionate about code.

Stronger: Full-stack engineer (Rails, React, PostgreSQL). Open to junior SWE roles.

Also stronger: Backend-focused. Building APIs with Node and Go. Looking for my first engineering role.

The goal isn't poetry. It's clarity. A recruiter or hiring manager who sees your profile in 10 seconds should know what you do and whether you're worth reaching out to.

Your website field: If you have a personal site, link it. If you don't have one but have a strong LinkedIn, link that. If you have a deployed project worth featuring, you could link directly to the live app here.

Your profile photo: Use one. A professional photo (or at least a clear, non-blurry one) makes your profile look like a real person works on it. A default avatar reads as inactive.

The Full Audit Checklist

Print this or copy it into a document. Work through it before your first application goes out.

Remove or hide: - [ ] Tutorial completion repos - [ ] Hello-world and starter projects - [ ] Abandoned repos with fewer than 10 substantive commits - [ ] Forks with no original commits - [ ] Homework assignments (unless genuinely impressive) - [ ] Repos with embarrassing names, commit messages, or placeholder content

Clean up: - [ ] Add a README to every pinned project - [ ] Test every deployed link and fix or remove dead ones - [ ] Delete dead branches from pinned repos - [ ] Review recent commit history on pinned repos - [ ] Check that all README instructions actually work (try cloning and running the project yourself)

Pin and profile: - [ ] Pin 3-6 of your strongest projects - [ ] Confirm each pinned project has a live link or is clearly noted as in-progress - [ ] Write a GitHub bio with your stack and job search status - [ ] Add a website or portfolio link - [ ] Use a real profile photo

Final check: - [ ] Open your own profile in a private browser window and look at it as a stranger - [ ] Ask: does this profile make me want to hire this person? - [ ] Read the pinned project READMEs out loud. Do they make sense to a non-technical reader?

A Note on Timing

Don't wait until your portfolio is perfect before applying. "Perfect" doesn't exist and waiting for it is a reason not to start.

What the audit is about is removing active negatives, not achieving some ideal state. A profile with three pinned projects and no visible tutorial repos is ready. A profile with 20 visible repos, eight of which are abandoned tutorials, is not ready, regardless of the quality of the other twelve.

Do the audit once, thoroughly. Then apply. Then keep building and improving projects as you go. Your portfolio should grow alongside your job search, not be a prerequisite to starting it.

For more on making sure everything about your GitHub presence is working for you, see how to build a GitHub profile that gets you hired.

If you want a structured process for getting your portfolio and job search ready at the same time, here's how the Globally Scoped program works.