10 Things Every Junior Developer Portfolio Should Have

Most junior portfolios fail in the same way. Not because the code is bad — usually it is fine — but because a reviewer cannot work out, quickly, what the person can do. The portfolio is a claim, and the claim has no evidence attached to it.

Here are the ten things that fix that, roughly in the order they are worth adding.

1. One sentence saying what you build

Above everything else, before any scrolling, a reviewer should be able to read what you are and what you want.

Final-year computer science student. I build APIs and data pipelines in Python and Go. Available from July 2027.

That is three facts in twenty words: level, specialism, availability. Compare it to what most student sites open with — "Passionate developer with a love for clean code and new technologies" — which contains zero facts and describes several hundred thousand people.

Pick a direction even if you are not certain. A portfolio aimed at front-end roles that turns out to be wrong is far more effective than a portfolio aimed at nothing.

2. Two or three projects, not eight

Reviewers look at your first two projects and form a view. The third gets skimmed. The fourth through eighth are, functionally, invisible.

Eight projects at 60% completion is the most common shape on a junior portfolio and the least effective. It reads as someone who starts things. Two finished, deployed, documented projects read as someone who ships.

If you have eight, pick the three that best match the role you want. The rest can stay on GitHub unpinned.

3. At least one thing that is live and clickable

A URL a reviewer can open in a new tab is worth more than three repositories they would have to clone.

This is the single highest-leverage item on the list and it is usually a weekend of work. Free hosting on Vercel, Netlify, Cloudflare Pages, Fly.io or Render covers almost every stack. If the project genuinely cannot be deployed — a mobile app, a game, a CLI tool — record a 30-second screen capture instead. Never make a reviewer imagine it.

4. A README on every project you point at

An undocumented project cannot be assessed, so it counts for nothing. Worse than nothing, actually: it suggests you either could not be bothered or did not know it mattered.

The README needs to answer, in this order: what is this, can I see it working, what is it built with, how does it work, can I run it, what did you learn. Most student READMEs answer only the fifth of those.

The README template covers this in full.

5. One technical decision, explained, per project

This is the item that most reliably separates candidates, and almost nobody does it.

I used Postgres rather than SQLite because the scheduler and the web process both write, and SQLite's single-writer lock was causing timeouts under concurrent load.

That sentence tells a reviewer you understood a constraint, evaluated an option, and made a choice you can defend. It is the difference between "I used the stack from the tutorial" and "I made an engineering decision".

You need one per project. Not five.

6. Something that went wrong

Interviewers ask about this in almost every technical conversation. Having the answer written down means you never fumble it.

Be specific. "Deployment was challenging" is not an answer. "Times were stored without timezone information, so every fixture shifted by an hour when the clocks changed — I moved storage to UTC and added a test that runs the list across a DST boundary" is an answer, and it doubles as evidence that you write tests.

7. A GitHub profile that supports the story

Your CV links to your portfolio; your portfolio links to GitHub; GitHub is where a technical reviewer checks whether you are telling the truth.

The minimum: a profile README with three lines about what you build, your best repositories pinned, real descriptions on each, and no secrets anywhere in your commit history. Everything else is optional.

The GitHub profile guide has the full four-pass cleanup.

8. A skills section without percentages

Percentage bars and five-star ratings on skills are actively disliked by technical reviewers. "Python — 87%" is not a measurable claim, and it invites the obvious follow-up question you cannot answer.

Group technologies by what you have used them for instead. If you want to signal depth honestly, split them into "used in a deployed project" and "used in coursework and side projects". Reviewers find that genuinely informative, and it costs you nothing in credibility.

9. A one-page CV that links back to everything

The portfolio only gets opened if the CV survives the first filter, which takes somewhere between eight and twenty seconds.

One page. PDF. Your portfolio and GitHub as clickable links in the header. Three lines per project that say what you built, with what, and what happened. Named sensibly — firstname-lastname-cv.pdf, not CV_final_v3.pdf.

The developer CV guide covers the bullet patterns in detail.

10. Consistency across all of it

Reviewers cross-reference. They will see your CV, then your LinkedIn, then your site, then GitHub, and they will notice if the four of them describe four different people.

Same target role. Same top projects. Same technologies emphasised. Same name and photograph. This is a 30-minute job and it is the last thing most people do, if they do it at all.

What order to do this in

If you are starting from nothing, this sequence gets you to something sendable fastest:

1. Pick a target role and write the one-sentence claim (30 minutes)
2. Choose your two or three projects (1 hour)
3. Deploy one of them (an evening)
4. Write a proper README for it (an evening)
5. Clean up your GitHub profile and pin them (an evening)
6. Build the one-page site (a weekend)
7. Write the CV from the case studies (an evening)
8. Fix LinkedIn to match (30 minutes)

That is roughly two weeks of evenings and it takes you from nothing to something you can attach to an application. The order matters: the website is step six because building a site before you know which projects go on it is how people spend three weekends choosing a CSS framework.

The test

Open your portfolio in a private browser window and give it to someone who is not on your course. Ask them one question: what do you think I do?

If their answer does not match the role you are applying for, the positioning is the problem — not the projects. That is a one-evening fix, and it is worth more than another feature.