How would you handle a situation where one team member takes all the credit for a group project

How did you approach the conversation with your teammate?

Did you involve your manager or other stakeholders?

What specific steps did you take to clarify contributions?

How did you balance assertiveness with maintaining the relationship?

• Was the situation resolved? How?
• What was the impact on team dynamics and your working relationship?
• What did you learn about handling similar situations?
• How did this change your approach to documenting contributions?

Sample Answer (Junior / New Grad) Situation: During my internship on a data analytics team, I spent three weeks building a Python script that automated our weekly reporting process, reducing manual work from 4 hours to 15 minutes. In our team demo, my project partner presented the tool to leadership and repeatedly used "I" instead of "we," making it sound like he had built it alone. I felt frustrated because I had done the majority of the technical implementation while he had focused on gathering requirements.

Task: I needed to ensure my contribution was recognized without damaging the working relationship or coming across as petty. As an intern, I also wanted to demonstrate maturity in handling workplace conflicts. My goal was to have my work properly attributed while maintaining professionalism.

Action: I waited until after the meeting, then asked my partner for a quick one-on-one conversation. I calmly explained that I felt uncomfortable with how the presentation went and that I'd contributed significantly to the technical implementation. I used specific examples, like mentioning the data transformation logic and API integration I'd built. He seemed genuinely surprised and apologized, saying he hadn't realized how it came across. Together, we sent a follow-up email to our manager clarifying both of our roles, with him proposing the idea. I also started documenting my contributions more carefully in our project tracker going forward.

Result: My manager thanked us for the clarification and made sure to mention both our names when sharing the tool with the broader organization. My partner and I actually developed a better working relationship after that honest conversation, and he became more conscious about using inclusive language. I learned the importance of speaking up early and directly rather than letting resentment build. This experience taught me to document my work clearly and establish contribution expectations upfront in collaborative projects.

Sample Answer (Mid-Level) Situation: I was the technical lead on a critical customer migration project that would move 50+ enterprise clients to our new platform over six months. Our team of five engineers worked intensively on the migration tooling, with me architecting the solution and writing about 60% of the code while coordinating everyone's efforts. During our quarterly business review, one of the senior engineers on the project presented our progress to the VP and consistently described decisions and implementations using only his perspective, barely mentioning the team's contributions.

Task: As the technical lead, I was responsible for ensuring the team received appropriate recognition, especially since performance reviews were approaching. I needed to address this in a way that protected my team's interests without creating a hostile dynamic, since we still had three months of intense work ahead. My goal was to reset expectations around how we communicated about shared work.

Action: I scheduled a private conversation with the engineer the next day and approached it from a collaborative angle. I acknowledged his strong contributions but explained that the presentation made others feel their work was invisible, and that I felt my leadership role wasn't accurately represented. I provided specific examples, like how he'd said "I designed the architecture" when we'd actually workshopped it together with me creating the final proposal. He became defensive initially, but I stayed focused on future behavior rather than attacking his character. I then proactively scheduled a follow-up session with our VP where I presented a contribution matrix showing each team member's key accomplishments. I also established a new practice of rotating presentation responsibilities and having the team review slides together beforehand.

Result: The engineer acknowledged his mistake and made a point to highlight team contributions in subsequent meetings. Our VP appreciated the transparency and used our contribution matrix format as a template for other teams. The rest of the team felt heard and valued, which actually improved our velocity in the final project months. We delivered the migration two weeks early with a 98% success rate. I learned that addressing attribution issues quickly prevents them from poisoning team culture, and that creating systematic processes for recognition is better than relying on individual awareness.

Sample Answer (Senior) Situation: I was leading a cross-functional initiative to rebuild our payment processing system, involving eight engineers, two product managers, and multiple stakeholders across finance, compliance, and operations. Over four months, we reduced transaction failures by 85% and cut processing costs by $2M annually. However, during the executive presentation, the product director who had sponsored the project presented it as primarily his vision and strategy, minimizing both my technical leadership and the engineering team's extensive problem-solving work. Several of my engineers privately expressed frustration, and I noticed it was affecting morale on our next project.

Task: As the engineering lead, I needed to advocate for proper recognition of the technical team's contributions while maintaining a productive relationship with the product organization. Beyond just this incident, I recognized a systemic issue where engineering contributions were often undervalued in executive communications. My goal was to address both the immediate situation and establish better practices for how we communicated about collaborative success.

Action: I first had a direct conversation with the product director, framing it around our shared goal of team motivation rather than personal grievances. I explained that engineering felt their deep technical problem-solving was reduced to mere implementation, and shared specific examples of critical decisions they'd made that weren't in the original product vision. He was receptive but admitted he didn't fully understand all the technical challenges we'd overcome. I then worked with him to create a joint follow-up presentation for the engineering and product all-hands, where we alternated presenting and explicitly called out individual contributions. More strategically, I partnered with the VP of Engineering to establish a new practice requiring joint engineering-product presentations for major initiatives, with written contribution summaries reviewed by both leads. I also started a monthly engineering wins newsletter that I sent to executive leadership, making our technical achievements more visible.

Result: The follow-up presentation significantly improved team morale, with several engineers thanking me for advocating for them. The product director became a stronger partner, actively seeking to understand technical challenges and regularly highlighting engineering contributions in his updates. Our new joint presentation practice was adopted company-wide within two quarters, leading to noticeably better engineering-product relationships across teams. My leadership team recognized this work during my performance review, noting improved cross-functional collaboration scores. Most importantly, I retained all eight engineers through the next project cycle, which was critical given the tight talent market. This experience taught me that senior leaders must address systemic recognition gaps, not just individual incidents, and that creating structural changes has more lasting impact than one-off interventions.

Sample Answer (Staff+) Situation: I had architected and championed a company-wide initiative to modernize our service mesh infrastructure, working across 15 engineering teams over 18 months. This effort ultimately reduced our cloud costs by $12M annually and improved system reliability from 99.5% to 99.95%. The initiative required building consensus across resistant teams, creating migration tooling, and establishing new operational practices. During our annual engineering summit, the VP of Infrastructure presented this transformation to the company and board, positioning himself as the primary driver and barely mentioning the distributed team that had done the actual work. Multiple senior engineers reached out to me expressing concern that this pattern was damaging trust in leadership.

Task: As a staff engineer, I needed to address both the immediate attribution issue and a broader organizational problem where executive leadership was consistently taking credit for work driven by individual contributors and senior engineers. This wasn't just about recognition—it was affecting retention and people's willingness to take on ambitious, high-visibility work. My goal was to create systemic change in how we acknowledged contributions while maintaining my relationship with executive leadership and my ability to drive future initiatives.

Action:

Result:

Common Mistakes

• Being passive-aggressive -- Address the issue directly rather than making indirect comments or complaining to others first
• Making it personal -- Focus on behaviors and impact rather than attacking someone's character or intentions
• Waiting too long -- Address attribution issues promptly before resentment builds and the situation becomes harder to resolve
• Not documenting contributions -- Failing to show specific examples of your work makes it harder to make your case credibly
• Burning bridges -- Remember you may need to continue working with this person; seek resolution, not revenge
• Ignoring systemic issues -- If this is a pattern, address the underlying causes rather than just the individual incident
• Being too accommodating -- Not speaking up at all teaches others that taking credit is acceptable and damages your career progression

Result: The engineer acknowledged his mistake and made a point to highlight team contributions in subsequent meetings. Our VP appreciated the transparency and used our contribution matrix format as a template for other teams. The rest of the team felt heard and valued, which actually improved our velocity in the final project months. We delivered the migration two weeks early with a 98% success rate. I learned that addressing attribution issues quickly prevents them from poisoning team culture, and that creating systematic processes for recognition is better than relying on individual awareness.

Result: The follow-up presentation significantly improved team morale, with several engineers thanking me for advocating for them. The product director became a stronger partner, actively seeking to understand technical challenges and regularly highlighting engineering contributions in his updates. Our new joint presentation practice was adopted company-wide within two quarters, leading to noticeably better engineering-product relationships across teams. My leadership team recognized this work during my performance review, noting improved cross-functional collaboration scores. Most importantly, I retained all eight engineers through the next project cycle, which was critical given the tight talent market. This experience taught me that senior leaders must address systemic recognition gaps, not just individual incidents, and that creating structural changes has more lasting impact than one-off interventions.