The portfolio project question is one of the most common from people learning to code, and most of the advice circulating online is based on what worked in 2019. The hiring environment has changed, and the projects that actually carry weight with hiring managers in 2026 aren’t always the projects that the standard bootcamp curricula encourage.

I’ve talked with a few engineering managers and senior engineers across different companies recently about what they actually look for in junior candidate portfolios. The patterns are more consistent than I’d expected, and they’re worth setting out clearly.

What hiring managers actually look for

Sustained projects over big projects. A small project that you’ve maintained for six months — adding features, fixing bugs, improving the deployment, responding to user feedback — tells a hiring manager more than a large project you finished and abandoned. The sustained engagement demonstrates the working pattern that you’ll bring to the job. The big-project-once pattern doesn’t.

Production deployment beyond a localhost screenshot. The project is actually deployed and running. There’s a real URL where the code runs. Better still, the deployment process is documented or visible — what platform, what infrastructure, what trade-offs were made. Production deployment is one of the things that separates “I can build something” from “I can build and operate something”, and the second is what hiring managers want to hire for.

Real users, even few. The project has people other than you using it. Even five real users, even a small Discord community, even a handful of people who’ve signed up and used the tool. The fact of real users brings entirely different considerations into the project — performance under non-trivial load, support and feedback handling, change management when fixing bugs that affect existing users — that matter more for evaluating engineering capability than the specific feature set.

Decisions documented and explained. The project has documentation that explains why specific choices were made. Why this database, why this framework, why this deployment platform. The documentation doesn’t have to be elaborate — a thoughtful README is often plenty — but the demonstrated thinking about trade-offs is exactly what hiring managers want to see.

Code that’s been refactored over time. The git history shows meaningful evolution. Initial implementations have been improved. Hacks have been replaced with cleaner solutions. The code reflects the developer’s growing capability, not the state of their capability at the moment they first wrote each piece. This is genuinely revealing about how a candidate works.

Specific project ideas that work

Some categories that have produced strong outcomes for the candidates I’ve watched:

A specialty tool for your specific hobby or interest. A bike route planning tool for cyclists in your city. A practice tracker for guitar players. A meal planning tool for a specific dietary approach. Domain-specific tools that solve real problems for actual people in a community you’re part of generally produce better engagement than generic productivity tools, because the developer cares about the problem and other people in the same community become natural early users.

A small SaaS or paid product, even if revenue is minimal. The combination of payment integration, customer support, terms of service, refund policies, and the rest of the business considerations that come with a paid product produces a much fuller demonstration of capability than free products. Doesn’t have to be successful as a business; the act of making something that people will pay for, even at small scale, demonstrates capability beyond pure code.

An open-source library or tool used by other developers. If your project is something other developers use, you’ve demonstrated communication, documentation, and engineering at a level that consumer-facing projects don’t always require. The audience of fellow developers is more critical and the bar is higher, but the credibility of “developers use my library” is substantial.

A complex personal project with thoughtful technical decisions. Something where the technical choices matter and have been made carefully — a self-hosted media server with a well-designed transcoding pipeline, a personal finance tool with proper security thinking, a niche analytics tool with meaningful data engineering. The complexity demonstrates capability; the thoughtfulness demonstrates engineering judgment.

A technical writing companion to your code. A blog or written body of work that documents your engineering thinking alongside the projects themselves. The combination of “I built X” and “here’s why I made the decisions I did and what I learned” produces a richer portfolio than code alone.

Specific project types that don’t work as well

Twitter / Reddit / Spotify clones. These have been built thousands of times. They don’t differentiate. They don’t tell hiring managers anything about you that they couldn’t infer from any other generic tutorial project.

To-do apps and calculator apps. These were valid learning vehicles. They aren’t impressive portfolio projects. The hiring manager has seen 200 of them by Tuesday.

Projects built entirely from tutorial videos with no original additions. The hiring manager can tell. The video tutorials produce identifiable patterns that show up across multiple candidates’ portfolios. Deviating substantially from the tutorial — adding features, restructuring the architecture, deploying to a different platform — is the difference between “this is a tutorial result” and “this is genuine work”.

Half-built projects with no recent commits. Abandoned projects on a portfolio actively hurt rather than help. Better to have a smaller portfolio of completed (or sustained) work than a larger portfolio of abandoned work that suggests inability to finish things.

Projects that obviously rely on AI generation without engineering thinking. Code that has the characteristic patterns of AI-generated work without showing evidence that the developer understood and shaped it. The hiring managers I’ve talked to are reading code carefully and can usually spot AI-generated portfolios that the developer doesn’t actually understand. The honest pattern of “I used AI tools as part of building this and here’s what I added beyond what they generated” is fine; the pattern of submitting AI-generated code as one’s own without modification or comprehension is being identified at increasing rates.

How to talk about your projects in interviews

The portfolio is the entry point; the conversation about the projects is what closes the deal. A few things that work in those conversations:

Be specific about decisions. “I chose Postgres because” beats “we used Postgres”. The fact that you can articulate why specific decisions were made tells the hiring manager you’re thinking like an engineer, not just executing.

Be honest about what didn’t work. The hiring managers I respect specifically value candidates who can talk about things they got wrong, what they learned, and what they’d do differently. The candidate who claims everything worked perfectly first time isn’t credible; the candidate who can describe a specific failure and the lesson is more believable.

Talk about trade-offs. Every engineering decision involves trade-offs. The candidate who can articulate the trade-offs they faced and how they decided demonstrates engineering thinking. The candidate who presents decisions as if they were obvious-best-choices demonstrates either inexperience or naivete.

Show how the project evolved. The first version of the project versus the current version. What got added, what got removed, what got refactored, why. The arc of the project’s evolution tells the hiring manager about the developer’s growth and judgement.

Be prepared for technical questions about the implementation. Hiring managers often deep-dive on portfolio projects to verify that the candidate actually built the thing and understands it. The candidates who can speak fluently about their own implementations have huge advantages over candidates who built something but couldn’t reproduce or modify it under pressure.

What I’d tell someone planning their portfolio for the next 12 months

Three things.

Pick projects you’ll genuinely care about for at least six months. The portfolio that wins is the portfolio that’s been sustained. Sustenance comes more easily when you actually care about the project.

Don’t try to build the most impressive thing. Build something genuine. The 200 hours of solid engineering work on a real project producing a real result beats 800 hours of impressive-on-paper work that nobody uses.

Document your thinking as you go. Blog posts, decision journals, README updates. The body of writing that grows alongside your code is part of what differentiates strong portfolios from weak ones.

The portfolio matters more than the resume for self-taught and bootcamp candidates. The resume gets you considered; the portfolio gets you interviewed. Spend the time and effort on the portfolio accordingly. The candidates I’ve watched succeed in 2026 have generally invested heavily in the portfolio; the candidates who treat the portfolio as an afterthought to learning have struggled.