How to Build a Developer Portfolio That Actually Gets Interviews

I have reviewed a few hundred junior developer applications, so here is the uncomfortable part first: your portfolio does not get read, it gets scanned. The person opening your application has roughly 60 to 120 seconds for it. They open the CV, look for a link, click it, and decide within about thirty seconds whether to keep going. Nobody reads your source code line by line at that stage.

What a reviewer actually does in the first 90 seconds

So the job of your portfolio is not to prove you are brilliant. It is to answer three questions fast. Can this person finish something that works? Can they explain what they built? Would I be embarrassed to put them in front of a client next month? Answer those three in ninety seconds and you get the interview. Everything else below is in service of that.

• Can I click one link and see the thing running, with nothing to install?
• Do I understand what problem it solves, and for whom, within one screen of reading?
• Is there evidence a human made decisions here, or did someone follow a video step by step?
• Does the code read like someone I would enjoy reviewing pull requests with?

What to stop building, and what to build instead

Stop building these

• To-do lists. Every course on earth ships one. It proves you can do CRUD, which is already assumed.
• Calculators, tip splitters, dice rollers, unit converters. These are exercises, not projects.
• Pixel-perfect Netflix, Spotify or Instagram clones fed by a fake JSON file. They prove you can copy a layout.
• A weather app that makes one API call. Fine as a Tuesday-night warm-up, not a portfolio centrepiece.
• Anything built by following a tutorial start to finish without deviating. Reviewers spot those repos instantly, because the folder structure, the variable names and even the commit messages are identical across hundreds of applicants.

Build these instead

Good junior projects share exactly one trait: they touch something real. Real data, a real user, or a workflow somebody actually performs today. Here are five that work, and every one of them is buildable in two to four weeks.

1. 1Automate a job you used to do by hand. Worked in accounting? Build the thing that turns the monthly spreadsheet into the report. You already know every awkward edge case, and that domain knowledge is what makes the project fun to talk about in an interview.
2. 2Ship a real site for a real business. Offer to build a booking page or menu site for a cafe, a clinic, or a tutor near you. Free is fine. You get real constraints, a real client changing their mind, and a real domain. Then write about those constraints in the README.
3. 3Build a tool for a hobby community you actually belong to. A pace calculator for your running club, a class booker for a gym, a reading tracker. Niche is a feature, not a bug, because you already know what the user needs.
4. 4Do something with messy public data. Government open data, transit timetables, exchange rates, air quality readings. Cleaning messy input is about 70 percent of real work and almost no junior portfolio shows any of it.
5. 5Rebuild one piece of internal business software: a small dashboard, an approval flow, a stock scanner. This is what most companies actually pay people to write. It is not another social network.

Three projects at this level is plenty. Four is fine. Twelve is a warning sign, because nobody builds twelve good things, and it tells the reviewer you cannot judge the quality of your own work.

The README is your portfolio, whether you like it or not

The README is the highest-leverage hour you will spend on the whole project. Most applicants pour forty hours into the code and four minutes into the README, then wonder why nobody replies. Shift that ratio a little. And remember that order matters enormously: a reviewer scrolls about one and a half screens, so everything that sells you has to live above that line.

# ClinicBook — appointment booking for small clinics

[Live demo](https://clinicbook.example.com) · demo login: [email protected] / demo1234

![Booking screen](docs/screenshot.png)

Built for a 2-doctor dental clinic that was taking every booking by
phone. Staff now confirm 30+ appointments a week in the browser
instead of a paper diary.

## What it does
- Patients pick a free slot; the clinic sees a day view on a tablet
- SMS reminder 24 hours before the appointment
- Double-booking is blocked in the database, not only in the UI

## Tech
Next.js 15 · PostgreSQL · Prisma · Twilio · deployed on Vercel

## Decisions I made
- Added a unique constraint on (doctor_id, slot_start) after a race
  condition let two patients grab the same 10:00 slot during testing
- Chose SMS over email because most patients here do not read email daily

## Run it locally
git clone https://github.com/you/clinicbook
npm install && cp .env.example .env && npm run dev

## What I would do next
Waiting list for cancelled slots, and move the SMS job off the request path

• A screenshot or GIF inside the first screen, always. Someone reading on a phone should see the product before they see the name of any framework.
• A live link and demo credentials. If they have to sign up to look at it, they will not look at it.
• One sentence on who it is for and what problem it removes, placed before the tech stack.
• A 'Decisions I made' section. This is the part that separates you from every tutorial follower. Two or three genuine decisions with the reasoning is enough.
• A 'What I would do next' section. It shows you know what is unfinished, which is a senior habit.
• No lorem ipsum, no 'TODO: write readme', and no leftover create-react-app boilerplate anywhere in the repo.

Presenting it: the page, the repo, the CV

You need far less than you think. A single page is enough. No blog engine, no dark mode toggle, no scroll animations.

1. 1One page. At the top: your name, one line on what you do and what you want (for example, front-end developer looking for a junior role in Bangkok), then links to your three projects.
2. 2One card per project: a screenshot, one sentence on what it is, and two links, Live and Code. Two, not one.
3. 3Contact details that work. Your email as selectable text rather than an image, plus LinkedIn or WhatsApp. Contact forms that silently fail cost people interviews every week.
4. 4Your CV as a PDF link on the same page, so nobody has to email you to get it.

Then clean up GitHub, because reviewers will go there.

• Pin your three best repos. Everything else drops out of sight automatically.
• Every pinned repo needs a one-line description and a live URL in the About field. That field is empty on roughly nine out of ten junior profiles and takes twenty seconds to fill.
• Your commit history should look like work: dozens of small commits with messages like 'fix double booking on the same slot', not three commits called 'update'.
• Archive or make private the abandoned tutorial repos. You do not owe strangers a tour of your learning graveyard.

On the CV itself, put the portfolio URL in the top block next to your phone number, not in a Links section at the bottom that nobody scrolls to. Then list each project in your experience section as if it were a job, with one bullet stating the outcome in numbers.

The mistakes that quietly kill portfolios

1. 1Nothing is deployed. By far the most common failure. A repo the reviewer cannot click into is a code sample, not a portfolio. Vercel, Netlify, Render and Fly all have free tiers that cover this, and a domain costs about 12 USD a year if you want it to look serious.
2. 2The demo is broken the day you apply. Free database tiers sleep, expire, or get deleted. Click every link the morning you send applications, and again once a month. A dead demo is worse than no demo, because it reads as carelessness.
3. 3Everything is 'in progress'. Three small finished things beat one ambitious half-built thing every single time. Ship, then improve.
4. 4You cannot explain your own code. If you let an AI write a chunk you do not understand, that is precisely the chunk you will be asked about. Use AI, but re-read every file and be able to defend it.
5. 5The project has no user. A social network for pet owners with no users and no research is a wireframe, not a product. One real user beats an imaginary million.
6. 6Secrets committed to the repo. A committed .env with live API keys is an instant no from anyone senior. Add .env to .gitignore on day one and ship a .env.example instead.
7. 7No tests anywhere, ever. You do not need 80 percent coverage. Five meaningful tests in one project plus a CI workflow that runs them is enough to show you know the practice exists.
8. 8Design nobody can look at. You do not have to be a designer. Pick one component library (Tailwind with shadcn/ui, Material, Bootstrap), one typeface, one accent colour, and consistent spacing. Restraint reads as competence.

An eight-week plan you can actually finish

If you are starting from nothing and still working full time, this schedule is built for roughly 8 to 10 hours a week.

Two solid projects and clean presentation at week eight beat six unfinished repos at week twenty. After that, keep one project alive: add a small feature every month or two, so your commit graph shows you did not stop the day you got hired-adjacent.

If doing this alone feels directionless, our Web Development and Mobile App courses at ALL IN ONE STATION are shaped exactly like this plan, ending with deployed capstone work and a reviewed README rather than a folder of exercises. That said, nothing above requires paying anyone. The plan works solo; it just asks more of your discipline.