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 in a GitHub profile

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. Pinned repositories are the up-to-six projects GitHub lets you surface at the top of your profile, and as of 2026 they are the single highest-leverage real estate you control.

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.

Here's the gap between what a recruiter screens in that window and what most new-grad candidates spend their effort on:

| Profile element | Recruiter attention in a 90-second skim | Where most new grads over- or under-invest | |---|---|---| | Pinned six repos | High: the main signal | Under-invested; left as a random default set | | Bio (one line under your name) | High: read in ~5 seconds | Under-invested; vague "aspiring engineer" filler | | Working demo links | High: "I clicked it and it ran" | Under-invested; demos broken or missing | | Profile README | Medium: skimmed if present | Over-invested; badges and snake animations | | Contribution graph | Low: glanced at, rarely decisive | Over-invested; commit-streak gaming | | Non-pinned repos and forks | Very low: only if they click in | Over-invested; 30+ stale repos left public |

Read the table top to bottom and the strategy writes itself: pour your hours into the rows recruiters actually look at, and stop polishing the ones they skip. For a candidate grinding through hundreds of applications, that reallocation is the fastest way to make a profile pull its weight.

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.

A README is the markdown file GitHub renders on a repo's landing page, the first and often only thing a recruiter reads about that project. 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.

Hosting the demo is easier than it's ever been: Vercel, Netlify, Render, Fly.io, and GitHub Pages all have free tiers that put a CS new grad's project on a real URL in minutes. The friction that used to excuse a missing demo is gone in the 2026 hiring cycle. If you're tightening the rest of your application materials at the same time, our CS new-grad resume tactics for ATS guide pairs directly with this one. The resume gets you the GitHub click, and the portfolio has to land it.

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

A fork is your own copy of someone else's repository, and an empty one (a fork with zero commits of your own) signals nothing except that you clicked a button. 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 free-tier sites, or "coming soon" pages. A deployed demo is a live, hosted URL where the application runs in a browser, not a screenshot, not a recorded video, not a localhost link.

The same honesty principle carries into the room. The portfolio that earns you the interview is the one you can walk in and talk about in your own voice, every repo a thing you actually built and can explain under pressure. When you've got real projects to defend, run a mock interview against the questions a recruiter will ask about them so you're answering out loud before the live call, not rehearsing in your head.

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. Honestly, if I had one weekend before a job search, I'd spend the whole thing getting a single repo to a live, working URL and let the rest sit.

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.

A clean GitHub is one input into a larger pipeline. Once the portfolio earns the screen, the next gate is the structured loop of phone screen, technical rounds, and onsite. Walk through what that looks like in our CS new-grad interview loop guide, and when you reach the back-and-forth, how to ask a recruiter for feedback after a rejection keeps the next application sharper than the last. The portfolio's only job is to convert the click into a conversation. Everything after that is the interview, and you can practice that out loud first so the answer comes in your own voice when it counts.

Key terms

Pinned repositories

The up-to-six projects GitHub displays at the top of your profile. The primary thing a recruiter sees and the highest-leverage real estate on your account.

README

The markdown file GitHub renders on a repository's landing page. For a recruiter, it is the project description. Keep the "what it does" part to two or three plain-English sentences.

Deployed demo

A live, hosted URL where your application actually runs in a browser. Distinct from a screenshot or video; clearing the "click it and it works" bar for one project beats ten repos without one.

Fork

Your own copy of someone else's repository. A fork with no commits of your own is dead weight; a fork you meaningfully changed or now maintain is a real signal if its README says so.

Contribution graph

The grid of daily-commit squares on your profile. Glanced at, rarely decisive. Hiring managers care that your projects are real and explainable, not that your streak is unbroken.

Archiving

A non-destructive GitHub action (Settings to Archive) that adds an "Archived" banner and moves a repo out of the active sort while keeping it public. The right home for old class projects you don't want to delete.

About the author: Sam K. 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.