Side Projects for Your Software Engineering Resume: Which Ones Actually Help
Published ยท Finch Team
Updated
Not all side projects are equal on a resume. A CRUD to-do app in React tells a recruiter roughly the same thing as no project at all. A scraper that processes 50k records and stores them in a normalized PostgreSQL schema tells them something real. The difference isn't the language or framework. It's the complexity, the decisions you made, and whether you can talk about it for 10 minutes without running dry.
This post is about which side projects for a software engineering resume actually move the needle, how to pick what to build, and how to write about it so the work speaks for itself.
What Makes a Side Project Resume-Worthy
A side project earns its spot on a resume when it demonstrates at least one of these four things:
1. You made real engineering decisions. Not "I followed a tutorial" but "I chose PostgreSQL over MongoDB because I needed relational constraints" or "I switched from polling to WebSockets after measuring the latency overhead." Recruiters can tell the difference when they ask questions in interviews.
2. It works and is deployed. A project that runs live carries more weight than one that "works locally." Deployment forces you to handle environment config, secrets management, and production behavior. It's also a link you can send.
3. You built something with non-trivial scale considerations. Even if only 5 people use your app, if you designed it to handle 10x that, you've demonstrated systems thinking. Write those numbers in your bullets.
4. It involves a domain-relevant technology. A backend role cares about your database design. An ML role cares about your model training pipeline. A full-stack role cares about your end-to-end architecture. The project should match what you're applying for.
If your project doesn't hit at least two of these, it might not be worth the real estate on your resume. One strong project beats four weak ones every time.
The 5 Project Types That Actually Impress Recruiters
1. Something With Real Data at Non-Trivial Scale
Scraping, ETL pipelines, data processing scripts: anything that touches significant data and requires thinking about performance, storage, or correctness.
Example: A Wikipedia data pipeline that fetches page revision histories via the Wikimedia API, normalizes author/timestamp/diff data into a PostgreSQL schema, and runs a word frequency analysis job overnight on 2 million revisions.
Why this works: It shows you understand databases, can handle pagination and rate limiting, think about data normalization, and have written code that actually runs on real production data from the internet.
What to write on your resume:
Built a Wikipedia revision analysis pipeline using Python, PostgreSQL, and the Wikimedia API. Processed 2.1M page revisions, normalized into a 4-table schema with indexed author IDs. Scheduled nightly batch jobs via cron with retry logic for failed API pages.
2. A Full-Stack App With Auth and State
Not a static site. Not a frontend with mocked data. A real app where users sign up, log in, and their data persists.
Example: A study group coordination app where CS students at your school post sessions by course, others sign up, and the calendar syncs to Google Calendar. Users, sessions, enrollments, notifications.
Why this works: Auth, sessions, database relationships, and a real deployment are things every working software engineer deals with. Showing you've handled all of them signals readiness to contribute to production codebases.
What to write on your resume:
Built a study group scheduling app using React, Node.js/Express, and PostgreSQL with JWT auth, Google Calendar OAuth integration, and email notifications via SendGrid. 180 registered users across 3 CS courses during pilot semester.
3. A CLI Tool or Developer Tool
Tools that solve a problem you had as a developer. A script that generates boilerplate, a local dev environment manager, a test data generator, a code formatter for a language that doesn't have one.
Why this works: Developer tooling shows you write code for other developers, which is what you'll do in most engineering jobs. It also tends to produce cleaner, more thoughtful code because the "user" is technically sophisticated.
Example: A CLI tool in Go that reads a Postgres schema and generates TypeScript interface types and Zod validation schemas. Input: a database URL. Output: ready-to-use TypeScript types.
What to write on your resume:
Built a Go CLI tool that introspects PostgreSQL schemas via information_schema and generates TypeScript + Zod validation schemas. Handles nullable columns, JSON fields, enums, and composite keys. Used in personal projects across 3 repos.
4. An ML or Data Science Project With Real Evaluation
Not a Jupyter notebook that runs on a public dataset and gets "good accuracy." A project with a real pipeline: data collection, feature engineering, model training, evaluation on held-out data, and ideally a deployment endpoint.
Example: A model that predicts whether a CS department job posting is an internship, new grad, or senior role based on the job description text. Trained on 8,000 scraped LinkedIn postings, evaluated on a held-out test set, deployed as a FastAPI endpoint.
Why this works: Model training is a small part of an ML project. The data collection, cleaning, feature engineering, and deployment are where the real engineering lives. Showing you did all of it is far more compelling than "fine-tuned BERT on a Kaggle dataset."
What to write on your resume:
Built a job level classifier using scikit-learn (TF-IDF + logistic regression) trained on 8k LinkedIn postings. Achieved 87% classification accuracy on 3 levels. Deployed as a FastAPI endpoint on Railway with Prometheus metrics tracking prediction confidence distribution.
5. An Open-Source Contribution to an Active Project
Not a fork you made changes to privately. A contribution that was merged into a project with real users.
Why this works: Contributing to someone else's codebase demonstrates skills that solo projects can't show: reading unfamiliar code, following contribution guidelines, responding to code review, writing tests that pass someone else's CI. These are day-one job skills.
Finding contribution opportunities:
- Search GitHub for repos with "good first issue" labels in languages you know
- Look at libraries you already use in your projects and check their issues list
- Documentation improvements, test coverage increases, and bug fixes with clear reproduction steps are all realistic first contributions
What to write on your resume:
Contributed cursor-based pagination to [Library Name] (3.4k GitHub stars). Added offset and cursor parameters to 4 list endpoints, wrote 18 unit tests, updated API docs. Merged after 2 review cycles.
Projects That Sound Good But Don't Help Much
The tutorial project. If you followed a YouTube tutorial to build something and the code structure is identical to the video, recruiters will often recognize it. Tutorial projects are fine for learning but should be replaced by original work before they go on your resume.
The to-do app. React to-do list, Python Flask to-do API, Node to-do app: there are millions of these. It shows you can follow a basic tutorial structure but tells a recruiter nothing about your engineering judgment.
The "I want to build this eventually" description. Don't put aspirational projects on your resume. If it doesn't have a GitHub link or a live URL, it doesn't go on the resume.
The project with 0 commits after the initial push. Recruiters sometimes look at GitHub activity. A project with one commit and no activity reads as "I started this and gave up." Either finish it or remove it.
The generic blog or portfolio site. Unless it does something technically interesting (custom CMS, WebSocket real-time features, serverless edge functions with interesting cache logic), a personal website does not belong in the Projects section of a software engineering resume.
How to Write Projects That Show Depth
The bullet formula for projects is the same as for work experience: what you built, what technology decisions you made, and what happened (metrics, users, performance, scale).
The mistake most students make is describing their projects at the product level instead of the engineering level.
Product level (weak):
Built a recipe management app where users can save, categorize, and search their recipes.
Engineering level (strong):
Built a recipe management app using React, Django REST Framework, and PostgreSQL. Implemented full-text search using Django's tsvector indexing with weighted rank for ingredient vs title matches. 800ms p95 search latency on 10k recipes in testing.
The second version demonstrates database knowledge (full-text search, tsvector, query planning), tells you the person measured performance, and gives a concrete scale number. You'd ask a completely different interview question after reading that.
When you write your project bullets, ask yourself: "Could this describe a project in a CS101 tutorial?" If yes, you need to add more engineering specifics.
How Many Projects Do You Need?
Two to three strong projects beat six mediocre ones. On a one-page resume, each project should have 2-3 bullets. That means two projects takes up 6 lines, which is roughly right for someone with 0-1 internships.
If you have an internship, your projects section competes with your experience section for space. One strong project plus the internship bullets is usually the right call. See our guide on keeping your resume to one page for how to handle the tradeoff.
If you have no internships yet, three projects (full-stack, data/backend, one open-source contribution or tool) is the target. That's enough to write a resume that isn't empty.
Your GitHub Profile Matters as Much as Your Resume Bullets
Project bullets get you through the resume screen. Your GitHub is what a technical interviewer actually looks at.
When we built Finch's first version, a resume generator, it read students' GitHub repos to find which ones had real engineering substance (commit history, non-trivial code, documentation, real project structure) and pulled the strongest bullet material from the actual code. It could find things students had done but hadn't thought to put on their resumes. Reread your own repos with the same eye.
For this to work, your repos need to be public and have actual code and commit history, not just a README. Treat your GitHub repos the same way you'd treat the projects section of your resume.
For more on making your GitHub presence work for your applications, check out our GitHub on resume guide.
One Last Thing: Build What Interests You
The best projects on your resume are projects you actually wanted to build. Recruiters can tell when someone built something to check a box versus something they genuinely wanted to exist. The enthusiasm in how you describe it in an interview (or the depth of technical decisions you made because you cared about the outcome) comes through.
Build something that solves a problem you have. If you hate manually updating spreadsheets, automate it. If you think search at your university is terrible, build a better one for a subset of data. If you use a library with a missing feature that annoys you, add it.
The skill-building and the resume outcome are the same project. You just also have something to talk about that you cared about.
And once you have strong projects, put them in front of the right roles. Each week Finch picks the 3 internships or new-grad roles that fit your major best and says why each one fits, so you know which applications should lead with which project.