Can You Put a Group Project on Your Resume?

Yes, under Projects. Name the component you owned rather than the app the team shipped. If the repo is public, so is the record of who wrote what. Here is the format.

By Howard Davner

Quick Answer: Yes. List it under Projects, and build the bullet around the component you owned rather than the app the team shipped: your piece, what it does, the team named once as context. If the repository is public, the commit history is public with it, so claim the thing the history already shows.

You have a capstone or a class project with three other names on it, and you are trying to work out whether listing it makes you look collaborative or makes you look like you were along for the ride. Both halves of the advice you have read argue about the team. The team is not the part that gets checked.

Where a group project goes on your resume

A group project goes in a Projects section, not Experience, unless the work was paid or done for a real client. Experience is for roles you held. Projects is for things you built, and a capstone, a course project, a hackathon build and a personal side project all sit in the same section with no job title attached.

Each entry needs four things, in this order:

• Project name, with a live URL if you have one.
• Your component, in the first person: the part you designed, built or owned.
• What it does, in plain words, for a reader who has never seen it.
• The stack, limited to the parts you actually touched.

Say "I" about your piece and name the team once. "We built a course-scheduling app" tells a reader nothing about you. Two or three projects is the normal count for a student resume, and how many projects belong on a resume is a question of how many you can defend, not how many you can list.

The bullet has one shape

Every good project bullet follows the same structure: verb, the component you owned, the project with the team size named once, then what it changed or made possible.

Vague: "Worked with a team of four to build a course-scheduling app for the CS department."

Specific: "Designed and built the conflict-detection logic for a four-person course-scheduling app, replacing the manual pass the department ran each term."

The team is still there, mentioned once, as context. Everything else in the sentence is your piece. If you have a real figure for the impact, use it. If you do not, drop the figure and keep the specificity. An invented metric is the one thing in that sentence that can genuinely hurt you, because it is the part an interviewer will ask you to break down.

Why "only list solo projects" is bad advice

Almost no work at a real job is solo. Engineers ship features inside a team. Analysts hand off dashboards someone else built the pipeline for. A rule that throws out everything you did not build alone throws out your most realistic evidence of how you actually work, which is the thing an employer is trying to predict in the first place.

The advice comes from a real problem, misdiagnosed. The problem is not the team. It is that most group project bullets are written as project summaries. "Contributed to a team project that built a course-scheduling app" could mean you wrote the scheduler or it could mean you made the slides for the final presentation. Vagueness is the risk, not collaboration.

How recruiters check what you actually did

Recruiters check by asking in the interview, and sometimes by looking before it. If the project is on GitHub and the repository is public, the record of who wrote which lines is public with it. Anyone holding the link can open the commit history. The Insights tab has a Contributors view that breaks commits down by person. The blame view on any file shows who last touched each line.

Nobody is running a forensic audit on a student resume. But a technical interviewer who already has your repository open, reading it before a call, is two clicks from seeing which files you touched, and those two clicks cost them nothing.

That cuts both ways, and the useful direction is the second one:

• If your bullet claims a component your commits do not show, the contradiction is sitting in public, and you will be answering for it live.
• If your commits do show it, you have something the bullet cannot carry on its own. The history is dated, attributed, and not written by you in a text box.

So the rule is not "be modest". It is: claim the thing the history supports, and claim it specifically. A repository is a weak thing to send into a first screen for reasons that have nothing to do with this, because it asks the reader to run something before it shows them anything. For the attribution question, it is the strongest evidence you have.

How to isolate your piece

Isolate your piece with one honest question: if the rest of the team vanished and someone asked you to rebuild your part from scratch, could you? If yes, it is yours to claim in the first person. If no, it is not yours yet.

Three ways to cut it:

• By component. You owned the login flow, the recommendation logic, the cleaning script, the financial model inside the deck. Name the component, not the app.
• By decision. You chose the schema, picked the framework, decided how the API was split, ran the interviews that set the feature list.
• By output. You are the one who deployed it, wrote the tests, or built the dashboard the rest of the team pulled numbers from.

If you genuinely paired on all of it and cannot separate the work, that is worth listening to rather than writing around. It probably belongs in the interview as a collaboration story instead of on the resume as a claim of ownership.

If the repo is not yours, the link is not yours either

Group projects usually live in one person's account or a course organisation, and that has two consequences most students meet late.

The link can disappear. If a teammate makes the repository private, or the course organisation is cleared out after the semester, the URL on your resume stops resolving and nobody tells you.

Forking it to your own account while you still have access preserves a copy. A fork also carries a visible "forked from" line at the top, which is honest and not a problem, but it does mean the copy does not read as yours at a glance.

The version with neither problem is a live URL you own. A deployed project works as resume evidence precisely because it does not depend on anyone else keeping a repository up, and turning a class project into something a recruiter can actually click is mostly a cleanup job rather than a rebuild.

When better wording will not fix it

If your piece cannot be separated from the team's, no amount of rewriting closes that gap. Wording is not the constraint.

What closes it is shipping your component on its own. The conflict-detection logic becomes a small tool that takes a schedule and shows the clashes. One input, one output, one screen, entirely yours, at a URL. It is smaller than the team project, and that is the point, because what gets evaluated in a first screen is not size. It is whether anyone can tell what you did.

That trade costs you something worth naming. A four-person app sounds more impressive than one narrow tool, and a resume carrying only the tool loses the evidence that you can work with other people. Keep both. They answer different questions, and a reviewer is asking both.

If you would rather not start from a blank page, Provieo's project builder takes the job description you are applying to and walks you from a scoped idea to a deployed URL that is unambiguously yours. Free to use, and your first deployed project is free.

The follow-up question to prepare for

The question to prepare for is "what part of this did you actually do". It is the fastest way for an interviewer to tell whether you understood the work or attended it, which is why it comes up so often on student resumes.

Before an interview, go through every group project bullet and write out, in plain words, what you would say. If the answer is fuzzy, tighten the bullet until it only claims the part you are sure of. What employers look for in a CS portfolio is largely evidence that you finish things, and a bullet you can defend for two minutes is worth more than a bigger one you cannot.

The bottom line

Yes, put the group project on your resume. List it under Projects, make one piece of it unambiguously yours in the bullet and in the commit history, and where you can, put it at a URL that belongs to you.

Build something that is unambiguously yours →

Try it free, no sign-up needed

Not sure what to build for a specific role? Paste a job description into Provieo's free Job Description Matcher and see example project directions for a posting, with no account. It draws on a fixed set of ideas, so treat it as a starting point.

Put a working link in your next application.

Paste the job you're applying to. Provieo designs a project against that exact listing and walks you through deploying it, so what a recruiter clicks is the work itself, not a description of it.

Free to use, and your first deployed project is free. Or tailor your resume to the same posting.