Stop Describing Your Projects Like This on Your CV

A reviewer spends between eight and twenty seconds on a junior CV before deciding whether to keep reading. In that window they are scanning for concrete nouns: technologies, systems, numbers, verbs that describe building something.

Most student project bullets contain none of those. Here are the six that appear most often, and what to write instead.

1. "Worked on a group project using Java"

Why it fails. "Worked on" describes attendance, not contribution. It also raises the question it was trying to avoid: which parts did you write?

Instead: name your part, and the thing it does.

Built the authentication service and REST API for a 4-person library system (Java, Spring Boot, PostgreSQL) — 14 endpoints with role-based access control

Being precise about a well-defined contribution is more impressive than implying you built everything. Interviewers ask, and vagueness reads as either overstatement or not understanding the codebase.

2. "Developed a full-stack web application"

Why it fails. It could be anything. It describes a category, not a thing.

Instead: say what it does and who uses it.

Built a fixture-management app for three amateur football clubs (Next.js, Postgres) — used across a full season for ~120 fixtures

The number does most of the work. It does not need to be big; it needs to be real.

3. "Used HTML, CSS, JavaScript, React, Node.js, Express, MongoDB, Git, Docker and AWS"

Why it fails. A technology list is not a description. It also triggers the obvious question — you listed ten things, which of them can you actually discuss?

Instead: name the three that matter to the bullet, and put the rest in your skills section.

Built a REST API serving 12 endpoints (Node.js, Express, MongoDB) with request validation and 80% test coverage

If Docker and AWS were genuinely part of the project, they earn their own bullet about deployment. If they were one tutorial each, they do not belong on the CV at all.

4. "Implemented various features and fixed bugs"

Why it fails. "Various" is the word people use when they cannot remember. It describes maintenance rather than construction.

Instead: pick the single most interesting thing you did and describe it specifically.

Diagnosed and fixed a timezone defect where fixtures shifted by an hour after DST — migrated storage to UTC and added regression tests across the boundary

One specific bug you can explain beats "various bugs" every time, because it demonstrates diagnosis rather than activity.

5. "Responsible for the front-end design and user experience"

Why it fails. "Responsible for" is job-description language, not evidence. It describes a remit rather than an outcome.

Instead: lead with the verb and say what changed.

Rebuilt the booking flow as a 3-step form with inline validation, cutting abandoned bookings from 40% to 12% across one term

If you do not have a number, describe the concrete work instead:

Built a keyboard-accessible component library (modal, dropdown, tabs) with focus trapping and correct ARIA roles, used across all three project pages

6. "Personal project to learn React"

Why it fails. It frames the project as practice rather than as work. A reviewer reading "to learn X" mentally files it under tutorial.

Instead: describe it as a thing that exists, and let the learning be implicit.

Built a spaced-repetition flashcard app implementing the SM-2 scheduling algorithm (React, IndexedDB) — works fully offline, used daily through two exam periods

Everything is a learning project. Saying so out loud is what makes it sound like one.

The pattern that works

Three lines per project, each following the same shape:

[Verb] [what] [(stack)] — [what happened]

Built, designed, implemented, migrated, diagnosed, deployed. Not "worked on", "helped with", "was involved in".
The thing itself, concretely.
Two or three technologies in brackets. Not ten.
An outcome, a number, or a specific technical detail.

A worked example:

Society Events Platform — Django, PostgreSQL, Redis

Built event sign-up used by 3 university societies for ~400 registrations over one term

Prevented capacity oversell by moving the limit into a database constraint after load testing found a race between concurrent sign-ups

Added transactional email and CSV export, used weekly by committees

Three lines. A reviewer scanning that in eight seconds picks up: real users, a real number, a concurrency problem understood and fixed, and evidence the thing is actually in use.

On numbers you do not have

Do not invent them. "Improved performance by 40%" with no measurement behind it collapses on the first follow-up question.

You have more real numbers than you think:

How many people used it
How many endpoints, tables, components, or records
How long it ran for
Before-and-after on anything you measured — memory, response time, file size, build time
Test count or coverage, if you have it

"Used by 20 people on my course" is a real number. "Reduced peak memory from 1.2 GB to 40 MB by streaming the file" is a real number. Both are more convincing than a fabricated percentage, precisely because they sound like things that actually happened.

If you genuinely have no number, describe the technical specifics instead. Detail substitutes for measurement.

While you are there: the skills section

Delete the percentage bars and the five-star ratings. Technical reviewers dislike them consistently, and "Python — 87%" is not a claim anyone can evaluate.

List technologies grouped by category:

Languages Python, Go, SQL, TypeScript Data PostgreSQL, Redis, SQLite Tools Docker, GitHub Actions, Linux

If you want to signal depth honestly, split into "used in a deployed project" and "used in coursework and side projects". Reviewers find that genuinely informative and it costs you nothing.

Where the bullets come from

Writing three good lines from scratch is hard. Writing them from a case study you have already written is easy.

Write the project up properly first — problem, users, approach, architecture, challenges, result, lessons — then compress the approach, architecture and result sections into three lines. The full version becomes your website copy and your interview answer; the compressed version goes on the CV.

That is one piece of writing doing three jobs, which is the only reason it is worth the 45 minutes.

The project case-study template is in the free toolkit, and the developer CV guide covers the rest of the page structure.