How to Build a CS GitHub Portfolio for Recruiters

How do you build a CS GitHub portfolio that actually helps you get hired?

Curate down to six pinned repos that each tell a clear story, write a two-sentence README that a non-engineer can understand, delete or archive everything that doesn't help, and put a working demo link at the top of each repo's README. The recruiter visit is 90 seconds. Design for that visit, not for a hypothetical engineer who'll clone your code.

What recruiters actually see

When a recruiter clicks the GitHub link on your resume, the page they land on shows three things above the fold: your profile picture and bio, your pinned repositories, and your contribution graph. They don't scroll. They read the bio, glance at the pinned repos, and form an impression in under two minutes.

That means almost everything in your GitHub profile is invisible to the recruiter. The fork of react from three years ago, the half-finished hackathon project, the class assignment with one commit — none of it gets seen unless they specifically click in. The leverage is in what they see in those first 90 seconds.

Step 1: Curate the pinned six

GitHub lets you pin up to six repositories. Treat these slots like real estate. Each one should:

• Be your work, not a class skeleton with your edits on top.
• Have a README a non-engineer can read in 30 seconds.
• Have a demo link or a screenshot near the top.
• Have a last-commit date within the last 12 months ideally — or a clear note about why it stopped.

If you have more than six, kill the weakest ones until you're down to six. If you have fewer than six, that's fine — three excellent repos beat six middling ones.

A useful pinned set for a new-grad CS candidate:

1. One full-stack web project — something you built end-to-end, with a deployed link.
2. One backend / API project — a service with real endpoints, documented in the README.
3. One frontend / UI project — a polished interface, ideally with a deployed link.
4. One systems / lower-level project — a CLI tool, a compiler, an interpreter, a game engine. Shows you're not afraid of the metal.
5. One open-source contribution or library — if you have one. A small published package, a meaningful PR merged into a well-known project.
6. One project that signals your domain interest — ML, distributed systems, security, graphics, whatever you're pointing your career at.

If you don't have all six categories, don't fake it. Pin the ones you have and use the bio to set context.

Step 2: Write a README the recruiter can actually read

The biggest unforced error in new-grad portfolios is a README that's either empty or full of unexplained code. Most candidates either:

• Leave it as the GitHub default ("# my-project\nA project.")
• Or fill it with installation instructions that only matter to someone cloning the repo.

Neither helps a recruiter who's not going to clone anything.

The structure that works:

# Project Name

One-sentence description of what it does and who it's for.

## What it does
2-3 sentences in plain English. No jargon.

## Demo
Link to a deployed version, OR a screenshot/GIF, OR a 30-second video link.

## Stack
3-5 bullet points: language, framework, database, hosting.

## What I learned
2-3 bullet points about the hard parts.

## Run it locally
A short, working setup section for people who want to clone.

Two sentences for "what it does." Three at most. If you can't compress what your project does into three sentences, you don't understand it well enough yet — and that's the same thing a recruiter would conclude from reading 400 words of preamble.

Per the GitHub state-of-the-octoverse report on developer behavior, repositories with a deployed demo link in the README get 4-5x more click-throughs from visitors than repos without. Demo first, code second.

Step 3: Profile bio + README + pinned section

Your profile-level README (the one that shows on github.com/your-username) is optional but worth doing. Keep it short. A good template:

# Hey, I'm [name]

CS [year/grad year] at [school] building [thing].
Currently focused on [domain] and [stack].

## What I'm working on
- One short sentence about a current project.
- Link to it.

## How to reach me
- email / LinkedIn / portfolio site

Skip the badge spam. Skip the snake animations of your contribution graph. Skip the "I love coffee and coding" tagline. A recruiter trying to read this needs to extract "what does this person do" in 10 seconds.

Your bio (the short line under your profile picture) should match. "Final-year CS student. Backend + distributed systems. UC Davis '26." beats "Aspiring software engineer passionate about technology." Specificity converts.

Step 4: Clean up what's visible

Most new-grad GitHub profiles have 30+ repos and only six of them matter. The other 24 hurt you in two ways: they dilute the visible profile, and a recruiter who pokes around might land on the half-finished homework repo first.

Three actions:

Archive everything that isn't pinned and isn't actively maintained. Archiving (Settings → Archive) is non-destructive — the code stays public if it was public — but the repo gets a clear "Archived" banner and moves out of the active sort. Class projects from 2022 belong here.

Make embarrassing class assignments private. If a course required you to push a homework solution, make that repo private now. The code wasn't your design and won't help you.

Delete repos with one commit and no README. They look abandoned because they are.

After cleaning, the public repo list should be navigable. If a recruiter clicks "Repositories" they should see 5-15 real projects in active or archived state, not 50 random forks and 30 abandoned class repos.

Step 5: The fork question

Forks of popular open-source projects clutter your profile and don't impress anyone. Three rules:

• Don't fork a repo just to star it. Use the star button.
• If you forked a repo and never shipped a PR, delete the fork. A fork with no commits is dead weight.
• If you forked and made a meaningful contribution that didn't get merged, write a README on your fork explaining what you changed and why. Otherwise it just looks like you cloned the project.

The exception: a fork that you actively maintain because the upstream is abandoned and you've taken over. That's a real signal. Make it clear in the fork's README that you're now the maintainer.

Step 6: The "one impressive demo" rule

If you can only get one thing right on your GitHub, get one project to the state where a recruiter can click a link and see it working. Not a screenshot. Not a video. A real URL where the thing runs.

That single working demo does more for your candidacy than ten pinned repos without one. The reason is simple: most candidates don't have one. The bar to look above-average is "the project actually works when I click the link." A surprising number of pinned repos point to broken deploys, expired Netlify sites, or "coming soon" pages.

According to HBR research on hiring signals, the single fastest-moving credibility signal a recruiter can capture from a portfolio is "I clicked it and something happened." That's the bar. Clear it for at least one project.

Step 7: How to handle code that isn't yours

Three common situations:

Group projects. Fork the team repo to your own account, label the README clearly: "Group project for [course/event]. My contributions: [list of specific files/features]." Don't claim credit for the whole thing.

Internship code. Almost certainly proprietary. Don't push it to public GitHub. In the resume, describe the impact without the code.

Tutorial code. Fine to keep as a learning record, but don't pin it. A pinned repo that's clearly a follow-along from a tutorial reads as a beginner signal.

Maintenance, not perfection

GitHub portfolios decay. A repo that was current a year ago may now have broken dependencies, expired API keys, or a dead demo. Do a 30-minute audit every quarter:

• Click every demo link on every pinned repo. Fix or remove the broken ones.
• Re-read every pinned README. Update anything that's no longer accurate.
• Archive any repo that you haven't touched in 18 months.

The portfolio that helps you get hired isn't the one with the most projects — it's the one where every visible thing still works. Recruiters read maintenance as competence.

About the author: Alex Chen is the founder of InterviewChamp.AI and writes about the modern tech interview from the inside — what changed, what works for new grads, and where the old playbook fails.