Resumer

Skip to article
5 min read

Side projects on your resume: when to list them and when they hurt

Side projects can be the strongest line on a resume or a clear signal of inexperience. Here's the matrix for which projects belong and which don't.

resumeside-projectsportfolios
Side projects on your resume: when to list them and when they hurt
On this page
  1. 01The decision matrix
  2. 02What counts as a "strong" project
  3. 03How to format the section
  4. 04What the data says
  5. 05What this isn't
  6. 06Sources

Side projects are one of the most misused sections on a resume. Used well, they're the strongest single line in the document — proof you can ship the kind of work the job requires. Used badly, they signal inexperience, distraction, or time the candidate shouldn't have had. Most resumes lean the wrong way.

This post is the matrix for which projects belong on the resume and which don't.

The decision matrix

Should this side project be on your resume?

Decision matrix
Career stage (junior → senior)
Junior + strong project
  • List prominently — top of the work section
  • Substitute for thin internship history
  • Two or three projects, each detailed
Senior + strong project
  • Worth listing if highly relevant to target role
  • Position as career bridge or pivot proof
  • One project, briefly, near the end
Junior + weak project
  • Include only if you have nothing stronger
  • Better than blank space, worse than real work
  • Treat as portfolio filler, not selling point
Senior + weak project
  • Skip
  • Reads as having time you shouldn't have
  • Senior resumes don't benefit from hobby projects
Project quality and relevance (low → high)

Two questions decide whether a side project earns a line:

  1. What's your career stage? Side projects do very different work on a junior resume than on a senior one. A 22-year-old's portfolio project is evidence of capability. A 42-year-old's hobby project is filler at best and a question mark at worst.

  2. How strong and relevant is the project? "Strong" means real users, measurable impact, or visible craft. "Relevant" means the project demonstrates the skill the role requires — not a parallel skill, not an adjacent one, but the actual skill.

The four quadrants:

Junior + strong project. List prominently, near the top of the work section. For new grads and career-changers, a strong shipped project is often the most credible thing on the resume — more credible than an internship at a brand-name company, because the project demonstrates execution rather than proximity. Two or three projects detailed at length beat a longer thin work history.

Senior + strong project. Worth listing if highly relevant — especially when it bridges your work history to a new role, demonstrates a skill your day job doesn't show, or proves a pivot. One project, briefly described, near the end of the resume. Senior candidates don't lead with side projects; they use them as a closing argument.

Junior + weak project. Include only if you have nothing stronger. A todo app from a bootcamp is filler. It's better than blank space but worse than real internship work. Don't oversell it; let it occupy a small bullet block and move on.

Senior + weak project. Skip. A senior resume with hobby projects in it raises a small question about how the candidate has been using their time — and a senior hire doesn't need to demonstrate basic capability. The work history does that. Hobby projects on a senior resume often hurt more than help.

What counts as a "strong" project

Projects worth listing vs. projects that backfire

Side by side
Strengthens the resume
  • Shipped product with real users or measurable impact
  • Open-source contributions to known projects (commits, not stars)
  • Project demonstrating skill the work history can't (pivot evidence)
  • Project tied to a domain or industry you're targeting
  • Project with an accessible demo, repo, or write-up
Weakens it
  • Tutorials completed (todo apps, weather apps, calculator apps)
  • Forked repos with no original contribution
  • 'Concept' projects that were never built
  • Side projects that compete with or duplicate your current employer's work
  • Six abandoned projects listed as if they all shipped

The line between strong and weak isn't about complexity — it's about reality. A simple project that real people use beats a sophisticated project that nobody has touched.

Strong:

  • Shipped product with real users, even at small scale. A scheduling tool used by five clinics. An open-source library that has 200 downloads a week. A newsletter with 800 subscribers.
  • Open-source contributions to known projects — commits, not stars. Issues filed and PRs merged into projects the recruiter recognizes (or that you can name credibly) are real signal.
  • Projects that bridge to a target field. A pharmacist's HIPAA-compliant intake form when pivoting to healthcare-product is meaningful precisely because it crosses fields.
  • Projects with an accessible demo, repo, or write-up. The recruiter can click through and see the thing. No demo = effectively no project.

Weak:

  • Tutorials completed. A todo app, a weather app, a calculator app, the third react-tutorial project. These show you completed a tutorial. They don't show you can ship.
  • Forked repos with no original contribution. Stars and forks aren't contributions.
  • "Concept" projects that exist only as a description or Figma file. If it's not built, it's not a project for resume purposes.
  • Side work that competes with your current employer. List anything that crosses an IP or non-compete line and you've created a question you'd rather not have asked.
  • Six abandoned projects, listed as if they all shipped. The recruiter will check one; if it doesn't work, the credibility of all six drops.

How to format the section

For junior candidates leaning heavily on projects:

Projects

ClinicIntake.app — HIPAA-compliant intake form for small clinics. ~1,200 forms processed; used by two clinics in the Bay Area. Built in Next.js, Postgres, AWS. https://clinicintake.app

pgmigration — Open-source CLI for managing Postgres migration order across environments. 340 weekly downloads on npm. Contributed by 4 other developers. https://github.com/...

Two projects, four lines each. The project name, the one-sentence description, the credible scale or scope, the link.

For senior candidates listing one bridging project:

Selected outside work — Built and maintain clinic-intake-toolkit, a Postgres-backed intake form used in three Bay Area clinics. Used during a 2024 pivot from clinical pharmacy to healthcare-product. https://github.com/...

One line, with context. The "during a pivot" framing signals deliberateness rather than dabbling.

What the data says

Strong side projects beat a credential for early-career hiring

Audit data
1.4× callback.In matched-resume studies for early-career technical roles, candidates with one shipped, accessible side project receive roughly 40% higher callback rates than otherwise identical candidates without one.

The effect is concentrated in fields where the work itself is verifiable — software, design, data, writing. A shipped side project gives the recruiter something to look at instead of guessing whether the candidate can actually do the work. The effect is largest for junior candidates with thin work history; it's much smaller (sometimes nothing) for senior candidates whose work history already demonstrates capability. Importantly, the effect is conditional on the project being real and accessible — a list of project names without links produces no callback bump.

Source · GitHub Octoverse hiring research and matched-resume audit studies in technical recruiting

Audit studies for early-career technical roles show that one shipped, accessible side project lifts callback rates by roughly 40% over otherwise identical resumes without one. The effect concentrates in fields where the work itself is verifiable — software, design, data, technical writing. The recruiter clicks the link, sees a real thing, and updates their assessment.

The effect is largest for junior candidates with thin work history. It's much smaller — often nothing — for senior candidates whose work history already demonstrates capability. And it's conditional on the project being real. A list of project names with no links or demos produces no callback bump and sometimes slightly worse outcomes (the recruiter wonders why nothing is linkable).

The implication for senior candidates is unintuitive but consistent: side projects mostly don't help your senior resume. They neither prove nor disprove what your work history says about you, and they sometimes raise a question about how you've been using your time. The exception is the bridging project that proves a pivot — that's strong and worth listing.

For the related question of how to position internships and short-term work that lives in similar territory, see achievements-vs-responsibilities. For the broader question of when a portfolio belongs alongside the resume, see design-resume-portfolio-vs-pdf.

What this isn't

A few clarifications:

  • It's not a rule that side projects help every candidate. They help juniors with strong projects. They don't reliably help anyone else.
  • It's not the same as a portfolio. A portfolio is a separate deliverable that lives at a URL. Side projects on the resume are line items. Don't list six items on the resume and then re-list the same six in the portfolio — that signals you're padding.
  • It's not a license to oversell a tutorial. "Built a full-stack app" is technically true of a todo-app tutorial. It's not the framing that survives a follow-up question. Use language proportional to what the project actually is.

The short version: junior with strong project — list prominently. Senior with strong, bridging project — list briefly. Junior with weak project — list small if necessary. Senior with weak project — skip. The recruiter is going to click the link; make sure there's something there.

More to read