What Signal Does a Side Project Actually Send?
The assumption most candidates make about side projects is that having them is good and more is better. Neither of these is quite accurate. A side project sends a signal, but the signal depends entirely on what the project is, how it is presented, and what role you are applying for.
At its best, a side project demonstrates that you care enough about your work to do it outside of the hours you are paid for, that you can ship something independently from start to finish, and that your skills extend beyond what you describe on a resume. These are genuinely valuable signals for roles where initiative, technical depth, and shipping discipline matter.
At its worst, a side project that is poorly documented, never shipped, built with technologies that have no relevance to the role, or presented without any context about why you built it tells the hiring team very little useful. The project exists. That is about all that is communicated.
What Kinds of Projects Matter for Which Roles
Different roles have different expectations about what side project work signals, and optimizing for the wrong type of project for the role you are targeting is a real way to waste significant time.
For software engineering roles, especially those that emphasize systems thinking, code quality, and independent execution, a completed project that solves a real problem, has clean code, reasonable test coverage, and a README that explains the technical decisions is meaningful. A project that uses a new framework you are claiming proficiency in is particularly useful if the role involves that technology and your employment history does not include it yet.
For product management and design roles, side projects that demonstrate product thinking, user research, and iteration based on feedback are far more relevant than technically impressive builds. A PM candidate who built a simple app and documented the user interviews that informed its features, the iterations they made based on early feedback, and the metrics they tracked is showing more PM-relevant thinking than a PM candidate who built a technically sophisticated tool with no documented user insight behind it.
For data and analytics roles, a project that involves acquiring messy real-world data, cleaning and analyzing it, and presenting findings clearly is high signal. Publishing analyses on a blog or portfolio, contributing to a Kaggle competition with a clear writeup of your approach, or building a dashboard that visualizes public data in an interesting way all demonstrate the core data workflow in a way that a list of tool proficiencies cannot.
For creative and communication roles, portfolio work is the primary evaluation signal, and the absence of a portfolio is a genuine disqualifier for most hiring managers. But portfolio quality matters more than portfolio quantity. Three excellent pieces that demonstrate range, craft, and thinking about audience are worth more than twenty pieces of inconsistent quality.
What Recruiters and Hiring Managers Actually Look At on GitHub
For technical roles, candidates frequently list their GitHub profile and expect hiring teams to review it carefully. The reality is that most recruiters are not going to review your GitHub in depth, and many hiring managers are too busy to go through repository after repository unless a recruiter or colleague has flagged a specific project as interesting.
What does get looked at: your pinned repositories, because they are the most visible by default. Your contribution graph, which is used as a rough proxy for coding activity (though this is a flawed signal that discriminates against people who work in private repositories and people who contribute to non-code parts of a project). The README of any pinned repository, which should immediately communicate what the project is, why it exists, and how to run it.
A GitHub profile with three well-chosen pinned repositories, each with a clean README, a clear purpose, and readable code, is worth more than a profile with thirty repositories of inconsistent quality and sparse documentation. Curate your pinned repositories before adding your GitHub to a resume or application.
If your most significant technical work happens in private repositories (as is the case for most employed engineers), say so explicitly. "Most of my recent work is in private repositories at [company]. I can walk through specific technical decisions and challenges in detail during the interview." This is more honest and more useful than implying that your public GitHub is representative of your current work when it is not.
Presenting Project Work in Interviews
When an interviewer asks you to walk them through a side project, they are not asking for a feature tour. They are asking you to demonstrate how you think, how you make decisions, and what you have learned.
The structure that works for talking about a project in an interview: start with the problem you were trying to solve and why it interested you, then describe the key technical or design decisions you made and the alternatives you considered, then talk about what you would do differently if you started over. That last part is particularly important. "I would do X differently because I learned Y while building this" demonstrates intellectual honesty and growth orientation. "It came out exactly as planned" almost never sounds credible.
Avoid the trap of narrating everything the project does. Interviewers do not need a product walkthrough. They need to see your thinking. Go deeper on one or two decisions rather than covering everything at a surface level.
The Difference Between a Project That Demonstrates Skill and One That Just Exists
The clearest distinction between a high-signal project and a low-signal one: can you articulate why you made the specific technical or design choices you made, and were those choices made intentionally rather than by default?
A project built by following a tutorial closely, where you made no significant independent decisions, demonstrates that you can follow instructions. It does not demonstrate that you can build something from scratch. A project where you chose a specific database because of a specific tradeoff you thought about, structured the code in a way you can explain and defend, and made at least a few decisions that you would make differently if you rebuilt it today, demonstrates actually thinking about technical problems.
Projects that have real users, even a small number, are higher signal than projects that only you have used. Real users create real constraints: accessibility, performance under load, error handling, documentation, user feedback. These constraints produce better code and more interesting things to talk about in interviews. If you have a project that is public and functional, send it to five people who are not technical and watch where they get confused. Fixing those things teaches you more than most courses.
How to Present Side Projects on Your Resume
Side projects on a resume should be presented with the same specificity you would bring to describing an employment role. Not "built a web application" but "built a rental pricing tool used by 200 landlords in two cities, integrating public vacancy data with a machine learning model to suggest pricing adjustments. Built in Python with a FastAPI backend and a React frontend."
Include what it does, what technology it uses, the scale or usage if it is meaningful, and the specific technical problem it solved. If the project is publicly accessible, include the URL. If it is on GitHub with a clean README, include the repository link. If neither is true, do not list it at all or be prepared for questions you cannot answer with anything concrete.
Do not list side projects that you started but did not finish unless the unfinished state is recent and you can speak to the current state of development. Repositories that have not been touched in three years and were never completed communicate the opposite of initiative.