How many side projects should a CS resume include?

Two to four. Pick the ones with the most real users, the most technical depth, or the closest match to the target role — never list everything you've ever pushed to GitHub. A focused list signals judgment; a long list signals dilution.

Do school projects count as side projects?

Only if you went beyond the assignment — kept building after the course ended, deployed it publicly, or extended it past the rubric. A class project that ended at the deadline belongs in the Coursework or Education section, not in Projects.

Should I link to GitHub or a live demo?

Both when possible. Live demo first (one click, no clone-and-run friction), GitHub second. A live demo that proves the project works converts more recruiter scans than a private repo or a dead link.

What if my side project never reached real users?

List the technical scope instead of usage. 'Built a from-scratch implementation of Raft consensus in Go, including a fuzzing harness that found two edge-case bugs over 2 million simulated runs.' Technical depth beats vanity user counts.

How recent does a side project need to be to belong on the resume?

Within roughly the last 18-24 months for most new-grad and early-career resumes. Older projects need to be exceptional (real users, real revenue, or a paper-worthy result) to earn their spot.

Guide · resume

How to List Side Projects on a CS Resume

Treat each side project like a one-line product launch: name, one-line description, stack, link, and one bullet of measurable impact or scope. Two strong projects beat five hobby repos every time.

By Alex Chen, Founder, InterviewChamp.AI · Last updated 2026-05-19

How do you list side projects on a CS resume?

Treat each side project like a one-line product launch: a name, a one-sentence description, the stack, a working link, and one bullet that names either measurable impact or notable technical scope. List two to four — never every repo. The Projects section is the highest-leverage real estate on a new-grad resume; spend it on the projects that actually advance you to a phone screen.

The one-line project header

Each project's header sits on a single line:

Project Name — One-sentence description · Stack · Live · GitHub

Examples that work:

PipeNote — Markdown notes app with end-to-end encryption and offline sync · TypeScript, Rust, SQLite · Live · GitHub
Raft-in-Go — From-scratch implementation of the Raft consensus algorithm with deterministic-simulation tests · Go, fuzzing harness · GitHub
Latency Dashboard — Real-time API performance dashboard used by 200+ developers · React, FastAPI, ClickHouse · Live

Avoid:

Cute project names without a description ("Wormhole" — what is it?)
Listing technologies as the whole description ("React, Node.js, MongoDB project")
A heading with no link — recruiters lose trust in unsubstantiated projects fast

The supporting bullet: impact or technical scope

After the one-line header, one bullet that does one of two things:

Pattern A — impact-led (best when the project has users or measurable usage):

Used by 800+ developers per month; cut median onboarding time from 30 minutes to 4 by automating the OAuth handshake.

Pattern B — technical-depth-led (best when there are no users yet):

Built fuzzing harness that found two edge-case bugs over 2 million simulated network partitions; published a 12-page writeup of the design decisions.

Both patterns work; the wrong choice is hiding both — listing only "Built X using Y, Z, and Q" with no result or scope is filler. According to the Indeed Career Guide on technical projects on resumes, projects that include either a usage metric or a depth indicator (algorithmic complexity, dataset size, test coverage) convert at higher rates than projects listed only by name and stack.

How to pick which projects to list

Most CS candidates list too many projects. The rule: two to four projects, picked to do different work for you.

Project 1 — the closest match to the target role. If you're applying to a backend infrastructure role, the queue system you built belongs first. If you're applying to a front-end role, the offline-first PWA goes first.

Project 2 — the most technically deep. This is the one you can talk about for thirty minutes without running out of detail. Often the same as project 1; sometimes different. If different, list it second.

Project 3 (optional) — the one with real users. Even a small user count (50-200 users) sends a strong signal that you can ship something people use, not just something that compiles.

Project 4 (optional) — the one that shows breadth. Something in a different stack or domain than the others, to signal range.

Cut everything else. The LinkedIn Talent Blog reported that early-career hiring managers in 2025-2026 consistently flagged "too many small projects" as a weaker signal than "two or three deep projects" — depth beats volume in the screen.

Where the Projects section goes on the page

For new grads and candidates with under two years of work experience, Projects sits above Experience or right alongside it. For candidates with three-plus years of substantial work experience, Projects goes below — and gets trimmed to two entries to make room for the work history.

Two layouts work cleanly:

Single section, three entries. "Projects" as its own H2, three projects each with header + one bullet.
Split between Projects and Open-Source Contributions. If you have substantial open-source work (not just commits — actual merged-and-merged-back-into-main PRs to known libraries), list those separately. It signals real ecosystem participation.

What to leave out

Three project types that hurt more than they help on a CS resume:

The portfolio template. Cloning a portfolio template and putting your name on it isn't a project.
The Twitter clone / TodoMVC. Every CS candidate has built one. Unless you took it somewhere unusual (real-time presence, novel storage, deployed at scale), don't list it.
The unfinished SaaS. A landing page with a "join the waitlist" button isn't a project until something is built behind it.

When in doubt, ship one fewer project and let the ones you do list carry more bullets each.

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.

Frequently asked questions

How many side projects should a CS resume include?: Two to four. Pick the ones with the most real users, the most technical depth, or the closest match to the target role — never list everything you've ever pushed to GitHub. A focused list signals judgment; a long list signals dilution.
Do school projects count as side projects?: Only if you went beyond the assignment — kept building after the course ended, deployed it publicly, or extended it past the rubric. A class project that ended at the deadline belongs in the Coursework or Education section, not in Projects.
Should I link to GitHub or a live demo?: Both when possible. Live demo first (one click, no clone-and-run friction), GitHub second. A live demo that proves the project works converts more recruiter scans than a private repo or a dead link.
What if my side project never reached real users?: List the technical scope instead of usage. 'Built a from-scratch implementation of Raft consensus in Go, including a fuzzing harness that found two edge-case bugs over 2 million simulated runs.' Technical depth beats vanity user counts.
How recent does a side project need to be to belong on the resume?: Within roughly the last 18-24 months for most new-grad and early-career resumes. Older projects need to be exceptional (real users, real revenue, or a paper-worthy result) to earn their spot.