Side Projects and Open Source on Engineering Resumes: When to Include, How to Frame

Side projects are the most over- and under-played item on engineering resumes. New grads pad with weak personal projects (the third React todo app); senior engineers under-include substantial open-source work that would meaningfully improve their resume; mid-level engineers commonly include unfocused project lists that signal effort without depth. The rule is calibrated to your career stage: side projects matter most when they fill gaps in your work history, demonstrate skills your jobs don’t, or signal genuine engineering taste. They matter least — and can hurt — when they’re padding. This guide covers when to include them, how to frame them, and what to leave off.

The Decision Framework

Include a side project when at least one is true:

Your work history is thin and projects fill the gap (new grads, career switchers).
The project demonstrates skills your work history doesn’t (e.g., your job is backend; your project shows ML or systems work you want to be hired for).
The project has reached genuine substance: meaningful adoption, clear technical depth, or recognized contribution.
The project signals taste — code quality, design choices, write-ups — that recruiters and hiring managers can verify.

Skip a side project when:

Your work history already speaks for itself and the project would dilute the signal.
The project is shallow (the third todo app) and would be exposed in any technical conversation.
The project is incomplete or abandoned (especially if visibly so on GitHub).
You can’t talk about it for 10 minutes in detail under interview pressure.

The test for senior engineers: would you yourself, as a hiring manager, learn anything from this project that the work-history bullets don’t already convey? If no, omit.

What “Substance” Looks Like

A few qualitative signals that side projects have crossed the substance threshold:

Open source with measurable adoption

Hundreds to thousands of GitHub stars (calibrated to category — a niche networking tool with 800 stars is more impressive than a generic web template with 5,000)
Inclusion in package registries with non-trivial download counts (npm, PyPI, crates.io)
Used in production at recognizable companies
Cited in engineering blog posts, conference talks, or research papers

Personal projects with technical depth

A compiler or interpreter for a small language
A query engine, database, or storage layer with real benchmarks
An ML model deployed at scale (your own infrastructure, real users)
A system that solves a problem at non-trivial scale (e.g., scrapes and indexes 100M items, processes a real-time data feed)

Notable contribution to high-profile projects

Substantial PRs merged into Kubernetes, PyTorch, Rust compiler, etc.
Maintainership role on a project
Specific feature you championed and shipped in a major OSS project

Research or write-up component

Detailed README or blog post explaining design tradeoffs
Conference talk or video walkthrough
Paper or technical report (preprints count)

Projects with one or more of these signals belong on your resume. Projects without any of these are usually too weak to include.

How to Format Side Projects

For new grads / career switchers (substantial real estate)

“Projects” can be its own section after Experience. 2–3 projects, each with 2–3 bullets:

PROJECTS
[Project Name] — [link]                                              [Year]
- Built [what] using [stack] for [problem]
- [Outcome / scale / users / interesting technical decision]
- [Optional: notable adoption / talk / writeup]

Example:

Spectre.io — github.com/jdoe/spectre                              2024
- Built collaborative Markdown editor with WebRTC peer-to-peer sync; Yjs CRDT for conflict resolution
- 1.4k GitHub stars; deployed to 800+ active users via Cloudflare Pages
- Featured on Hacker News (#3, 2024-08-12); wrote 3-part series on CRDT design tradeoffs

For mid-level engineers (smaller real estate)

Mention 1–2 projects briefly under a “Selected Projects” or “Open Source” subsection. Keep it tight — bullets should be one-liners with the project name and a single signal of substance.

Example:

SELECTED OPEN SOURCE
- pgvector-rs (3.2k stars): Rust client for pgvector; maintainer
- Top-10 contributor to ClickHouse; merged migration tooling in v23.4

For senior+ engineers (footnote-only)

Most senior engineers shouldn’t have a Projects section at all. If you have one truly notable project (a major OSS contribution, a well-known open-source tool you maintain), include a single line:

- Maintainer, foo-cli (12k stars, used in production at Stripe, GitHub, Cloudflare)

Otherwise omit. Recruiters don’t expect senior engineers to advertise hobby projects; the work history should carry the resume.

What Hurts More Than It Helps

Tutorial-style projects

Anything that reads as “completed a course” — a Coursera capstone, a book’s sample project, a tutorial walkthrough. These signal “I’ve watched videos” rather than “I’ve engineered something.” Cut.

Generic web app demos

Todo apps, weather apps, recipe finders, basic CRUD. The third one of these on a resume signals shallowness. Cut unless you have a specific reason it demonstrates something unusual.

Half-finished projects visible on GitHub

If you list a project, recruiters often check the repo. A repo with a barebones README, no commits in 18 months, and the last commit message “wip” is worse than not listing the project. Either polish before listing or omit.

Big tech work disguised as side projects

“Hackathon project at Google” is fine if it’s framed as such; not fine if you’re trying to make it sound like an independent personal project. Be clear about context.

Listing only the project name without context

“GitHub: github.com/jdoe” with no further description is dead weight. Reviewers don’t follow links from resume PDFs reliably. Describe what it is.

Open-Source Contributions: A Special Case

Contributions to existing projects can be as valuable as personal projects, sometimes more:

One-shot PRs: if the merged PR is substantial (a meaningful feature, a non-trivial bug fix), a single bullet under Experience or in a Selected Projects section is appropriate.
Sustained contribution: “Top-20 contributor to PyTorch” or “Maintainer of [project]” carries strong signal. List it.
Drive-by typo fixes: not worth listing. The PR being merged into a famous project doesn’t itself demonstrate substance.

The substance test applies. Big repo + small contribution still equals small.

Hackathons and Competitions

For new grads and juniors, notable hackathon wins or competition placements (Google Code Jam, ICPC, Kaggle competitions, ML olympiads) are meaningful. List them concisely with placement and year. Avoid:

“Participated in” — participation alone isn’t signal
Lengthy lists of every hackathon attended
Hackathon “projects” that didn’t continue beyond the weekend (these read as one-offs)

For mid-level and senior engineers, hackathons usually drop off the resume unless you placed at a major one or your hackathon project went on to substance.

Linking Out: GitHub, Demos, Writeups

If you list a project, link to it. Recruiters who do follow links want:

A clean README explaining what the project is and why it exists
Demo or screenshots if it’s user-facing
Recent commits showing the project is alive (if applicable)
A “Built with” section listing the stack

If your repo doesn’t have these, polish before linking. The cost of a recruiter clicking through to a messy repo is higher than the benefit of the link.

Frequently Asked Questions

I don’t have any side projects. Will that hurt me?

Generally no, especially for mid-level and senior engineers. Side projects are a substitute when work history is thin or doesn’t show a particular skill set. If your work history is solid and shows the relevant skills, you don’t need projects to compensate. New grads and career switchers are the exception — they should have projects, and the projects should be substantive (not tutorials).

What about projects from school?

Acceptable for new grads if the project was substantial (a multi-month team project that produced something working) and is described accurately (“Senior Capstone Project, 4-person team, 8-month duration”). Generic class assignments — implementing a hash table for an algorithms class — don’t belong on a resume. By the time you have 1–2 years of work experience, school projects mostly drop off the resume unless they led to publications or notable open-source.

Should I list projects from my employer’s hackathons?

Sometimes, briefly. An internal hackathon project that won the company-wide event and turned into something used in production is worth a bullet. A weekend hackathon project that didn’t progress beyond the demo isn’t. Frame as “internal hackathon, [Company]” so it’s not confused with independent open-source.

Do contributions to my employer’s open-source projects count as side projects or work experience?

Both, depending on framing. If the work was part of your job (your team’s open-source library, your work-time contributions to upstream tools), it goes under work experience. If it’s after-hours contributions to your employer’s open-source that go beyond your job duties, it can also appear under projects with appropriate framing. Don’t double-list — pick one section.

How long should I keep an old side project on my resume?

As long as it’s still meaningfully relevant. A 5-year-old open-source project that’s still actively used and has continued adoption stays. A 5-year-old project you abandoned drops off when newer work supersedes it. The general curve: projects fall off the resume as work experience accumulates and as the project loses relevance. By staff level, only the most notable ones should remain.