The projects section: how to describe your work so it stands up to questions

For people with a short work history, a career switch or a field where the work itself is the proof, the projects section can be the strongest part of a resume. It shows what you can do without waiting for a job to say so.

It is also the section where careless writing hurts most. A project described as a topic ("Weather app") tells the reader nothing about you. A project described as work, with your part clear and your choices visible, tells them a great deal. This guide is about writing the second kind.

Which projects to include

Choose projects that do one of three things:

• They are relevant. They use skills or tools the target role needs, or they sit in the same field.
• They are finished. Something that works, even in a small way, is worth more than an ambitious plan that stopped halfway.
• They show how you think. Even a small project can show how you broke down a problem and made decisions.

Leave out anything you could not discuss for a couple of minutes. If a project was mostly following a tutorial, be clear with yourself about that, and either include only the part where you went further or leave it out.

Two to four strong projects is usually the right range. If you have many, pick the best and keep the others in a portfolio or a repository you link to.

How to write one

Each entry can be short: a title, a line of context, and two or three bullets. Answer these questions:

1. What was it, and why did you make it? One line of context. "A budgeting app for students who share a flat."
2. What did you use? The tools, languages, materials or methods, in a few words.
3. What did you do, and what came of it? The actions you took and anything that resulted: it works, it was used, it was tested, people gave feedback.
4. What part was yours? If you worked with others, say how many and what you owned.

Here is the "Weather app" from the start of this guide, after those questions:

And here is a fuller entry, with a title line, built from the same answers:

Shared Expenses Tracker (Android, Kotlin), personal project, 2025. Built an app for flatmates to log shared bills and see who owes what. Designed the data model and wrote the settle-up calculation, then tested it with five flatmates over three months and fixed the two bugs they reported.

The reader learns what it is, what tools were used, what you did and that real people used it. None of it needs an invented number.

A different example, not about software

Projects are not only for programmers. The same shape works in other fields.

Neighborhood Market Survey, university research project, 2025. Surveyed 120 shoppers across three local markets about prices and choice, cleaned the responses in a spreadsheet and presented the findings to the class. Recommended two changes to stall layout, one of which a market committee later tried.

Trade and catering courses are full of projects too, and students often list them as a single word. A workshop or kitchen project shows practical skill in exactly the way a manager wants to see.

A designer, writer, analyst, teacher, event organizer or lab researcher can all write entries in the same way: what, with what, what you did, what came of it.

Group work

Many projects are done in teams, and employers know it. The mistake is writing "we" throughout, so the reader cannot tell what you did. Name the team size and say plainly what you did.

That is honest, and it is easy to ask about. If you led the team, say what leading meant: setting the plan, splitting the work, merging the code, presenting the result.

Links and proof

If the work is public, link to it: a page where it runs, a repository, a portfolio, a short demonstration. A link lets a reader check for themselves, and many people will.

• Test every link before you send the document, on a device that is not signed in as you.
• Make sure the page makes sense to a stranger. A short description at the top of a repository helps a lot.
• Do not link to anything that includes private information, an employer's confidential material or client data you were not allowed to share.
• Link text should be short and readable, such as the domain or a project name, rather than a long web address that wraps over several lines.

For physical work, a few photos of the finished piece do the same job as a link to code. If the project is private or confidential, say what you can without breaking any agreement, and be ready to describe it in conversation. How to present the links themselves is covered in links, LinkedIn and portfolio.

Order and placement

Put the most relevant project first, not the oldest or the biggest. If you have little work experience, place the section directly after education or even above it. If you have a long work history, shrink the section to your best two items, or move it lower, since your jobs are doing the main work.

This is how a single strong entry sits on the page:

Mistakes to avoid

Listing the topic only. "E-commerce website" says nothing. Say what you built and what you did.

Listing every tool in the world. A line of fifteen technologies suggests you touched each one and mastered none. Name the ones that mattered.

Making up results. Do not invent users, downloads or figures. A small true result, such as five people used it for three months, beats a large false one.

Leaving the project unfinished. A project that never ran needs honest wording or a place in your own notebook, not your resume.

Forgetting to keep it current. A project from six years ago, in a field you have moved on from, may no longer deserve a place.

Software reading the section

Keep each entry as normal text, with the title on its own line and the details beneath. Avoid putting projects in side boxes or tables. If links are important, also write the name of the site or repository in plain words, in case the link itself is not carried through.