The Projects Section: How to Present Work That Isn't a Real Job

TL;DR

For new grads and bootcamp grads, the projects section is the most important section on the resume.
Each project entry needs four things: a name, a tech stack, what it does, and a link.
Three well-presented projects beat ten vague ones.
Bootcamp projects, personal projects, and open source contributions are treated differently.
Where the section sits on the page depends on how much professional experience you have.

Most candidates bury their projects section at the bottom of the resume as if it's a footnote.

For new grads and bootcamp graduates, this is the opposite of what you should do. The projects section is your primary evidence that you can build software. It's the part of your resume that a technical hiring manager actually reads. Putting it at the bottom, formatted as an afterthought, is leaving your best material in the wrong place.

Where the Projects Section Goes

Placement depends on what else you have.

No professional software experience: Projects goes directly below your skills section, above education. Your projects are the closest thing you have to work experience, so they should appear where work experience would normally appear.

One or two internships: Projects goes after your experience section. Your internship experience is stronger than project work in isolation, but projects are still important enough to come before education.

Multiple full-time roles: Projects may move below education or become very selective. At that point, only include projects that demonstrate something your work history doesn't already show.

For most people reading this article, the first scenario applies. Projects near the top. Not buried at the bottom.

The Anatomy of a Project Entry

A strong project entry has exactly four components:

1. The project name. Not "Personal Project" or "Class Project." A name. Even if it's simple. "Task Manager App" is better than "Personal Project #3." Names are memorable and make it easier for an interviewer to reference the work in a conversation.

2. The tech stack, listed concisely. Put this in parentheses or on the same line as the title: React, Node.js, PostgreSQL. Or: Python, FastAPI, SQLite. This immediately tells the reader what you know how to use. Don't list every library. List the frameworks and tools that took real skill to work with.

3. What it does. One or two bullets that describe what the application does and what technical problems you solved building it. This is where the same impact vs. activity rules apply as they do to job bullets.

4. A link. GitHub repo, live demo, or both. The link needs to work. A dead link is worse than no link. Your GitHub should be set up in a way that actually shows your code, not just a repository with one commit and a default README.

Here's an example of a complete project entry:

Budget Tracker (React, Express, PostgreSQL) github.com/username/budget-tracker | Live Demo

Built a personal finance app that lets users log transactions, set monthly budgets by category, and visualize spending trends with Chart.js
Implemented JWT authentication, persistent user sessions, and a RESTful API with Express serving a React front end

That entry is under six lines. It tells a hiring manager the technology, the purpose, and two specific technical things you did. That's enough.

How Many Bullets Per Project

Two to three bullets per project. Occasionally four for a significant project.

One bullet is almost always underselling. If you spent meaningful time on a project, there are two distinct things worth saying about it: what it does and one technical decision or challenge worth noting.

More than four bullets usually means you're padding or repeating yourself. Keep it tight.

How Many Projects to Include

Three to four projects is the right range for most candidates.

Three well-described projects are better than six vague ones. Every project entry you add that doesn't demonstrate something different is taking up space and diluting the section.

Ask this about each project before including it: does it demonstrate a skill or a technology that at least one of my other projects doesn't already show? If no, it may not earn its spot.

You also want variety in what your projects show. A mix of front-end and back-end work is more useful than four CRUD apps built on the same stack. If all three of your projects are React apps with a REST API, your resume only demonstrates one thing. Thinking about how to pick projects that fill in gaps is worth doing before you write the section.

Framing Different Types of Projects

Not all projects have the same source, and the way you write about them should reflect that.

Bootcamp projects

Bootcamp projects are legitimate work to include on a resume. The stigma around them has faded significantly. Hiring managers at most companies understand that a bootcamp grad who built a full-stack application from scratch during an intensive program has real skills.

What you want to avoid is labeling them in a way that undersells them. "Bootcamp Project: Budget App" is weaker than just "Budget App." You don't need to call out that something was a bootcamp project. The work stands on its own.

If the project was a group project, note that: "Collaborated with two other developers to build..." This is honest and actually shows you can work with others, which is a real job skill.

The one place to be careful: if a bootcamp project was largely scaffold code that students filled in with minor additions, listing it as a polished original project can backfire if you can't speak in depth about how it was built. Only list projects you can defend in a technical conversation.

Personal projects

Personal projects are the best kind to include because they show genuine curiosity and initiative. A project you built because you wanted to learn a technology or solve a problem you had is inherently more interesting than an assignment.

Write about personal projects the same way you write about any project: what it does, what you built, what technology you used. Don't over-explain the motivation in the resume entry itself. "Built a tool to track my personal reading list" is enough context. The interesting part is the technical implementation.

If your personal project is still in progress, that's fine to include as long as there's something working you can point to. An incomplete but functional MVP is real work. A repository with no commits or a broken demo is not.

Open source contributions

Open source is worth calling out specifically because many candidates don't know how to present it.

If you made a meaningful contribution to an existing open source project (a real bug fix, a new feature, improved documentation that required understanding the codebase), that belongs on your resume. Not as a separate project section, but either in your main projects section or under a sub-heading.

Format it differently from an original project: "Contributed to Project Name: Fixed a memory leak in the connection pooling module and added tests for edge cases in the API response parser."

Small contributions (fixing a typo, updating a link) are not worth listing. Contributions where you understood the codebase well enough to change behavior are.

What Not to Include

There are a few project types that consistently create more problems than they solve.

Tutorial projects you followed step-by-step. If you built a project by following a YouTube tutorial line by line, it's not really your project. Hiring managers often recognize common tutorial projects (the classic to-do app, the React weather app with a free API). Including them isn't automatically bad, but you need to have added something meaningful to them, or changed them enough that you can genuinely call the implementation yours.

Projects with dead links. A broken GitHub link or a demo that doesn't load is worse than no link. The hiring manager clicks, it fails, and now they're wondering whether your work is real. Check your links before every application.

Projects you can't explain. If someone asks you "how did you build the authentication on this?" and you can't answer, don't list it. In an interview, you'll be asked about every project on your resume. Each one is fair game.

Five versions of the same thing. Multiple to-do apps, multiple weather apps, multiple e-commerce templates with different styling. These don't show range. Pick the one that's best and cut the rest.

The Link Strategy

Every project needs a working link. Ideally two: a GitHub repo and a live demo.

The GitHub repo should have a clean, readable README that explains what the project does and how to run it. Not a two-sentence stub. A good README makes the project look like professional work. Hiring managers and engineers who are evaluating you will click through, and a README that says nothing about the project is a missed opportunity.

A live demo isn't always possible, but it's worth the effort when it is. Seeing a working application is different from reading about one. Free hosting through Render, Railway, or Vercel is widely available. Deploying your project and keeping it running is worth doing for your two or three most important projects.

Updating the Section As You Grow

The projects section is not permanent. As you build better work, older projects should be replaced.

A project you were proud of six months ago may not be the right thing to lead with now. New developers often leave old bootcamp projects on their resume years after they've built significantly more sophisticated work, simply because they haven't revisited the section.

Set a reminder to review your projects section every two to three months while you're job searching. What you're most proud of now may not be what you were most proud of last quarter.

The projects section connects directly to how your GitHub looks to a hiring manager. The repo linked from your resume is going to get clicked. Make sure what they find there matches the quality of what you've described.

For the full picture of how the projects section fits into the rest of the document, the software engineering resume guide covers every section in sequence.

If you want help auditing your projects section and figuring out which work to lead with, here's how the Globally Scoped program works.