Projects on a resume: what counts as evidence, and where to put it

The short answer

A project belongs on a resume when someone who has never met you could confirm that it exists, work out what you personally did, and ask you about it for ten minutes without finding the floor.

That is a higher bar than the usual advice, which asks whether the project is impressive. Impressive is not checkable. Everything below is about applying the checkable version and then deciding where the project sits.

• Paid or assigned work goes inside the role it belonged to.
• Independent work that passes every question can hold its own section.
• Work you cannot describe your own part in is a link, at most.
• Work that answers nothing in the posting comes off the page.

Five questions that decide it

Ask these in order and stop at the first no you cannot fix. They are ordered by how quickly a reader hits them: relevance decides whether anyone reads on, and the defence question only matters if you reach an interview.

Count the answers. Five yeses and the project can carry a full entry. Three or four and it earns one line or a link. Fewer than three and it is taking space from something that would work harder.

• Relevance: does it answer a requirement the posting actually states?
• Artifact: is there something a stranger could open, read, or see?
• Ownership: can you state your own part in one sentence, without the word we?
• Method: could you defend how you did it for ten minutes under questioning?
• Outcome: did it produce a result you can describe without inventing a number?

Where it goes, and the one documented reason to prefer work history

If the project was paid, assigned, or done inside a job, it is not a project on your resume. It is what you did in that job, and it belongs in the bullets under that employer. Placing it separately strips the two details that make it credible: who you were working for, and when.

There is a second reason, and it is the part almost nobody writing about this mentions. Workday's own documentation of what an external application parses lists personal and contact information, work experience, education and languages. Projects are not among those fields.

Read that carefully, because it is easy to over-conclude. It does not say a Projects section is discarded, or that a parser cannot read it, or that a recruiter will not see it. The uploaded file usually remains attached and readable. What it says is that the structured record the system builds is organised around employment and education, so work sitting in a separate section may not arrive inside that structure.

The limit on that argument is worth stating too. We looked for vendor documentation requiring particular section headings and did not find any across the systems we checked. Absence of documentation is not evidence of behaviour. A dedicated Projects section is a reasonable choice, not a formatting mistake, and the field list is a mild preference rather than a rule.

For independent work, university career services are unusually consistent about naming. The College of St. Scholastica suggests course projects can sit inside the Education section or in a separate one headed Academic Experience, Project Experience, or Relevant Projects, and advises matching the terminology used in the job posting. That last part is the useful half: the heading should use the employer's word for the work, not yours.

• Paid, client, or in-role work: inside the employer entry it belonged to.
• Independent work passing all five questions: its own section, named after the posting's language.
• Coursework: under Education, unless it is the strongest evidence you have.
• Passes artifact but not ownership: a portfolio link in the header, no entry.

Writing the entry so it survives a question

Once a project has earned its place, the entry has four jobs: say what it was, say what you did, say how it was built, and let the reader check. The technical projects guide published by the University of Texas at Austin's College of Natural Sciences career service puts the same list in practical terms: document what you accomplished, the functionality, which technologies you used, and include a link to the repository or a demo so a recruiter can see it working.

The link is the part people leave out, and it is the one doing the most work. It converts a claim into something inspectable, which is the whole argument for putting the project on the page.

Keep the entry short. Two or three lines is enough for anything that is not your main evidence, and a project that needs six lines is competing with the job history it is supposed to support.

Tutorial projects and work an AI tool mostly wrote

Two versions of the same worry. If you followed a tutorial end to end, or if a coding assistant produced most of the output, is the project yours to claim?

The test does not change, and it answers this cleanly. Ownership asks what your own part was. For a tutorial, the defensible claim is what you changed and why: the dataset you swapped in, the part that broke when you did, and how you fixed it. For work produced with an AI tool, the defensible claim is what you specified, what you rejected, and what you checked. Both are real contributions and both are describable.

What fails is presenting the finished object as though you built it from nothing. That fails at the method question, not on principle: an interviewer asks why a particular choice was made, and there is no answer, because the choice was made by someone or something else.

The honest version usually reads stronger anyway. A candidate who says which parts they verified sounds like someone who has worked on real systems. A candidate who claims uniform authorship of everything sounds like a candidate.

• Tutorial work: claim the modification and the debugging, not the architecture.
• AI-assisted work: claim the specification, the rejections, and the verification.
• Either way, expect the method question, and answer it in the entry rather than waiting for it.

When to take it off again

A projects section is borrowed space. Every line it occupies is a line the reader is not spending on paid work, and the balance between those two changes as your career does.

The rule that works: once you have relevant paid experience demonstrating the same capability, the project has done its job. A data analyst two years into an analytics role does not need the coursework capstone, because the job proves the same thing with an employer's name attached.

The exception is a project that shows something your paid work does not. An engineer whose job is entirely backend, applying for a role that wants some front-end exposure, is right to keep the side project that shows it. That is the project answering a requirement nothing else on the page covers, which is the first question all over again.

Review this at the same moment you review anything else on the resume: when you tailor for a specific posting. The project that earns its place for one role often does not for the next.

What we checked, and what we could not

The placement argument here rests on published vendor documentation and on university career services guidance, both read directly. The parsed-field list comes from Workday's own administrator documentation. The naming and placement options come from career services pages at the College of St. Scholastica and at the University of Texas at Austin, read on 13 September 2026.

What does not exist, as far as we can find, is a study measuring outcomes. Nobody has published research that takes a large sample of applications, varies whether a project appears and where it sits, and reports the effect on interview rate. Any article telling you that a Projects section raises your chances by some percentage is not working from such a study, because there is not one to work from.

So the advice here is built on what can be established: what the systems document about the fields they extract, what careers services consistently recommend, and what an interviewer can and cannot verify about a claim. Where a number would need an outcome study behind it, we have left the number out.