Skip to content
GuideEducation3 min read

Group projects: talking about your part in interviews

Final-year projects are team work. How to describe your own part clearly, credit others fairly and handle questions on parts you did not build.

Start reading
Two adults use a practical guide, checklist cards and a recorded workshop to support their learning

Conceptual image · created with AI

Explore this page3 sections

Overview

Most final-year and mini projects are done in teams of three or four. The interviewer knows this, and one of their first questions will be some version of 'what did you do?'

Students tend to answer too vaguely ('we built it together') or claim too much. This guide is about the middle path: specific, fair and easy to check.

At a glance

Key takeaways

  • Name your part in one specific sentence
  • Say who did the other parts by role, not by criticism
  • Know the whole project well enough to explain how your part fits
  • Admit when a question is about a part you did not build
  • Mention the team problems you helped solve, not the ones you complained about
  • Make sure every teammate's resume can tell the same story

Read the article

Start by naming your part in one sentence that someone could check. 'I designed the database and wrote the booking logic. Two teammates built the mobile screens and one handled testing and the report.' That is better than 'I was involved in all parts', which interviewers hear as 'I am not sure what I did'. It is also better than 'I built most of it', which invites a test.

If the work was genuinely shared, describe how. 'We paired on the backend for the first month, then I took over the payment part.' Shared work is normal. What matters is that you can say where your hands were.

Know the whole project anyway. Interviewers often ask about how the parts connect: how the screens call your code, what happens when the network fails, how the data gets from one place to another. You do not need to know every line of your teammates' work, but you should be able to explain the whole thing at the level of a diagram. If you cannot, sit with a teammate for an hour before your interviews and ask them to walk you through their part.

When a question lands on a part you did not build, say so and still be useful. 'That was my teammate's part, so I can tell you what it does but not every detail of how. As I understand it, it works like this.' Interviewers respect this. Guessing confidently about someone else's code and getting it wrong is far worse.

Talk about the team as well as the work, because many interviewers will ask. Choose something you did that helped the group: splitting tasks when the deadline moved, setting up a shared folder that ended the version confusion, or taking over a part when someone fell ill. Avoid stories that mainly show a teammate in a bad light. Even if they are true, the interviewer is imagining you on their team.

One practical step: agree as a team how each of you will describe the project. If four students from one project interview with the same company and each claims the same module, it is noticed. A ten-minute conversation before placement season, in which each person says 'this is what I will say I did', avoids that, and it usually makes every answer clearer.

TopicsCommunicationInterviews

Come to the session it came from

Reading it is useful. Being in the room and asking your own question is better.