How many side projects should I have on my résumé?

Two to three. One has to be genuinely strong — public link, real users, a non-trivial technical decision you can defend. The other one or two can be lighter. Eight projects on a single résumé reads as either a tutorial dump or a portfolio of unfinished ideas; neither helps.

Do recruiters actually look at GitHub?

Recruiters scan the GitHub link mostly for: does it work, does it have a real README, are commits spread across multiple weeks (not all in one push). Engineers later in the loop sometimes look more closely at the code, especially for new-grad candidates. Both audiences are looking for proof you actually wrote what you claim.

What's a 'real user' for a side project?

Anyone who used the project at least once, wasn't your immediate family, and didn't need you in the room to use it. Ten classmates who installed your tool counts. A static site with no traffic doesn't. A Discord bot in three servers counts. The bar is low, but it has to be crossed.

Should I include unfinished projects?

No. If a project doesn't have a working public link and a README, it's a draft, not a portfolio piece. Listing in-progress projects on a résumé signals you finish nothing. Save them for conversation; only ship finished items.

Guide · early-career

How to Make Your CS Side Project Portfolio Actually Impressive

Recruiters scan side-project sections for five seconds, not five minutes. The portfolio that lands interviews has one strong shipped project, not eight tutorial clones — with a public URL, real users, and a written design narrative that proves you actually built it. Depth beats breadth at every résumé screen.

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

How do you make your CS side project portfolio impressive?

Pick one project worth being known for and invest in it: a public URL, a README that explains why you built it, at least one real user outside your class, and a design-decisions section that shows your thinking. Two-to-three projects total — one strong, one or two supporting. Cut every tutorial clone and every dead-link "in progress" item. Depth beats breadth at every résumé screen.

The five-second test

Most résumés get a 30-second pass. The side-projects section gets roughly five of those seconds. A recruiter can evaluate three things:

Is there a project name that suggests it solves a real problem?
Is there a hyperlink, and does it look live?
Are the bullets specific or generic?

A pile of eight projects with generic descriptions scores 0/3. One project with a working URL, clear name, and specific bullets scores 3/3. Per the Indeed Career Guide research on entry-level résumés, bullets that lead with a verb and contain a specific result outperform descriptive ones at roughly 2x the response rate.

Pick one project to actually invest in

The biggest portfolio mistake is treating every course project as a portfolio piece. Most aren't. A course assignment 500 other students completed isn't differentiated. A solo project you scoped, built, and shipped to real users is.

Criteria for the anchor project:

Solves a problem you genuinely cared about
Scope fits 4-8 weeks of part-time work
Visible artifact — a website, a CLI tool, an extension, a bot
Can have real users you didn't have to coerce

Avoid yet another todo app, weather widget, blog clone, or HTML-résumé portfolio site. These pattern-match as filler.

The README is the actual portfolio

Most CS students treat the README as installation instructions. Recruiters treat it as the portfolio piece. A good README:

What it does. One paragraph, plain English.
Why I built it. Two-three sentences on the real problem.
Design decisions. Two-three specific architectural choices with rationale.
What I learned. Honest section on what surprised you.

The "design decisions" section is the differentiator. "I chose server-side rendering because the page needs to load fast on mobile networks; the tradeoff was a more complex deploy" is the kind of sentence that takes you from "CS student" to "person who thinks about systems."

Real users matter — even at small scale

A project with five real users beats a polished project with zero. Bar is low: classmates who installed your CLI counts, a Discord bot in three servers counts, a static site with 200 visitors counts.

How to get the first ten users without a marketing budget:

Post in your university's CS Slack or Discord
Share on r/cscareerquestions, r/programming, niche subreddits
Tweet at one person in your domain whose work the project draws on
Submit to Hacker News on a Saturday morning

You don't need it to go viral. You need to say "shipped to 12 users; got 4 pieces of feedback; iterated based on 2." That progression is what the bullet points are made of.

Write the résumé bullets in the right shape

Each side-project line follows this structure:

[Project name] — [one-line problem statement]
• Built [thing] using [stack]; [specific design choice]
• [Outcome — users, performance, completion]
• [Link: github.com/you/project · live.url]

Vague:

StudyBuddy — A web app for students • Built a full-stack application using best practices • Implemented user authentication

Concrete:

StudyBuddy — Spaced-repetition flashcard tool for CS coursework • Built using Next.js + Postgres; chose SM-2 spacing algorithm over simpler intervals • 80 active users from my algorithms class; week-over-week retention ~50%

Specificity is what makes recruiters click the link.

Two supporting projects, not eight

Beyond the anchor, list one or two supporting items — a 1-2 week build, an open-source contribution, a notable course project where you went beyond the assignment. Each still needs a link, a one-line problem statement, and a specific design tradeoff. Per The Pragmatic Engineer's writing on engineering hiring, strong junior portfolios are remembered for one or two clearly-thought projects, not for the length of the list.

Keep the portfolio alive between cycles. Open one issue per month on your anchor project. Tag the README with "Last updated: April 2026" so recruiters know you didn't ship it just for the résumé screen.

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 I have on my résumé?: Two to three. One has to be genuinely strong — public link, real users, a non-trivial technical decision you can defend. The other one or two can be lighter. Eight projects on a single résumé reads as either a tutorial dump or a portfolio of unfinished ideas; neither helps.
Do recruiters actually look at GitHub?: Recruiters scan the GitHub link mostly for: does it work, does it have a real README, are commits spread across multiple weeks (not all in one push). Engineers later in the loop sometimes look more closely at the code, especially for new-grad candidates. Both audiences are looking for proof you actually wrote what you claim.
What's a 'real user' for a side project?: Anyone who used the project at least once, wasn't your immediate family, and didn't need you in the room to use it. Ten classmates who installed your tool counts. A static site with no traffic doesn't. A Discord bot in three servers counts. The bar is low, but it has to be crossed.
Should I include unfinished projects?: No. If a project doesn't have a working public link and a README, it's a draft, not a portfolio piece. Listing in-progress projects on a résumé signals you finish nothing. Save them for conversation; only ship finished items.
How do I write the bullets for a side project?: Each bullet leads with a verb, names a specific technical decision, and ends with a measurable result. 'Built [thing] using [stack]; [specific design choice]; [outcome — users, latency, accuracy, etc.]'. Skip vague claims like 'used best practices' — they read as filler.