Most CVs have no projects section, and most of the ones that have one would be better off without it. A list of weekend experiments under a heading called "Projects" tells a recruiter you like tinkering, which is pleasant to know and rarely gets anyone an interview. The section is worth its space only when it does a job your experience section cannot do, and there are exactly three such jobs.
When a projects section earns its place
Before writing anything, check whether one of these applies. If none does, cut the section and give the space back to your roles.
Your employment history is thin
Graduates, career changers and anyone coming out of a long stretch without paid work share the same problem: the experience section is short, or it points somewhere other than the job they want. A well-written project fills that stretch with evidence. It is not a substitute for employment, and recruiters know that, but it shows what you did with time you controlled, which often says more about you than what an employer told you to do.
The project proves a skill your paid work does not
An accountant who built a cash-flow model for a local charity. A support agent who wrote the scripts that now tag half of the team's tickets automatically. In both cases the job title hides a skill the target role cares about, and the project entry is how that skill gets onto the page without bending the truth about the job itself.
The work itself is the deliverable
For developers, designers, writers, data analysts and researchers, the output is the proof. A hiring manager filling a front-end role would rather see the app you shipped than read that you are "passionate about clean code". Here the projects section is not an extra. It is often the second thing they read, right after your current role.
Outside these three cases, a projects section is usually filler. A framework you learned by following a tutorial, a game you started over a long weekend, a personal blog with four posts: these are fine to mention in an interview if they come up. They do not need a heading.
How to write an entry that reads as work, not a hobby
The gap between a project that reads as work and one that reads as a hobby is almost entirely in the writing. Hobbies get described by what they are. Work gets described by what it did. For each entry, cover these points in two to four lines:
- The problem. What was broken, slow, missing or unknown before you started?
- Your role. Solo, or part of a team? If a team, say what was yours and what was not. Overclaiming a group project is the fastest way to lose credibility in the interview.
- The constraint. A deadline, a budget of zero, a legacy system, a data set nobody had cleaned. Constraints are what make a project read like a job.
- The outcome. What changed. A number if you have an honest one, a concrete result if you do not.
- Whether anyone else used it. This is the line most people leave out and the one recruiters care about most. Users, downloads, a client, a team that adopted it, a maintainer who merged your change.
Here are two versions of the same project.
Weak: "Budget app. Built a personal finance app using React and Firebase."
Strong: "Shared expense tracker (solo, 2024). Built a web app for a flat of five people who were settling bills through a spreadsheet nobody trusted. Shipped in six weeks alongside a full-time job; used weekly by the flat for a year, then picked up by two other households."
The second one is barely longer. It just answers the questions a recruiter would ask anyway.
Give each project a name, your role and a date range, and if the format allows, say where the work can be seen. Put tools and languages in a short tail at the end of the entry rather than at the start. Tools are context. They are not the point.
A project reads as work when it has a problem, a constraint and someone other than you who got something out of it.
The abandoned project question
People often ask whether an unfinished project belongs on a CV. The honest answer depends on what you got out of it before you stopped.
If the project stalled before it produced anything, leave it out. If it reached a real milestone and then stopped, you can include it, as long as you describe the milestone rather than the original ambition. "Prototype tested with 12 users before the project was paused" is a truthful and useful line. "Building a platform to transform local commerce" with no end date is a promise you will be asked about.
Do not hide that it stopped, either. Recruiters can read a date range that ends, and a short note on why ("paused after the pilot showed the real problem was distribution, not the tool") reads as judgement. Knowing when to stop something is a skill plenty of teams wish they had more of.
One specific habit to drop: writing "ongoing" next to a project you have not touched in six months. It is the most stretched word in this section.
Internal projects in an otherwise flat role
Your job title and day-to-day duties are unremarkable, but inside that job you led or contributed to one project that is genuinely interesting. A data migration, a new supplier onboarding process, an internal tool your old team still uses.
The default is to keep it under that job, as the first and strongest bullet. The project happened on your employer's time and with their resources, and a recruiter reading the role expects to find it there. Pulling it out into a separate section can make the role look emptier than it was. Worse, it can read as an attempt to make one project look like a career.
There are two exceptions. If you have several internal projects across different employers that all point at the same target skill, a short "Selected projects" section can group them and make the pattern obvious, with each entry naming the employer it was done for. And if one internal project is the single most relevant thing on your CV for the role you want, you can surface it in your profile summary as well as under the job. Mention it in both places, but write the full description only once.
An internal project can also rescue a patchy stretch: a contract that was mostly one deliverable often explains a period better than a job title does.
Where the section goes relative to experience
Placement follows the same logic as everything else on a CV: the most relevant evidence goes highest.
- Experience is strong and relevant: projects go after experience, and often after education too. They support the story. They are not the headline.
- Experience is thin or pointing elsewhere: projects go directly after your summary and before experience. A recruiter hiring a junior analyst wants to see the analysis you have done before reading about your retail shifts.
- Your work is the deliverable: put the two or three strongest projects high, and leave the rest for a portfolio or a link in your header.
Three to five projects is usually the right number. Beyond that, the section starts to look like a list of everything you ever opened in an editor. If you build your CV from a LinkedIn profile with a tool like Postulit, check what comes across from the profile's projects list and prune it, since profile entries are often written for a different reader than a CV is.
Using a side project to test a new career, building a full portfolio, the LinkedIn version of this section and the separate achievements section are all different questions, and this one stays on the CV section itself.
What to do this afternoon
Open your CV and go through each project entry. For every one, ask whether it fits one of the three cases: a thin history, a skill your jobs do not show, or work that is itself the proof. Delete the ones that do not fit. Rewrite the rest so each answers problem, role, constraint, outcome and who used it, in four lines or fewer. Then decide where the section sits based on one question: is your experience section already carrying the CV, or does it need help? An afternoon spent on this will do more for your CV than adding another project.