Side Projects, Open Source, and What Counts

Two contradictory beliefs circulate about side projects. One says they’re essential — that no serious engineer arrives without a GitHub full of work. The other says they’re irrelevant and only professional experience counts.

Both are wrong in the same way: they treat “side project” as one category. It isn’t. A library that four hundred people depend on and a to-do app from a tutorial are not the same artefact, and reviewers don’t read them the same way.

When a projects section earns its place

You’re early career. New graduate, bootcamp leaver, or one internship in. Your projects are your primary evidence and they should be prominent, above work experience. Nobody expects otherwise.

Something you built is genuinely used. By other people, at any scale. A tool with real users, a library with dependents, a plugin someone else installed. This is the strongest case, and it stays worth including no matter how senior you get.

Your day job doesn’t demonstrate what you’re applying with. The classic version: you write closed-source enterprise Java and you’re applying for a systems role. Your projects are the only evidence available for the skills in question, so they matter.

You’re changing specialism. Moving from frontend to backend, from application code to infrastructure. Same logic — the evidence lives outside your job history.

There’s a gap to fill. If you were out of work for a period and built something during it, that’s a much better entry than an unexplained hole.

When it doesn’t

You have five-plus years of relevant professional experience and your projects are tutorial output, coursework, or a to-do app.

In that situation the projects section is actively harmful. Not because building a to-do app is bad, but because it competes for attention with the thing you actually want read. A reviewer with limited time who lands on “Personal Portfolio Website — React, deployed to Vercel” halfway down the page of a senior engineer has learned nothing and lost thirty seconds.

Space on a resume is zero-sum. Every line has to beat the line it displaced.

What reviewers actually look at

Assume a reviewer gives your projects one pass, not a study — enough to form an impression and move on. Here’s roughly what they’re checking, in order:

Does it do something real? A tool that solves an actual problem beats a demonstration of a framework. “A CLI that diffs two Terraform plans and highlights destructive changes” is instantly interesting. “A blog built with Next.js” is not, because the blog isn’t the achievement, and everyone has one.

Is it finished? A small, complete, working thing beats an ambitious half-built one every time. Half-built projects are common and they signal the opposite of what you want.

Is there a README? This is the single highest-leverage thing you can do to a repository. A reviewer clicking your link lands on the README, and if it explains what the project does, why it exists, and how to run it, they’ll form a favourable impression before reading a line of code. If it’s the default framework scaffold text, they’ll close the tab. Many otherwise-good projects fail here.

Does the code look like production code? Not perfect — but tests where tests make sense, some error handling, sensible commits, no committed credentials. A reviewer is trying to infer what you’d be like on their codebase.

Did you build it or follow it? A project that’s recognisably a well-known tutorial’s output reads as coursework regardless of how you label it.

How to write a project entry

Same discipline as a job bullet. Three lines maximum.

Weak:

Weather App — A weather app built with React and the OpenWeather API. Technologies: React, JavaScript, CSS, Axios.

Better:

tfdiff — CLI that parses Terraform plan output and flags destructive changes before apply. Written in Go; used by my team’s CI to block accidental deletes. ~40 stars, three outside contributors.

The second one names a real problem, says who uses it, and includes an honest scale signal. It also doesn’t bother listing “Go, CLI, Cobra” as a technology roster — the technology is obvious from the description.

Include a link. If the code isn’t public and can’t be, say so in half a clause and describe it anyway rather than dropping it.

Open source contributions

Contributions carry weight — but only if you say what you contributed. “Contributor to Kubernetes” could mean a typo fix in the docs.

Weak: Open source contributor — Kubernetes, Prometheus, various.

Better: Contributed the --dry-run=server flag handling to kubectl’s apply path (three merged PRs, 2024); occasional bug fixes to the Prometheus Go client.

Specificity does two things. It’s checkable, so it’s credible. And “got a non-trivial change through the review process of a large project” is a genuinely strong signal — it says you can work in an unfamiliar codebase, write to someone else’s standard, and take review feedback. That’s most of what a new hire has to do in their first quarter.

Documentation contributions count and are worth listing honestly as documentation contributions. Maintaining something, even something small, counts for more than contributing to something large.

The empty GitHub question

You have a job, children, hobbies, or all three, and your GitHub is a graveyard of forks from 2019. Does this hurt you?

Mostly, no. Plenty of strong engineers have no public code — their work is proprietary, and building software in their spare time isn’t something they want to do. Judging candidates on unpaid weekend output also filters heavily on who has free time, which is a bias most competent hiring teams are consciously trying to avoid.

Practical guidance:

If your GitHub is empty, don’t link it. An empty profile is worse than no link, because the reviewer clicked expecting something.
If it’s got two decent things and eight abandoned forks, still link it — reviewers can tell the difference, and pinning your best three repositories on the profile solves most of it.
If you’re early career, this is one of the few places you can build evidence deliberately. One finished, documented, genuinely useful small tool is worth more than eight abandoned starts.

Some sectors and some companies weight public work much more heavily than others — developer tooling and infrastructure companies tend to look, enterprise shops often don’t. Read the employer before deciding how much effort to put here.

The one-project strategy

If you’re early career and want to build evidence efficiently, the highest-return move is not five projects. It’s one, done properly:

Solves a small problem you personally had
Actually finished and working
README that explains the problem, the approach, and how to run it
Tests, because it’s the cheapest way to look professional
A short write-up of one thing that turned out to be harder than expected

That last item is underrated. An engineer who can explain a problem they hit and how they worked through it is demonstrating exactly the thing interviews are trying to measure — and it gives you a story you can tell when someone asks about the project, which they will.