How Many Projects Should a Junior Developer Have?

Short answer: two or three that you can explain in depth. Not eight. The number is less interesting than the reason behind it, which is that reviewers do not read portfolios the way you imagine.

What actually happens when someone opens your portfolio

A reviewer — often a hiring manager between meetings, sometimes a recruiter, occasionally an engineer who volunteered — spends somewhere between 60 seconds and four minutes on a junior application before deciding whether to continue.

In that time they will look at your first project properly, skim your second, and register that a third exists. Projects four through eight are, in practice, invisible. They are not being weighed and found wanting; they are not being read.

This is why eight projects at 60% completion is the most common shape on a junior portfolio and one of the least effective. It reads as someone who starts things. Two finished, deployed, documented projects read as someone who ships — and shipping is the entire question a junior hire is being assessed on.

The shape that works

One substantial project that shows depth. Something that took weeks, has a real data model or a genuinely hard part, and gives you something to talk about for ten minutes. This is the project that carries the portfolio.

One that shows a different dimension. If the first is back-end, make this one user-facing, or vice versa. It answers the "can they do anything else?" question before it is asked.

Optionally, one small polished thing. A CLI tool published to a package registry, a browser extension in a store, a small library. These are cheap — often a weekend — and they demonstrate you can finish and distribute something, which is a distinct skill from building it.

Three is the ceiling for what gets attention, not a target. Two excellent projects beat three where the third is filler.

When fewer is right

One project is enough if it is genuinely deep. Self-taught candidates without a degree often do better with a single substantial system — a task queue, an interpreter, an observability setup across their own services — than with three medium ones. Depth is the argument when you cannot lean on a qualification.

The risk is that if a reviewer does not engage with your one project, there is nothing else. Mitigate it by making the README exceptional and getting the thing deployed.

When more is fine

The count that matters is pinned and featured, not the total in your GitHub account.

Having thirty repositories is not a problem as long as the six pinned ones are chosen deliberately and the rest are archived or unpinned. Nobody is impressed by volume, but nobody penalises it either — they simply look at what you put in front of them.

The same applies to a blog, contributions to other projects, or coursework. Those can exist. They just should not be competing for attention with the work you actually want judged.

What "explain in depth" means

This is the real constraint, and it is why the number is low.

For each project you present, you should be able to answer, without notes:

• What problem does it solve and who for?
• Why did you build it this way rather than another way?
• What was the hardest part and how did you handle it?
• What would you do differently now?
• Walk me through what happens when a user does X.

That is roughly a two-minute answer per project, and getting there takes real work — usually writing a case study and saying it out loud a few times. You cannot do that for eight projects. You barely have time to do it for three.

If you cannot answer those five questions about a project, it is not portfolio evidence yet. It is either not finished or not understood, and both are worse than not listing it.

The AI-assisted caveat

This has become the sharpest version of the same rule. If AI wrote a substantial part of a project you present, you still need to be able to explain every line of it, because you will be asked to.

An interviewer finds this out in about ninety seconds, and there is no recovery from it. Use AI to accelerate — brainstorming, reviewing your code, drafting documentation you then rewrite — but do not present code you have not read and understood.

What to do if you only have coursework

Do not start from scratch. An assignment becomes portfolio evidence when you deploy it, write a real README, add one feature nobody asked for, add a few tests, and handle the error cases the sample data never triggered. That is about two evenings, against three weeks for something new, and a reviewer cannot tell the difference.

How to turn a university assignment into a portfolio project covers the full upgrade.

The practical answer

If you are starting today with four half-finished things:

1. Pick the two closest to the role you want.
2. Finish one of them properly — deployed, documented, tested.
3. Finish the second.
4. Archive or unpin the other two.
5. Write a two-minute explanation of each and say it out loud.

That is roughly two weeks of evenings and it is worth considerably more than a fifth project.

If you want project briefs rather than another list of ideas, the portfolio project ideas guide has thirty of them with full specifications, and the free toolkit includes five of those plus the case-study template you will need to write those two-minute explanations.