Side Projects That Actually Impress Hiring Managers in 2026

A hiring manager looking at your GitHub does not read your code. We tested this assumption by walking through how engineers actually triage candidate portfolios, and the pattern is consistent: they spend somewhere between ten seconds and two minutes per project before deciding whether to look deeper. That window is the entire game. A clone of a to-do app, a weather dashboard, or a tutorial-followed e-commerce site closes the window immediately, because the reviewer has seen the exact same project forty times and knows it taught you nothing about the parts of engineering that are hard.

What survives the ten-second skim in 2026 is different from what survived in 2020. AI tools have made it trivial to generate a polished-looking app with a landing page and a dark-mode toggle. The visual bar is no longer a signal. The signal now lives in the decisions a tool cannot make for you: what problem you chose, what tradeoffs you took, and whether anyone other than you has used the thing.

What hiring managers actually evaluate

Strip away the surface and there are four things a reviewer is trying to infer from a side project, in roughly this order of weight.

The first is judgment: did you pick a problem worth solving, or did you build whatever the tutorial told you to? A scoped, real problem — even a small one — beats an ambitious clone every time, because it shows you can identify and bound a problem, which is most of the job.

The second is whether it runs. A surprising share of portfolio links are dead, point to a localhost screenshot, or 500 on the first click. A deployed, working URL puts you ahead of a large fraction of applicants for the cost of one afternoon. If the reviewer can use it without cloning the repo and reading your README, you have already won attention you would otherwise have to earn.

The third is the README and the commit history. These are the closest a reviewer gets to watching you work. A README that states the problem, shows the decision you made, and admits one tradeoff reads as senior. A commit history of small, described changes reads as someone who works on a team. A single commit named “initial commit” containing 4,000 lines reads as someone who pasted output and never iterated.

The fourth, and the rarest, is evidence that someone used it. Ten real users you can name beats a thousand imaginary ones. A screenshot of a single genuine support conversation, a changelog entry that says “fixed because a user reported X,” or three GitHub stars from strangers all carry more weight than another feature.

Four projects that signal the right things

These are not the only good ideas — they are categories that reliably pass the skim because each forces a decision an AI assistant cannot make for you.

A tool that scratches your own itch and that you actually use. The strongest signal is a project still running in your own life six months after you built it. It proves the problem was real and that you maintained software past the fun part. A CLI that renames your screenshots, a script that reconciles your subscriptions, a bot that pings you when a specific GitHub label appears — small is fine. Sustained is the signal.

A focused contribution to an open-source project people use. A merged pull request to a library with real downloads tells a reviewer that you can read an unfamiliar codebase, follow contribution norms, and ship inside someone else’s constraints. That is a closer match to the actual job than any greenfield app. Start with documentation fixes and small bugs; the bar to a first merge is lower than most people assume.

A teardown or measurement project. Pick something, measure it, and write up what you found. Benchmark three vector databases on the same workload. Profile why a popular npm package is slow to import. Reproduce a paper’s result and note where it broke. These projects demonstrate that you can form a question, gather evidence, and reach a defensible conclusion — and they double as writing samples, which most candidates never provide.

A project that survived contact with users. Anything with a public URL where strangers can sign up and where you can point to a real interaction. The number of users is almost irrelevant; the fact that you exposed your work to people who did not have to be nice to you is the point.

The common thread is that each category forces you to make and defend a choice. That is exactly the muscle a hiring manager is checking for, and it is the one thing the tooling cannot do on your behalf.

How to present it so it lands

Building the project is half the work; the other half is removing every reason for a reviewer to bounce. Lead with a live link, not a repo. Put the one-sentence problem statement at the very top of the README, above the install instructions. Include one screenshot or a short GIF so the reviewer sees the thing working without leaving the page.

Then do the part almost nobody does: write two or three sentences on a decision you made and what you gave up. “I used SQLite instead of Postgres because the dataset fits in memory and I wanted zero-ops deployment; if it grew past a few hundred thousand rows I would migrate” tells a reviewer more about your seniority than any amount of code. It shows you think in tradeoffs, which is the vocabulary of every technical interview you are about to have.

Finally, link the project from somewhere a human will see it — your resume, your email signature, the first line of your application — rather than burying it in a pinned repo and hoping. The best side project in the world earns you nothing if the reviewer never opens it.