← Blog
careerengineeringhiring

Most Developer Portfolios Are Broken

7 March 2026

Most Developer Portfolios Are Broken

I've reviewed a lot of developer portfolios. As a lead engineer, I've looked at candidates' work before interviews, helped people I mentor put together their first professional presence, and occasionally audited my own against what I'd want to see.

The pattern is almost always the same.

The Todo App Graveyard

Most portfolios are full of projects that exist to demonstrate that you can code. A todo app. A weather dashboard. A clone of some well-known product. A CRUD app with a name that sounds like a startup. Sometimes they're polished. Sometimes they have nice animations. None of them matter.

The problem isn't that these projects are simple. The problem is that they have no stakes. Nobody uses them. No real decision was made during their construction — just a tutorial followed, a feature list completed. They demonstrate that you can write code. They say nothing about whether you can solve problems.

Nobody Reads Your About Page

Most About pages are invisible. Walls of "I'm passionate about building scalable solutions" that communicate nothing. A list of technologies that could be copied from a hundred other profiles.

Nobody cares that you're passionate about React. Everyone is passionate about React, or at least says they are. The question is what you've done with it, why you made certain choices, what went wrong.

Projects Without Context Are Meaningless

The second most common failure: a project with a title, a GitHub link, and a one-line description. "E-commerce platform built with Next.js and Stripe." Okay. And?

What problem were you solving? What was hard about it? What would you do differently? What did you ship, and what did you cut? Who uses it?

Without answers to these questions, a project is just a repository. A repository tells me you can write code. It doesn't tell me whether I want to work with you.

What Actually Signals Ability

The portfolios that stand out share a few things.

Real users. If something you built is used by people who weren't obligated to use it, say so. Numbers help. "Used by 200 barbershops in Italy" is more interesting than "a booking management application." Real use implies real requirements, real edge cases, real decisions under pressure.

Specificity about tradeoffs. The engineers I most want to work with are the ones who can explain why they made a choice — and what they gave up to make it. "I chose SQLite over Postgres because the deployment model needed to be self-hosted with zero configuration" tells me more about someone's judgment than a list of every database they've ever touched.

Honest writing. A post that says "I tried this, it didn't work because of X, so I did Y instead" is more valuable than a perfectly polished write-up where everything went according to plan. Real engineering is full of dead ends. Hiding them from your portfolio is hiding the most interesting part of the work.

The Writing Advantage

This is the most underused thing in developer portfolios: most people don't write. If you write, you are automatically in a smaller pool. Not because writing proves you're a better engineer — it doesn't, directly. But it proves you can explain your thinking, which is something you'll be asked to do constantly as a senior engineer. And it creates a trail of evidence about how your mind works that no GitHub profile can replicate.

You don't need to publish often. One honest post about something you actually built — what it was, why you built it, what surprised you — is worth more than a perfectly optimized README on a todo app.

What I Actually Look At

When I review a portfolio before an interview, I'm looking for evidence of judgment. Not the most impressive technology, not the best design, not the highest project count. Judgment. Did they make real decisions? Do they understand the tradeoffs they made? Can they explain what they built in a way that's honest and specific?

If I see that, I'm interested. If I see a todo app with a dark mode, I'll still talk to you — but you've made my job harder.

Build something real. Write about what was hard. That's it.