The 90-Day Portfolio Review: How to Show Growth as a Junior Developer

The portfolio advice juniors get is stuck in 2018. Build a todo app. Add a weather widget. Make a personal site with a contact form. These projects taught you that you could finish something. They do not teach you anything a hiring manager in 2026 cannot see through in three seconds, because every bootcamp grad has the same three repos and they all look the same.

A portfolio that moves the needle does not list projects. It tells a story of growth over time, with evidence. The 90-day review is the mechanism that makes that story legible. Every quarter, you look at what you built, pick the pieces that show a jump in skill, and write them up as case studies rather than feature lists. This takes about two hours per quarter and compounds into the only portfolio format that actually changes how a hiring manager reads your resume.

What a portfolio review actually measures

The signal a hiring manager is looking for is not the number of projects you built. It is the distance between where you started and where you are now, and whether that trajectory is still pointing up. A junior with three React apps is indistinguishable from a thousand other juniors with three React apps. A junior whose first project was a static landing page and whose third project handles auth, state management, and an external API has a story. The projects are the same difficulty. The framing is what separates them.

The 90-day review forces you to answer two questions that most junior portfolios cannot: what did you learn between project A and project B, and why did you build the things you built. If you built a chat app because the tutorial told you to, that is invisible on a resume but obvious in an interview. If you built it because you wanted to understand WebSocket connection management and chose chat as the vehicle for that learning, the why becomes the interesting part and the chat app is just the backdrop.

Start each review with a simple audit. List every project you touched in the last 90 days, including unfinished ones. For each, write one sentence about what was new for you: a technology, a concept, a constraint, a failure mode. Delete the projects where the answer is “nothing new.” Those are practice reps, not portfolio material. The ones left are your growth evidence for the quarter.

Choosing the right projects to showcase growth

You do not need ten projects. You need three that form a visible arc. The arc should be obvious enough that someone flipping through your portfolio at speed can see the slope without reading every word.

The pattern that works: a project that shows you can ship, a project that shows you can think, and a project that shows you care about craft. The order matters less than the contrast. A hiring manager who sees all three knows you are not a one-dimensional coder. One who sees three shipping projects with no thinking or craft assumes you build quickly and break things, which is not the reputation you want.

A shipping project is anything that solves a real problem for a real user, even if the user is you. A CLI tool that automates your own deployment, a browser extension that fixes an annoyance in a tool you use daily, a script that saved your team an hour a week. These projects do not need to be complex. They need to have been used.

A thinking project demonstrates that you can reason about tradeoffs. A postmortem on a failed project counts. A design doc for something you never built counts. A blog post comparing two approaches to the same problem counts. The artifact is secondary to the evidence that you can evaluate options and explain decisions.

A craft project shows attention to detail. Test coverage on a library you wrote. Accessible UI. Clear commit history with messages that explain why, not what. A README that a stranger could follow. These are not bonus points. For a junior role, craft signals are often the tiebreaker between otherwise identical candidates.

Writing case studies that hiring managers actually read

The default junior portfolio format is a screenshot, a list of technologies, and a link to the repo. This format tells you nothing about the person behind the code. It tells you what they used, not how they think.

Replace it with a case study. A case study is a short narrative with four sections: the problem, the approach, the hard part, and what you would do differently. Each section is two to four sentences. The whole thing reads in under 90 seconds.

The problem section answers: what were you trying to do, and why did it matter to anyone. This is the filter that separates toy projects from real work. If you cannot explain why the problem mattered, the project does not belong in your portfolio.

The approach section answers: what technical choices did you make, and why. This is where you get to show judgment. “I chose SQLite over Postgres because the project runs locally and I wanted to avoid requiring a Docker setup for contributors” is a thinking signal. A stack list with no reasoning is not.

The hard part section is the most important and the one juniors skip. What went wrong? What did you not know when you started? What specific technical challenge forced you to learn something new? Honesty here is a competitive advantage, because every experienced reviewer knows that real projects have hard parts and a portfolio that pretends otherwise looks fake.

The what-you-would-do-differently section closes the loop. It shows you can reflect on your own work, which is a senior behavior. Naming a limitation you chose to accept is especially strong: “I skipped pagination because the dataset was always under 50 records, but at scale I would add cursor-based pagination to avoid offset drift.” That sentence tells a reviewer you understand the tradeoffs, not just the happy path.

Run a review every 90 days. Replace older projects as newer ones show clearer growth. After two or three cycles, you will have a portfolio where every project earns its place and the trajectory between them is visible at a glance. That is the thing most junior portfolios lack, and building it costs less time than you spend scrolling job boards in a month.

A portfolio review is the cheapest career habit you can build. Two hours a quarter, sustained for a year, produces a document that no amount of last-minute resume polishing can replicate. Start the first one this weekend with whatever you have in your GitHub right now. The first review is always the hardest, because it will show you exactly where the gaps are. That is the point.