Projects on a Resume: When to Add Them and How to Describe Them

Add a projects section when it carries evidence that your work history does not: you are early in your career, changing field, or applying where the work itself is the proof, as in software, design, data or writing. Choose two to four projects that match the job, describe each in two or three lines with what you built, how and what happened, and link to the work if it is public. Leave the section out if your experience section already shows the same skills.

A project is only useful on a resume if a reader can see what you did and why it matters for this job.

When it helps

What to choose

Pick projects that satisfy three tests:

1. Relevant: they use skills the job asks for.
2. Complete: they reached a result you can describe, even a small one.
3. Yours: you can explain every decision in an interview.

A small finished project beats an ambitious unfinished one. If the project was a team effort, say how many people and what your part was.

How to describe a project

Use a short header line with the name and context, then one to three bullets:

"Customer churn analysis (personal project, 2025)

• Analysed 18,000 anonymised telecom records in Python to find the strongest predictors of cancellation.
• Built a logistic regression model that flagged 70 percent of churners in a test set, and presented the findings in a short report.
• Published code and write-up on GitHub: github.com/yourname/churn."

The formula is the one used for work bullets: action, scope, result. See how to write resume bullet points. Include the tools you used, since that is where the project doubles as evidence for the skills section.

Links

If the work is public, link to it: a repository, a live site, a portfolio page or a published piece. Use a short, clean URL, and check it works from a device you are not logged in on. Make sure the repository has a readable description, since a reviewer may spend one minute on it. Do not link to anything you would not want seen: a messy repository with no explanation can work against you.

If the work is confidential, describe it generally and say so: "Redesigned an internal approvals workflow for a financial services client (details confidential)."

Examples by field

Software:

• "Weather alert bot (side project, 2025): built a Telegram bot in Python that sends severe weather alerts to about 120 users, using a public API and a scheduled job."

Design:

• "Mobile booking app redesign (case study): interviewed eight users, reduced the booking flow from seven screens to four and tested the prototype with five participants."

Marketing:

• "Local bakery newsletter (volunteer): wrote and sent fortnightly emails to 600 subscribers; open rate rose from 28 to 36 percent over three months."

Research or writing:

• "Dissertation on remote work and team trust (university): interviewed 15 managers, coded themes and presented findings to a department seminar."

Examples like these are illustrative. Your own should use your facts.

Where to put the section

For early-career candidates, after education or experience, or even above experience if it is stronger. For experienced candidates, a short "Selected projects" block near the end, or integrated into the job description it belongs to. In a freelance career, group projects under a heading such as "Selected client work", with a short line for each.

Mistakes to avoid

• Listing course assignments that everyone in the class completed.
• Including projects with no outcome.
• Claiming sole credit for team work.
• Dumping tool names without saying what you did.
• Listing ten projects when only three are relevant.

Match them to the job

For each application, check which projects fit the role and move those up. Remove those that do not. This is part of building a targeted resume. For students, a short section sits well in a student resume, and for people with no job history at all, it is often the core of the page: see how to write a resume with no experience.

How to start a project in a weekend

If you do not have a project yet and the job asks for evidence, a small one is enough.

1. Choose a problem you understand, ideally one a real person has. A friend's spreadsheet, a local club's website or a public dataset on a topic you like.
2. Set a small scope you can finish in two days.
3. Build it, and write a short README or one-page summary: the problem, what you did, what you found and what you would do next.
4. Share it, even with two people, and ask what was unclear.
5. Add it to your resume with one or two bullets.

A finished small project with a clear write-up is more convincing than a half-built large one.

Open-source and community work

Contributions to open-source projects, local groups or public datasets count as projects. Name the project, say what you changed, and link to the contribution. Even a documentation fix or a bug report shows you can read someone else's work and improve it. List only contributions you can explain, and keep the description factual: "Fixed a date parsing bug in the X library (merged pull request)."