What a bootcamp graduate
portfolio should include.
A coding bootcamp graduate's portfolio should lead with the capstone project: what it does, the stack it is built on, your specific role in building it, a live demo link that actually loads, and a public repo with a real README and a commit history a reviewer can scroll through. Behind that, show two or three more projects that prove breadth, a full-stack app, an API integration, something with authentication or a database, each with its own working demo and repo. Name the bootcamp and the stack it taught, plainly, and let the software do the work of answering the "no CS degree" question. Below is the full list of what to include, the terms a recruiter searches, and which of the Portfolio designs give your projects room to breathe.
The sections a bootcamp portfolio needs.
A bootcamp graduate is hired on proof they can build and ship, not on a transcript, so the portfolio is organised around working software. Work through these in order, and read the flagged block twice before you publish.
The capstone, stated first
What the app does in one sentence, the stack it runs on, and the part you personally built rather than the part your team built around you. Pair it with a live demo link and a repo whose README explains how to run it locally and what decisions you made.
Two or three supporting projects
A full-stack app, a project that consumes a third-party API, and something that handles authentication or reads and writes to a real database. Together they show you can work across a stack, not just finish one assignment.
The bootcamp and the stack, named plainly
Say which bootcamp you attended and the stack it taught, for example JavaScript, React, Node, Express, and PostgreSQL. There is nothing to hide here. A reviewer who has hired bootcamp graduates before knows the path, and naming it plainly reads as confident, not defensive.
Fundamentals, stated in your own words
A short line on data structures, REST API design, and version control with Git, in language that shows you understand them rather than just used them. This is what answers the assumption that a bootcamp skips fundamentals a degree covers.
Cohort and pair-programming work
If a project was built with a team during the cohort, say so, and describe exactly what you owned: the feature you built, the bug you tracked down, the piece of the codebase that was yours. Group work is normal in a bootcamp and a reviewer expects to see it, they just want to know your specific contribution.
Working links, checked before publishing
Every demo link should load and every repo should be public and readable. A reviewer clicks through in seconds, and a dead link or a private repo undoes the credibility the project was supposed to build.
Leave out: anything that is not really yours
An unfinished tutorial passed off as a project, a cloned tutorial app with no original feature or design decision added, a demo link that returns an error, or a repo set to private that a reviewer cannot open. Any one of these reads worse than having fewer projects.
Three working, deployed, original projects beat six that half-load or turn out to be the same tutorial everyone in your cohort built. Quality and honesty about what you built are what carry the page.
Terms a recruiter searches.
Recruiters screening junior developer applications search their applicant tracking system for specific stack terms. If these are true of you, use the exact words, because a system indexes the words you wrote, not the ones you meant.
Paste your resume into the free ATS score checker with a real junior developer posting to see which of these terms it uses and your resume is missing.
Which designs suit a projects-first page.
A bootcamp graduate's page lives or dies on whether a reviewer can reach a live demo and a repo in one click. Of the 60 Portfolio designs and 48 resume layouts, these are the shapes that fit.
Pick a design built around a grid of project cards, each with room for a fast-loading screenshot, a live demo link, and a repo link. Skip the designs built for a single hero image, they only have room to show one project well.
Of the 48 resume layouts, choose a single-column one. A two-column resume can serialise into a scrambled reading order when a tracking system parses it, and that costs you a screen you should have passed.
Put your stack and your projects above your education. A reviewer who works in tech reads for what you built first and treats the bootcamp itself as context, not the headline.
Compress project screenshots so the page loads quickly. A slow-loading portfolio undercuts the exact impression you are trying to make, that you can build software that works well.
Who a bootcamp portfolio is not for.
A projects-first portfolio helps some bootcamp graduates and does little for others. Read this before you spend an evening building one.
Worth building if you
- +Are moving into a first developer role and need working software to answer the question a CS degree would otherwise answer.
- +Have at least one deployed capstone project with a public repo you are proud to walk a reviewer through.
- +Are applying directly to companies and startups that actually open portfolio links and GitHub profiles as part of screening.
- +Want one link that shows your stack, your projects, and your commit history at a glance.
Skip it, for now, if you
- −Already hold a computer science degree. State that plainly on your resume instead, you do not need the bootcamp framing this page is built around.
- −Only have tutorial clones and no project you built or extended yourself. Build one original piece first, even a small one, then come back.
- −Apply only through your bootcamp's hiring-partner pipeline that submits a standard resume on your behalf. Fix that resume first.
- −Have a demo link or repo you would be embarrassed for a reviewer to actually open. Fix or remove it before you publish a link to it.
Questions bootcamp graduates ask.
Straight answers on projects, honesty about the bootcamp, and what a reviewer actually checks.
What is the single most important thing on a bootcamp graduate's portfolio?
The capstone project, with a working live demo and a public repo a reviewer can open. It is the clearest evidence you can ship real software, and it should sit at the top of the page, not buried below an about section.
Should I say I went to a coding bootcamp?
Yes. Name the bootcamp and the stack it taught, in plain language, alongside your projects. Hiding it or being vague about your background reads as less confident than stating it directly and letting the working software carry the argument.
How many projects should I actually include?
The capstone plus two or three more that show breadth, a full-stack app, an API integration, and something with authentication or a database. More than that dilutes attention; fewer than that does not show enough range.
My repo isn't very polished. Should I still link it?
Clean it up first. Add a README that explains what the project does, how to run it, and what you built, then make sure the commit history is visible and not squashed into one commit. A tidy repo with an honest history matters more than a perfect one.
Do I need a CS degree to get hired as a bootcamp graduate?
No. Working, deployed software, a clean repo, and a clear grasp of fundamentals like data structures, REST APIs, and Git answer that question better than a degree line would. The portfolio's entire job is to make that case with evidence a reviewer can click through.
Where to go next.
Build the site, test your resume, or read how the paste-a-resume flow works.
Turn your bootcamp
resume into a site.
Paste your resume and Portfolio drafts a clean, projects-first website in about a minute. Your capstone up top, room for a live demo and repo on every project, published to your own domain with TLS handled for you.