How to List Side Projects on a CS Resume

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. A side project here is anything you built outside coursework or a job; the Projects section is the highest-leverage real estate on a new-grad resume, so spend it on the ones that actually advance you to a phone screen.

In the 2026 hiring cycle, a CS new grad can fire off 487 applications and watch most die in the resume screen before a human reads a line. The fix is almost never more repos. It's making the two or three projects you already have legible as results. And the payoff runs past the screen: the same one-liner you write here is the project you'll walk an interviewer through out loud, so a clean Projects section does double duty toward the offer that ends the search. If you want to rehearse that walkthrough on the exact project you just listed, you can run a free practice round before the real interview.

The one-line project header

The one-line project header is the single line that names the project, describes it in a sentence, lists the stack, and links the work: the resume equivalent of a launch tweet. Each project's header sits on one 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 · Python, React, FastAPI, ClickHouse · Live

Avoid:

• Cute project names without a description ("Wormhole," but 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

The supporting bullet is the one line under the header that turns a project from a name into a signal; it carries either a usage metric or a depth indicator. After the one-line header, write 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, the kind of project a system design conversation can grow out of. 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:

1. Single section, three entries. "Projects" as its own H2, three projects each with header + one bullet.
2. Split between Projects and Open-Source Contributions. If you have substantial open-source work (not just commits, but actual merged 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. I'd rather read two projects I believe than six I have to squint at.

Which side projects help vs hurt

The line between a project that earns a screen and one that quietly costs you credibility is usually about evidence: a working link and a defensible number versus a name with nothing behind it.

| Project type | Helps your resume when... | Hurts your resume when... | |---|---|---| | Deployed app with users | It has a live link and a usage number (50-200+ users is plenty for a new grad) | It's "in progress," the link is dead, or the repo is private | | Systems / algorithms build | It shows depth, like a from-scratch Raft or a fuzzing harness with a real result | It's a half-finished homework extension with no writeup | | Open-source contribution | It's a merged PR to a known library, named with the project and the change | It's a one-line typo fix dressed up as "open-source experience" | | Tutorial clone (TodoMVC, Twitter) | You took it somewhere unusual, like real-time presence, novel storage, or scale | It's the stock tutorial output every applicant submits | | Portfolio / landing page | It's the vehicle showing other real projects | It's a cloned template with your name on it, listed as the project |

If your strongest evidence lives in your commit history rather than a deployed URL, how to build a CS GitHub portfolio for recruiters covers how to make the repo itself the proof.

How to list side projects on a CS resume, step by step

If you want a checklist to run against your resume tonight, here's the method in order:

1. Shortlist two to four projects. Pick for real users, technical depth, or closeness to the target role. Cut everything else; a focused list signals judgment, while a dump of every repo signals you can't tell your best work from your filler.
2. Write a one-line header for each. Name, one-sentence description, stack, working link, all on a single line. The stack line is also what an applicant tracking system keyword-matches, so name the real technologies.
3. Add one impact-or-depth bullet. Either a usage metric ("used by 800+ developers per month") or a depth indicator ("fuzzing harness that found two edge-case bugs over 2 million simulated runs"). Listing only the stack with no result is filler.
4. Order by relevance to the role. Lead with the closest match to the job, then the deepest project, then the one with real users, then the one that shows breadth. The first entry should answer what the recruiter is screening for.
5. Verify every link from a logged-out browser. A dead link or an accidentally private repo costs trust faster than a missing project. If the live site is down, deploy a static demo before you submit.

For the bullet wording itself, how to quantify CS project bullets breaks down the verb-result-number pattern; for the keyword side of clearing the filter, CS new-grad resume tactics for ATS goes deeper on an ATS-friendly resume.

Key terms

Side project

Software you built outside coursework or a job: a deployed app, a systems build, an open-source contribution. School work only counts here if you kept building past the deadline.

One-line project header

The single line that names the project, describes it in a sentence, lists the stack, and links the work. The resume equivalent of a product launch: name, description, stack, Live link, GitHub link.

Supporting bullet

The one line under the header that carries the evidence: either a usage metric (users, requests, adoption) or a technical-depth indicator (algorithm complexity, test coverage, dataset size). Hiding both makes the entry filler.

Impact-led vs depth-led framing

Two ways to write the supporting bullet. Impact-led leads with usage and is best when the project has real users; depth-led leads with technical scope and is best when it has none yet.

Applicant tracking system (ATS)

The software, such as Workday or Greenhouse, that parses and keyword-matches a resume against the job description before a human reads it. The stack line on each project is what it scores; the link and the number are what convince the human after.

As of 2026, a tight Projects section and a candidate who can walk through those projects out loud are two halves of the same offer. You can practice the project walkthrough before the real screen, or see the plans for unlimited reps through the 2026 hiring season. The goal isn't a longer resume. It's walking in able to say the answer in your own voice, and landing the offer that finally ends the search.

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.