SS
Key Takeaways
- A side project earns its place when it proves a skill your work history cannot - otherwise it competes with stronger evidence for the same space.
- Tutorial follow-alongs read as coursework; a project only counts when you made decisions someone could disagree with.
- Write projects the way you write jobs: action, technology, scale, outcome - not a list of frameworks.
- One finished, deployed project outperforms four abandoned repositories, and reviewers can tell the difference instantly.
- If a project has a live URL or repository, the link must survive PDF export or the evidence never reaches the reader.
The advice you usually hear is "add side projects to your resume." That is only half right. Side projects can be the strongest section on a junior resume and dead weight on a senior one, and the difference comes down to what the project proves that nothing else on the page does.
This guide covers which projects to keep, how to write them so they read as engineering rather than hobby work, and when to cut the section entirely.
If you want to know whether your current resume is even reaching a human, start with the free ATS score checker.
When Side Projects Belong on Your Resume
Projects earn space in four situations:
You are early career or a fresher
With little or no professional history, projects are your evidence. They are frequently the only place a reviewer can see how you actually work. See the fresher resume guide for how the rest of the page should support them.
You are changing fields
A project is how you demonstrate the new skill before anyone has paid you for it. Someone moving from finance into data work has no professional analytics history - a well-documented analysis project fills that gap. The career change resume guide covers how to frame the rest.
Your job does not show the skill the role wants
You maintain legacy systems at work but the job asks for modern infrastructure. A project is your only proof.
The project is genuinely notable
Real users, adoption, or recognition. A tool with a thousand downloads is not a side project, it is a product, and it belongs near the top.
When to cut the section: you have eight years of directly relevant experience and the projects are small. At that point every line spent on a weekend build is a line not spent on the work someone paid you to do.
Which Projects Actually Count
The test is simple: did you make decisions someone could disagree with?
Projects that count
- You chose an architecture and could defend it
- You handled a real constraint - cost, latency, scale, bad data
- You shipped it somewhere other people could reach
- You solved a problem you personally had
Projects that do not
- A tutorial you followed to completion
- A course capstone identical to the other three hundred submissions
- A to-do app, weather app, or calculator with no distinguishing feature
- A repository with one commit and no README
That last category matters more than people expect. Reviewers open the repository. A project with no explanation and a single commit actively hurts, because it suggests you either did not finish it or did not think it worth explaining. The GitHub profile guide covers what they see when they land there.
The tutorial problem, and how to fix it
If your only projects are follow-alongs, do not discard them - extend them. Take the course project and add something the tutorial did not: authentication, a different data source, a deployment pipeline, a test suite. The moment you make a decision the tutorial did not make for you, it becomes yours.
How to Write a Project Entry
Most project sections read like this:
Weather App - React, Node.js, MongoDB, Express A weather application using React and the OpenWeather API.
That is a technology list with a sentence attached. It tells a reviewer nothing about your judgment.
Write projects the same way you write jobs - action, technology, scale, outcome:
Weather App | React, Node.js, Redis Built a forecast dashboard serving 400+ daily users, cutting API costs 80% by caching upstream responses in Redis with a 10-minute TTL.
The second version answers what you did, what you used, how big it was, and what happened. Same project, completely different signal. The technique is identical to the one in how to write resume bullet points, and the numbers matter - see how to quantify achievements on your resume.
What to include per project
- Name and stack on the title line
- One to three bullets, each with a decision or an outcome
- Links to the live site and the repository
- Dates if recent; omit if the project is old enough to date you
Numbers you probably have
Candidates say they have no metrics, then produce five in conversation. Users, records processed, response time, test coverage, downloads, repository stars, hours saved, cost avoided. Do not invent them - but do go looking, because most people have more than they think.
How Many, and Where to Put Them
How many: two to four. Below two the section looks thin; above four it starts crowding your actual experience.
Where:
- Fresher or career changer - directly under education, above any unrelated work history
- Experienced and relevant - after experience, before education
- Experienced and marginal - cut it, or reduce to a single line
Order by relevance to the job, not by how proud you are of them. The strongest project for a backend role may be the third-favourite one you built. This is the same tailoring judgment covered in how to tailor your resume for every job.
Making the Links Work
A project entry without a working link asks the reviewer to take your word for it.
Link both the live deployment and the repository where both exist. They answer different questions - does it work, and can you write code.
Check the link survives export. This trips up more candidates than any other item here. Many templates render a link as anchor text - the word "GitHub" pointing nowhere - or drop the hyperlink entirely when the resume is exported to PDF. Open your finished PDF and click every link. If it does not navigate, it does not exist.
Keep deployments alive. A free-tier app that sleeps after inactivity may take thirty seconds to wake, and reviewers do not wait. If a project is on your resume, make sure it loads.
More on placement in how to add a portfolio link to your resume.
Common Mistakes
Listing frameworks instead of outcomes. "Used React, Redux, and Tailwind" describes a stack, not work.
Including everything you have ever built. Curation is a signal in itself.
Projects that contradict your target role. Five game projects on a data-engineering application suggests your interests point elsewhere.
No README. The reviewer clicks through and finds nothing explaining what they are looking at. Twenty minutes fixes this.
Stale projects. A project last touched three years ago, listed above recent work, invites the wrong question.
Claiming team projects as solo. If four people built it, say so and state what you owned. Being caught inflating a project is far worse than the project being smaller than someone assumed.
Frequently Asked Questions
Should I include side projects if I have 10 years of experience?
Usually not, unless a project is genuinely notable - real users, open-source adoption, or a skill your work history does not show. At that level your professional record is the stronger evidence, and space is limited.
Do hiring managers actually look at the projects?
Technical hiring managers frequently do, particularly for junior roles where there is less work history to assess. They tend to open the repository rather than read the bullet, which is why the README matters as much as the resume line.
Can I include unfinished projects?
Only if the finished part stands alone and you are honest about scope. "Built the ingestion pipeline and API; frontend in progress" is fine. A half-built app presented as complete is not, and it will surface in the interview.
How detailed should each project be?
One to three bullets. If it needs more, it is a portfolio piece - link out to a full write-up rather than expanding the resume. See the portfolio guide.
What if my projects are all from a bootcamp?
Extend at least one beyond what the curriculum required, so it stops looking like everyone else's submission. A single differentiated project is worth more than four identical capstones.
Want to know whether your projects section is helping or padding? Check your resume's ATS score free.
Make This Practical
Start by cutting. Remove any project you could not discuss for five minutes, and any tutorial you did not extend. Two strong entries beat five weak ones.
Then rewrite what remains as action, technology, scale, outcome - using how to write resume bullet points and how to quantify achievements on your resume. Add a README to every linked repository, following the GitHub profile guide.
Finally, verify the evidence reaches the reader. Export to PDF, click every project link, then run the file through the free ATS score checker and tailor the section per role with how to tailor your resume for every job.
Templates that keep this structure intact
This template is ATS-tested — start from it and the formatting rules in this guide are already handled.
Was this guide useful?
Be the first to rate it.
