Resume guide

How to list certifications and projects on a resume.

Certifications and projects can fill the gap when work experience is thin — but only if they're presented well. This guide covers which ones are worth listing, where they belong, and how to describe them so they read as evidence rather than decoration.

1. Which certifications are worth listing

A certification is worth listing when it satisfies at least one of these:

  • It's expected in your field. (CPA for accountants, AWS Solutions Architect for cloud engineers, PMP for project managers, nursing licences for nurses.)
  • It required real study. A weekend "certificate of completion" carries far less weight than a programme with an assessment.
  • It verifies a skill you want to use. A recognised SQL certification helps if you're applying for a data role, even if you have no work history using SQL.

Skip certifications that:

  • Are easily obtained and not respected in your field.
  • Are unrelated to the job you're applying for.
  • Are expired, and you don't plan to renew.
  • Are being used as filler to pad the resume.

2. How to format certifications

Each entry needs three things: the name of the certification, the issuing organisation, and the date (year is usually enough).

AWS Certified Solutions Architect — Associate
Amazon Web Services · 2024

If you have a credential URL or ID, include it for credentials where verification is common (AWS, Google Cloud, Microsoft). For certifications where verification is less common, the credential link is optional and can crowd the resume.

3. Where certifications go

Placement depends on relevance. If a certification is the primary reason you're qualified for the job, put it high — sometimes before education. If it's supporting evidence, put it near the bottom in a "Certifications" section.

A good rule: the resume should read in the order that makes the strongest case for you. If a certification is that case, it belongs near the top.

4. Which projects are worth listing

Projects worth listing on a resume are ones where:

  • You built, wrote, shipped, or researched something. Not "participated in" something.
  • There's a tangible output — a URL, a GitHub repo, a published paper, a deployed app, a finished piece of work.
  • You can describe what was hard about it. A project that "worked on the first try" often isn't as interesting to describe as one where you solved a specific problem.

Projects not worth listing:

  • Group projects where your contribution is unclear.
  • Coursework that was just following a tutorial.
  • Toy projects with no real use case, unless they're a learning vehicle for a skill you can't demonstrate otherwise.
  • Anything you can't describe in two sentences without referencing someone else's work.

5. How to describe a project

For each project, aim to include:

  • Title — the project's name.
  • Role — solo, or your specific role on a team.
  • Link — GitHub, live demo, portfolio page.
  • One-line description — what it is and what it does.
  • Two bullets on what you did and what was hard. These should read like mini experience bullets.

Example:

A11y Checklist — Solo project · github.com/example/a11y-checklist
A small open-source tool that generates a printable accessibility checklist for a given set of WCAG criteria.
· Built with vanilla JavaScript and no build step, so it runs from any folder.
· Used by roughly 300 developers in the first three months after release.

That's one project in three lines, and it tells a reader more about your capability than any generic bullet ever could.

6. When to use projects instead of experience

If you have real work experience, projects usually belong below it — they're supplementary evidence. If you have little or no work experience, projects can take the place of Experience on the resume. In that case, describe them as fully as you would describe a job, with the same attention to outcomes and specifics.

7. Final checklist

  • Does every certification you list genuinely belong to you and remain valid?
  • Have you included the issuing organisation and date?
  • Is the certification section placed where it helps you most?
  • Does every project have a link and a role?
  • Do your project bullets describe outcomes, not just features?
  • Have you removed any project that you can't describe without referencing someone else's work?