What to put in your portfolio when you have no experience

The three projects that actually move the needle

After several thousand junior-level resumes, you start to notice that the same three project shapes work disproportionately well — and they have almost nothing to do with the trendy ones.

• A real backend service with auth, a real DB, and a deployed URL. The single most defensible artifact you can have.
• A small AI/LLM project that demonstrates eval discipline, not just 'I called an API'. The 2026 version of 'I built a scraper'.
• A tool you actually use. Not a tutorial repo — a CLI or web app you reach for weekly. Recruiters notice when your README ends with 'I'm still using this.'

Why 'clone X' usually backfires

Twitter clones, Reddit clones, Instagram clones — they're popular because they're well-trodden, and they backfire because they're well-trodden. Every interviewer has seen 50 of them. Yours will be unfavourably compared to the others, no matter how clean it is.

Worse, the design decisions are already made. You don't get to defend 'why I chose this auth model' or 'why I picked this DB' because the upstream product already chose. There's nothing to talk about.

If you must build something familiar, fork it sideways: 'A Twitter for X niche' or 'A Reddit clone that's also a Postgres learning project.' The constraint forces design decisions back into your hands.

The README is half the project

An interviewer will spend 90 seconds on your repo. 70 of those are on the README. Optimise accordingly.

• One-sentence what-it-is. Above the fold. Not 'A backend project' — 'A multi-tenant TODO API with JWT auth and per-tenant rate limiting.'
• Live URL, in the header, before anything else. If there's no live URL, deploy. Render and Fly.io have free tiers that are good enough.
• A short architecture diagram. Even hand-drawn-and-photographed beats no diagram.
• A 'design decisions' section: 3 things you chose, 1 thing you'd do differently. This single section converts more interviews than any other.
• A real screenshot or short GIF. Not a logo.

What makes a project 'interview-defensible'

When the interviewer asks you a hard question about your project, you should have a real answer — not 'I'd have to look that up.' That's the difference between a project on your resume and a project that gets you hired.

Practical test: pick any single line in your code. Can you say, in one sentence, why it's that way and not three alternatives? If yes, you're interview-ready. If no, you copied a tutorial.

Three projects to copy the shape of (not the code of)

These are project templates we've seen work repeatedly. Pick one, give it your own twist, and ship it in 12-20 hours over a weekend or two.

• Multi-user TODO API with JWT auth + per-user rate limiting + a real OpenAPI spec. Boring on paper, brutal interview signal in practice — covers auth, persistence, REST design, and rate-limiting in one project.
• A Claude-powered CLI for something you actually do (summarise meeting notes, triage your inbox, generate test fixtures). Hits 'AI engineering' without being a chatbot. Bonus: include a small golden-eval suite — three test cases, hand-graded — and your interviewer will ask about it.
• A static-site engine in pure Python (FastAPI + Jinja2 + markdown-it-py). RSS, sitemap, OG cards. A real Lighthouse 95+ score. Cheap to build, easy to talk about, infinite to extend.

Avoid the 'just one more feature' trap

More features rarely make a portfolio project better. They make it harder to demo, harder to deploy, and harder to defend in interviews. The pull from 'one core feature done excellently' to 'four features done okay' is the wrong direction.

A defensible heuristic: ship 70% of what you originally planned, but write the README and one good architectural decision in the saved time. That's what gets read.