How to list projects on a resume (so they read like proof, not filler)

Most resumes fail in a predictable spot: the gap between what the person can do and what their job titles say. If you are a new graduate, your title was "student". If you are changing careers, your last title belongs to a different industry. If your job is narrower than your skills, your title hides what you can actually build. A projects section closes that gap, because a project shows the work itself, not the label.

Projects matter most exactly when formal experience is thin. Recruiters and automated screens look for evidence that you have applied your skills somewhere real. A project with a name, a stack, and a result is that evidence. This post shows you how to format it so it reads as proof.

Who actually needs a projects section

Add one if any of these describe you:

• You are a student or recent graduate with little work experience in your field. See how to write a resume with no experience for the full playbook.
• You are changing careers and need proof of the new skills before anyone has paid you to use them. Projects are the highest-value section for career changers.
• Your job is narrower than your skills, and a side project shows what your title does not.
• You work in tech, data, design, or engineering, where showing work is the norm.

Skip it, or keep it minimal, if you have many years of directly relevant work experience. Your experience section already carries the proof, and a projects section can start to look like padding. For everyone else, two to four strong projects is the right size. More than four and the section stops being a highlight and starts being a list.

Where the projects section goes

Placement is a signal about what matters most on the page. Put the section where your best evidence is:

• Above Work Experience, right after education: students, new graduates, and career changers. Your projects are your strongest qualification, so they go first.
• Below Work Experience: when your work history is solid and projects are supporting evidence.
• Inside a job entry, not a separate section: when the project was part of a job. A project you did at work belongs under that job's bullets, where the context already exists. Pulling it out into a separate section splits one good story into two thin ones.

Call the section "Projects" or "Selected Projects". "Relevant Projects" works too when you are tailoring per posting and the projects shown are the ones that match this role. The name should describe what is in the section, not apologise for it: avoid "Academic Projects" as a section title unless every entry is academic and you want to signal exactly that.

The anatomy of a project entry

Every project entry has four parts, in the same order every time. A recruiter who has seen a hundred resumes can read this format in seconds:

1. Project title. Give it a name, even if it is descriptive: "Neighbourhood food-bank inventory tracker" beats "Web app project". A name makes the entry memorable and searchable.
2. Context line: your role, the tools, the date. One line, same as a job entry: Personal project · React, Node.js, PostgreSQL · Mar 2026. Academic work should say so: Course project · Python, pandas · Nov 2025. The context line is also where honesty lives; do not describe a solo coursework build in a way that implies a team or a client.
3. Two or three bullets on what you built and what came of it. This is where the section earns its place. Each bullet follows the same formula as a work-experience bullet: action plus what you did plus a result or number. Write them with the bullet formula, and quantify the result honestly where you can.
4. A link where it helps. A live demo, a GitHub repo, or a portfolio page. Only link to work you are comfortable being judged on, and only if the repository is presentable: a repo with a README and recent commits helps; an empty repo with a broken build hurts.

Notice what this entry does not say. It does not say "passionate about optimisation". It does not list every library imported. It shows the problem, the build, and the result, each in one line. That is the entire job of a project entry.

Before/after: the same project, two ways

Most projects are written like course titles. Here is the same work formatted for a recruiter and a screening system:

The "after" version is longer, but none of it is filler. The dataset size, the accuracy, the held-out set, the write-up: every line is a checkable fact that tells the reader what level you operate at. Recruiters reject vague project entries not because the projects are academic, but because they do not prove ability. Specifics prove ability.

Tailor the projects to each posting

Here is the part most advice skips. You do not have one projects section; you have a portfolio, and you choose which projects face each reader. Applying for a data role? Lead with the classifier and the analysis write-up. Applying for a backend role? Lead with the Flask deployment and the database design. Same person, same work, different emphasis.

This is the same method as tailoring your resume to a job description: read the posting, note the skills and keywords it repeats, and let the projects that genuinely use those skills go first. Use the posting's language where it is true. If they ask for "API design", and you built a REST API, say REST API. But do not rename things to match. Keyword alignment is honest when the underlying work is real; it is stuffing when it is not.

A practical way to work: keep a master list of every project with full details, then pick two to four per application. Running your draft through Tailr's ATS checker shows which of the posting's keywords your project bullets already cover and which are missing. The missing ones are a prompt to reconsider which projects you featured, not an invitation to invent experience.

The honesty rules

Projects are easy to exaggerate because nobody checks coursework the way they check employment. That is exactly why the honesty bar is higher here. Four rules:

1. Label academic and tutorial work as such. "Course project" and "tutorial follow-along" are honest labels, and there is no shame in them at entry level. Rebranding a tutorial as a personal build is the fastest way to get caught: one interview question about a design decision will expose it.
2. Claim your contribution, not the team's. On group projects, say what you did: "built the data pipeline" not "built a data pipeline with my team" left vague, and never "led" unless you actually led. Interviewers ask follow-ups on whatever you claim, and "we" answers to "you" questions end interviews.
3. Numbers must be true. If the 17% figure was measured, say how. If it was not measured, do not invent a number. An honest qualitative outcome ("the driver uses it every morning") beats a fabricated metric.
4. Only link to work you can defend. If you cannot explain the design of the project in two minutes, the line should not be on the page.

Three mistakes that tank a projects section

• The kitchen sink. Six projects, one bullet each, none memorable. Two deep entries beat six shallow ones. Cut anything you would not want to spend five interview minutes on.
• Coursework with no outcome. "Implemented sorting algorithms in Java" is a line from a syllabus, not a project. If the only outcome was a grade, the entry is not doing any work for you. Cut it, or add what you actually produced: a benchmark comparison, a write-up, a working demo.
• Keyword-stuffed entries. A tools line that reads "Python, Java, C++, TensorFlow, React, Docker, Kubernetes, AWS" on a student project tells the reader you listed a glossary. List the tools the project actually uses. Screening systems and humans both penalise stuffing; it reads as noise.

The 60-second projects-section audit

Before you send the resume, run this check:

1. Does every entry have a name, a context line, and bullets with outcomes? Any entry missing one of the four parts is a draft, not a line.
2. Are these the right projects for this posting? The featured projects should overlap with the posting's skills. If a stronger match is sitting in your master list, swap it in.
3. Could you defend every line in an interview? If a follow-up question would expose exaggeration, cut or correct the line now.
4. Is anything here just filling space? One strong project beats three thin ones.
5. Do the links work? Open every repo and demo link. A dead link is worse than no link.

Projects are not a consolation prize for a short work history. They are evidence of what you can build, presented in a format that both humans and screening systems can read in seconds. Pick the projects that match the posting, write them as proof, keep every claim defensible, and the section will do more work than any job title could.