What to build for a portfolio that gets you interviews

The single most common thing standing between a trained beginner and an interview is not skill. It is that there is nothing an employer can open.

A CV listing React, Node, MongoDB and Python tells a recruiter nothing, because every CV in the pile says that. A link to something running, that you can explain, moves you into a much smaller group — smaller than most candidates realise.

Three projects, finished

Three is enough. More than that and the reviewer stops reading; fewer and one weak project is your whole case.

One that does something useful for a real person. Ideally someone specific — your uncle's shop, your college society, the friend who tracks something in a spreadsheet that visibly hurts to look at. Real users produce real requirements, and real requirements produce the messy decisions an interviewer wants to hear about. It does not need to be original. It needs to be used.

One that shows the full stack. Authentication, a database, a server, deployed on the internet with a URL. It can be modest — a booking tool, a small inventory app. What it proves is that you understand how the pieces connect, which is different from having used each of them once.

One that shows depth in something. A performance problem you solved and can measure. An unusual integration. A tricky algorithm. This is the one you will talk about for twenty minutes, and it should be the one you found genuinely interesting, because that comes through.

Finished, in all three cases, means deployed and working when a stranger clicks it. A GitHub repo of a half-built thing is not a portfolio entry. Roughly half the links on junior CVs are dead, so a working link is itself a differentiator — which is a low bar and a real one.

What to avoid

The tutorial clone with the tutorial's design. Reviewers have seen the same to-do app and the same weather dashboard several thousand times. If you built one to learn, good — but it is a lesson, not evidence.

A "portfolio website" as the portfolio. A page listing your skills with a gradient and a hero section is not a project. Build the thing; the page describing it is optional.

Fifteen half-projects. Volume reads as inability to finish, which is the specific worry an employer has about a self-taught junior.

Anything you cannot explain line by line. Increasingly relevant. If you cannot say why a function is written the way it is, do not ship it — that conversation is the interview now.

The part everyone skips

Write a README.

Not a description of the app. A short account of the decisions:

• What problem it solves, in two sentences. No preamble.
• A screenshot or a thirty-second clip, so the reviewer sees it working before deciding whether to click.
• How to run it locally, correctly, tested on a clean machine.
• One decision you made and why — the database you chose, the thing you deliberately did not build.
• What you would do differently. This one carries the most weight per line, because it demonstrates judgement about your own work, which is the rarest thing on a junior CV.

Most reviewers spend under two minutes on a project. The README is what they read. A good one on an average project outperforms a great project with no README — not because the code matters less, but because unread code cannot be evaluated at all.

Where the work comes from

If you are training with us, some of it is already done. The 23 graded projects are marked by a mentor with written feedback, and the ones you revise after that feedback are usually the strongest things in a first portfolio — partly because revising to a critique is exactly the professional loop.

Anything you build in the code lab can be published to a public link, so you can show someone a running project without owning a server or configuring a deployment. The capstone is designed to be the "full stack, deployed" entry above.

None of that removes the need for the first project on the list — the one for a real person, that nobody assigned. That one is yours to find, and it is reliably the one you end up talking about.

When it is ready

You will not feel ready. Nobody does, and waiting until you do is the most common way to lose six months.

The test is not whether the code is good. It is: does the link work, can you explain every part of it, and does the README answer what it is and why. If those three are true, start applying, and keep building while you do.

More on the path from zero in becoming a full-stack developer with no experience, or see the programmes.