Building Your Tech Portfolio

A tech portfolio answers the question a résumé can't: can this person actually build things? Done well, it's a small set of projects that demonstrate real judgment — not a dumping ground for every tutorial you've followed. This page covers what to include, how to choose projects, why your READMEs matter more than your code, and how to make demos that survive being clicked by a stranger.

The uncomfortable truth: reviewers spend a couple of minutes per portfolio, and most of that time goes to the README and the live demo. Many never read a line of code. Optimise for the two-minute reviewer, then reward the one who digs deeper.

What a strong portfolio contains

Three to five projects. Not ten — ten signals you can't judge your own best work. Each project should demonstrate something the others don't: one showing full-stack depth, one showing performance or systems thinking, one showing product taste. For early-career candidates, a substantive capstone plus two focused projects is plenty.

Beyond the projects themselves: a one-paragraph bio that says what kind of problems you like, real links that work (this sounds obvious; check yours today), and a way to contact you. Anything beyond that is decoration.

Choosing projects that say something

The fatal portfolio smell is "tutorial adjacency" — a to-do app, a weather app, a Netflix clone — because it proves you can follow instructions, which was never in doubt. The projects that get responses solve a real, specific problem, ideally one you had. Built a tool to track your own job applications? That demonstrates product thinking, genuine requirements, and a user you can interview (yourself). The bar isn't scale; it's evidence of decisions.

When choosing, ask: can I talk about this project for ten minutes — the trade-offs, the bugs, what I'd rebuild? If yes, it belongs. If the honest answer is "I followed along and it works," leave it off. Interviewers will find the weakest project on your portfolio and ask about it, so every entry is a promise you can discuss it deeply. That's also why portfolio projects feed directly into behavioral rounds — they're your best source of STAR stories.

The README is the product

Treat each README as a landing page written by someone who respects the reader's time:

• First screen: what it does, a screenshot or short GIF, and a link to the live demo. A reviewer should understand the project in fifteen seconds without scrolling.
• Why it exists: two sentences on the problem. This is what separates engineers who build from engineers who assemble.
• How it works: a small architecture sketch or bullet list — tech choices with reasons. "Chose SQLite because the dataset fits on one node and ops simplicity mattered more than write scale" is a senior-sounding sentence you can write on day one.
• Run it yourself: copy-pasteable setup instructions that you've tested from a clean machine or container. A README with broken setup steps is worse than none.
• What I'd do next: three honest limitations. Self-awareness reads as seniority.

Demos that don't embarrass you

A dead demo link is a negative signal — it says the owner doesn't check their own work. Deploy on a platform you understand, set a monthly reminder to click every link, and design for the demo's failure: record a short screen capture as backup, and make the app handle empty states gracefully so a fresh visitor doesn't land on errors. If a project needs seeded data to look alive, seed it. Nobody is impressed by a login wall guarding a blank dashboard; add a demo account or a read-only mode.

Then put the portfolio where it earns its keep: at the top of your résumé (our resume builder has a place for it) and in your LinkedIn featured section (see the LinkedIn optimizer).

Common mistakes

• Quantity over curation. Nine mediocre projects hide the one good one. Delete ruthlessly.
• Code with no story. Repos with default READMEs force reviewers to guess why anything exists. They'll guess wrong or leave.
• Dead links and broken builds. Check monthly. It takes ten minutes and protects your entire signal.
• Hidden contribution. Group projects without a line explaining your part. Reviewers assume the least flattering interpretation.

FAQ

Do I need a personal website, or is GitHub enough? GitHub with excellent READMEs is genuinely enough for most roles. A personal site adds polish and SEO for your name — nice to have, never a substitute for project quality.

Should I include bootcamp or course projects? Only if you extended them meaningfully beyond the brief — your own features, your own deployment, your own bugs survived. The extension is the portfolio piece; the assignment isn't.