gitGood.dev
Back to Blog

Side Projects That Actually Impress Recruiters

D
Daniel Casale
••5 min read
careerportfoliojob-search

Let's get something out of the way: nobody is going to hire you because you built a to-do app.

I'm not saying that to be harsh. Building a to-do app is a great way to learn. But if you're putting it on your resume hoping it'll set you apart, it won't. Recruiters have seen thousands of them. It's the "Hello World" of portfolio projects.

So what actually works?

The project itself matters less than you think

Here's what I've learned from talking to hiring managers and recruiters: they don't care about the idea. They care about the execution and what it reveals about you.

A weather app that pulls from an API and displays data? Forgettable. A weather app that caches results, handles rate limiting, has error states, and includes tests? Now we're talking.

The project topic is almost irrelevant. What matters is whether it looks like something a professional built or something a student threw together over a weekend.

What actually stands out

1. Projects that solve a real problem

The best side projects come from scratching your own itch. Did you build a tool because you got tired of doing something manually? That's gold.

  • A script that organizes your downloads folder
  • A browser extension that blocks distracting sites during work hours
  • A CLI tool that formats your commit messages

These aren't glamorous. But they show you think like an engineer - you see a problem and you build a solution. That's literally the job.

2. Projects with a README that tells a story

This is the easiest win and almost nobody does it well. Your README should answer:

  • What does it do? One or two sentences max.
  • Why did you build it? What problem were you solving?
  • How do you run it? Clear setup instructions.
  • What decisions did you make? Why this database? Why this architecture?

That last one is huge. A "Technical Decisions" section in your README shows you think critically, not just code on autopilot.

3. Projects with clean git history

This is a subtle one. When a hiring manager clicks into your repo, some of them will check your commits. If every commit says "fix" or "update" or "asdfasdf," that's a red flag.

Clean, descriptive commits show discipline. It shows you'd be a good teammate. Nobody wants to review a PR where every commit is "stuff."

4. Projects that are deployed

A live link beats a GitHub repo every time. It doesn't matter if it's on a free tier somewhere. The fact that you dealt with deployment - environment variables, DNS, CI/CD, whatever - shows you understand the full lifecycle of software.

Vercel, Railway, Fly.io - there are plenty of free options. Use one.

5. Projects with tests

Even a few tests make your project stand out from 90% of portfolio projects. You don't need 100% coverage. A handful of unit tests and maybe one integration test shows you understand quality.

// Even something this simple sets you apart
describe('formatCurrency', () => {
  it('formats USD correctly', () => {
    expect(formatCurrency(1234.5, 'USD')).toBe('$1,234.50');
  });

  it('handles zero', () => {
    expect(formatCurrency(0, 'USD')).toBe('$0.00');
  });
});

What to avoid

Don't clone popular apps just to clone them. A Twitter clone or an Airbnb clone with dummy data doesn't demonstrate much. If you do build a clone, add a unique twist that shows your own thinking.

Don't have 30 half-finished repos. Three polished projects beat thirty abandoned ones. If your GitHub is a graveyard of repos with one commit each, archive or delete the ones that aren't presentable.

Don't over-engineer for the sake of it. Using Kubernetes to deploy a static blog doesn't make you look smart. It makes you look like you're padding your resume with buzzwords. Use the right tool for the job.

Don't forget mobile. If your project has a UI, make sure it doesn't look broken on a phone. Recruiters check links on their phones more than you'd think.

The presentation matters

Here's something that took me too long to figure out: how you talk about your project matters as much as the project itself.

On your resume, don't just list the tech stack. Describe the impact or the interesting challenge:

Bad: "Built a budget tracker using React, Node.js, and PostgreSQL"

Good: "Built a budget tracker that categorizes transactions using pattern matching, reducing manual categorization by 80% for personal use"

See the difference? One is a shopping list of technologies. The other tells a story about problem-solving.

Start small, finish strong

You don't need a massive project. Some of the most impressive repos I've seen are small utilities with clean code, good docs, and thoughtful design.

Pick something you'd actually use. Build it well. Write about the decisions you made. Deploy it. Add a few tests.

That's it. That's the formula. It's not complicated - it just takes caring about the details. And that's exactly what employers are looking for.

More Articles