How to Put Projects on Your Resume

A project can show relevant work that your job title does not capture. It can also become a vague entry listing tools without explaining what you built. The difference is whether a reader can identify the problem, your contribution, and the deliverable without opening a link.

Choose projects that support the role you want and describe them with the same factual discipline as employment. A personal exercise can be worthwhile, but it should not be presented as a company engagement. A team result can be impressive, but your bullets should make your own work visible.

Select projects by relevance and substance

Start with the target posting. Identify the tasks and tools you can demonstrate through completed work. Then choose the project that provides the clearest evidence. A smaller finished project with a documented method can be more useful than an ambitious idea with no working result.

Assess whether the project adds something the rest of your resume does not already show. If your employment bullets establish the same capability in a stronger context, the project may not deserve much space. If you are entering a field or changing careers, it may be one of your most relevant pieces of evidence.

Keep a short selection worksheet: target requirement, project evidence, your role, and the artifact you can explain. For the wider process, see resume tailoring. Relevance determines which project belongs on the page; honesty determines how you describe it.

Label the setting and your contribution

Use a clear project name, date or date range where useful, and a context label such as Personal Project, Academic Project, or Volunteer Project. A reader should not need to discover later that a supposed client project was a classroom simulation.

For collaboration, describe your responsibilities separately from the final team output. 'Built the data-cleaning script for a group dashboard project' is more informative than 'Developed a complete analytics platform' if you only worked on one component. Use verbs that reflect your level of contribution.

If an assignment supplied starter code, a dataset, or a design brief, you can still describe the work you completed. Explain the implementation, analysis, or decisions that were yours. Do not imply original ownership of supplied materials, and follow any rules on publishing course or client work.

Write a bullet that contains an actual deliverable

A useful structure is action, problem or context, method, and deliverable. A fictional example: 'Cleaned a public housing dataset in Python, documented duplicate records, and produced a reproducible notebook comparing neighborhood trends.' The sentence identifies the work without claiming real-world policy impact.

Another fictional example: 'Designed an onboarding prototype in Figma and documented the navigation changes from peer feedback.' If the feedback came from classmates, do not call it a production usability study with customers. Clear context lets the reader evaluate the evidence at the right level.

Writing assistance can help turn a project description into a concise entry. Supply the actual context, tools, and deliverable first. Review any suggestion that turns a prototype into a launched product or a class exercise into professional experience.

Show methods without turning the entry into a stack list

A list of technologies does not explain how you used them. Name the few tools necessary to understand the work and put them beside the action they supported. If the project used a library only for a small utility, do not let that library dominate the entry at the expense of the problem solved.

Describe a meaningful technical or practical choice when relevant. You might explain that you used a validation script to check data before charting it, or separated reusable interface components from page-specific elements. Only claim decisions you actually made and can discuss.

For an unfinished project, say what has been completed. A working prototype, documented analysis, or tested component can be described honestly. Do not use present-tense ambition as if it were an achieved result. If nothing substantial exists yet, improve the project before giving it resume space.

Make the link useful and accessible

Link to a repository, portfolio page, document, or demonstration only when it adds evidence and can be shared appropriately. Check access in a private browser window. A link that requires your personal login or points to a deleted deployment creates friction rather than proof.

The destination should explain the project context, your contribution, setup or viewing instructions, and limitations. Remove secrets and private data before sharing code or artifacts. Your resume entry should still be understandable without clicking, because not every reviewer will open the destination.

• Check the destination without your logged-in account.
• Identify your contribution on the project page.
• Include instructions for viewing or running the work.
• Explain what the prototype does and does not do.
• Keep the resume bullet readable without the link.

Put the section where the evidence belongs

For an early-career candidate, Projects can sit near Education or above less relevant employment. For an experienced candidate, a short Selected Projects section may sit after the recent roles. Avoid repeating an employment project in a separate section unless the second entry adds useful detail and the relationship is clear.

Use familiar headings and a consistent format. If the page becomes crowded, reduce the number of projects instead of shrinking all the text. Resume templates can give you a structure, but the strongest evidence should determine how much space each section gets.

Choose one project and rewrite its entry today. Make the setting, your contribution, and deliverable explicit. Then check it against the target role and open the link as an outside reader. A project section should make your work easier to inspect, not ask the reader to infer it from a collection of tool names.

Common questions

Can I list a tutorial project?

You can describe what you completed and learned, but identify the tutorial context and avoid implying that the design or solution was entirely original. If possible, add your own extension or analysis so the entry shows decisions beyond following instructions.

Do all projects need numbers?

No. A working artifact, documented method, or clear deliverable can be useful evidence. Add numbers only when they describe real scope or verified results. Do not invent users, performance gains, or business impact to make a project sound complete.

Should projects go under work experience?

Use the section that accurately reflects the context. Academic and personal projects usually deserve a separate label. A project completed as part of your employment can be described within that role, where the relationship is clear.