How to Screw Up Side Projects on Your Resume

More Projects Doesn't Mean Better

When screening resumes, I notice a lot of people assume more side projects equals a better impression. Two pages packed with projects. I get the intent to look passionate, but honestly — if all five are todo-app-level, it signals "they haven't grown beyond this point." Better to leave them off entirely.

(I had my own dark era of putting 3 todo apps on my resume as a first-year dev.)

Listing Tech Stacks Without Context Backfires in Interviews

I frequently see resumes claiming one project used "React, TypeScript, Tailwind, Zustand, React Query, Prisma, PostgreSQL, Docker, AWS." Looks impressive, sure. But in the interview, Docker turns out to be copy-pasting a Dockerfile from a blog post, and AWS was just uploading images to S3.

"Reduced unnecessary network requests by 63% using React Query's API caching" and "Used React Query" send completely different messages. What matters is what problem you solved with that technology.

The Clone Coding Trap

Netflix clone, Instagram clone, Carrot Market clone. Great for learning, but on a resume they read as "followed a YouTube tutorial." When I ask in interviews "did you design this part yourself?", most people can't answer.

A smaller project that solves a real problem you actually had is far more powerful. An app showing cafe seat availability because you were tired of finding no seats, a medication reminder bot because your parents needed one. These projects give you unlimited material for interviews — why you built it, what was hard, how people reacted.

Undeployed Projects Are Half-Finished

A project with only a GitHub link and no live URL loses half its credibility. Deploying to Vercel or Cloudflare Pages takes 10 minutes. "A project that only runs locally" reads the same as "a project I didn't finish."

The experience of managing environment variables and setting up HTTPS during deployment is also worth highlighting. Skipping that step is a missed opportunity.

A Shocking Number of People Leave the Default README

You click into the repo and it still says "Getting Started with Create React App." This signals someone who doesn't care about details. Two or three screenshots, a 3-line feature summary, a couple lines on tech decisions, and setup instructions — that alone transforms the impression. Thirty minutes on a README is more effective for your resume than 10 lines of code.

What I Recommend

One-line project description, the problem you tried to solve, 1-2 key technical decisions, and results/lessons learned. Write each in 1-2 lines. A single sentence like "I considered Context API for state management but chose Zustand due to re-rendering issues" serves as evidence of technical understanding.

(Though I only started writing mine this cleanly in my 4th year. Before that, it was all tech stack lists.)

One deep project beats ten shallow ones. If you ran a single project for 6 months — incorporating user feedback, improving performance, handling incidents — that alone can fill a 30-minute interview. Whether you had 5 users or 50 doesn't matter.