How to list class projects on a new grad resume
Class projects count as experience when you write them as work: a name, what you built, your part on the team, the tools, and a result. Here is one entry, taken apart line by line.
If you just graduated, your class projects are your experience. Not a consolation prize for missing an internship. Real work, with a deadline, a team, tools, and something at the end.
The catch is how you write them. Listed as coursework, they read like homework. Written as work, they read like a job. Here is a finished entry. Keep this page open next to your resume and fix yours one line at a time.
- Built a web app that pairs students driving home on the same weekend by route and departure time.
- On a team of four, designed the matching algorithm and the database schema; wrote 48 automated tests for the matching logic.
- Demoed live at the department showcase; the campus sustainability office asked to pilot it. Code at github.com/yourname/rideshare.
Read it top to bottom: a name, the tools, the term, what it does, your part, and a result someone could check, with a link at the end. Each piece gets its own section below.
The name: call it what it is
The first thing on the line is a project name a stranger understands. Not the course code. A recruiter at a company across the country has no idea what your school's numbering means, and the code tells them nothing about what you made.
If the project never had a name, give it a descriptive one. "Soil Microplastics Survey" is honest. So is "Bridge Load Sensor (Senior Capstone)". You are labeling the work, not rebranding it.
The tools and the term: same line, after the name
Put the tools right on the title line, separated by a middle dot. Recruiters and the ATS (applicant tracking system, the software that stores and searches applications) both look for tool names, and the title line is where a skimming eye lands first.
Name the actual tools. "Various technologies" is a blank space with a period at the end. For non-software work, tools still apply: Excel, SPSS, R, Canva, SolidWorks, a fluorescence microscope, a survey platform.
Then the term, as season and year. It tells the reader the work is recent and how it fits next to your other entries. Skip month ranges; a semester is a semester.
Bullet one: what you built
Start with a verb and say what the thing does, for whom. Built, wrote, designed, measured, tested, analyzed. One sentence. If a friend outside your major can picture the result, it works.
"Worked on" is the phrase to hunt down first. It tells the reader you were near the project. It does not say what you did. Swap in the real verb every time.
Bullet two: your part on the team
Most class projects are group projects, and the reader knows it. Pretending you built the whole thing alone is a lie that falls apart at the first interview question. Hiding behind "we" is the opposite mistake: the reader cannot tell what you can do.
The honest version has two pieces. The team size, then the slice you owned. That is it. You do not need to apologize for working on a team. Every job is a team.
A useful check: could you talk for a few minutes about the slice you named, with no notes? If yes, it belongs on the line. If a teammate would have to answer the follow-up, name a smaller slice that is truly yours. Smaller and specific beats big and vague.
Bullet three: the result, even with no users
This is the line most new grads skip, and the one that does the most work. A result is something that existed or changed when the project ended. Class projects rarely have customers, so the result looks different from a job bullet. It still exists.
The grade is the weakest option. Everyone who passed the class has one. Stronger results, roughly in order:
- Someone adopted it. A professor reused your tool in a later section. The bakery owner changed her pricing. A lab kept your protocol.
- It ran. A working demo, deployed somewhere a reader can click.
- It was checked. Automated tests and how much of the code they cover (test coverage), a reproducible analysis, a design that passed a load test.
- It was shown. A presentation to a client, a poster at a symposium, a showcase, a competition entry.
If the honest answer is "it worked and I turned it in," say what worked. "Shipped a working demo with a test suite" is a real result. It is checkable, and a hiring manager can ask you about it.
The link: let them see it
If the work lives somewhere public, link it. A repo, a live demo, a slide deck, a poster PDF. Put a short, readable URL at the end of the result bullet or on the title line. No raw tracking links, no "click here".
Before you link, open it as a stranger would. A repo with a one-line README and a folder called "final_FINAL_real" works against you. Add a short README that says what the project does and how to run it. For group repos, the commit history shows your part on its own, which backs up bullet two.
If the work is private (a client's real numbers, a class policy against posting solutions), skip the link. The entry still stands on its bullets.
What to leave off
- Course codes. Nobody outside your school can read them.
- "Worked on", "helped with", "assisted", "responsible for". Each one hides the verb you need.
- "Various technologies". Name them or cut the phrase.
- The grade as the only result. Keep a strong GPA in Education, where it belongs.
- The assignment prompt. "Students were asked to design..." describes the class, not you.
Build your entry
Pick your strongest project and fill the fields below. The entry builds as you type and flags the phrases above when it spots them. Load a sample to see how a marketing plan or a lab study fills the same shape.
Write one project entry, live.
Fill the six fields. The entry assembles as you type and flags anything that reads like homework instead of work.
A name a stranger would understand. Not the course code.
Start with a verb. What does the thing do, and for whom?
Team size, then the slice you owned. Use "I" and a real verb.
Comma separated. Name them; never write "various technologies".
Season and year, like Fall 2025.
What existed or changed at the end. A demo, tests, a user, a decision.
Start typing, or load a sample above.
Where the Projects section goes
Now the section-level calls. Order your resume by what is most relevant to the job you want, not by habit.
- No related jobs yet: Education first, then Projects, then any other work (retail, campus jobs, tutoring). Projects are your strongest evidence, so they sit high.
- A related internship: Education, then the internship under Experience, then Projects. Paid work in the field outranks class work.
- A project more relevant than your internship: Projects can go above Experience. Relevance to this job decides, not which one paid.
Keep unrelated jobs on the page. A semester of serving tables shows you show up. It just goes lower.
How many, and which ones
Two to four projects is the usual range for a one-page new grad resume. Fewer and the section looks thin. More and each entry gets squeezed into one weak line.
Choose by relevance to the job posting, not by size. A small data-cleaning script beats a huge game engine if the job is a data analyst role. A short pricing analysis beats a long brand campaign if the posting is for a finance-minded marketing role.
Read the posting, circle the tools and tasks it names, and pick the projects that match the most circles. You can swap projects between applications. That is what a tailored resume is.
Open your resume in the free editor, pick one project, and rewrite it in this shape tonight: name, tools, term, what you built, your part, and the result. Your words, not AI. Then do the next one.