INTERVIEW QUESTION
Tell me about a time you worked on a team: how to show your part
Say what you did and what others did in shared work, and show how you helped the team without taking anyone's work over.
Your best project story probably sounds something like this: “We rebuilt the onboarding flow, cut drop-off by a third and shipped a week early.” It's accurate, and it may be the right story to tell. Then the interviewer asks, “What was your part?”, and you realize the answer never said.
That follow-up is what this question is really asking. Everyone has worked on a team, so being on one proves nothing. A recruiter on Reddit puts the real question plainly: how do you work in a team, and can you? Booking the meetings and sharing the document don't answer it.
A strong answer does three things. It says what you did and what others did. It shows how you kept the work in step with theirs. And if a teammate struggled, it shows you helped without taking their work over.
What interviewers listen for
The first thing is your role. In a shared project the interviewer can't score “the team”, so they need to hear which decisions, pieces of work and conversations were yours. Everything else in the answer hangs off that.
Your role doesn't have to be the biggest one. Microsoft's interview tips describe collaboration as contributing to the team's work and building on other people's success. A supporting role you did well, and can describe precisely, answers that better than a lead role you can only describe in outline.
The second is how the work stayed connected. Joint work usually goes wrong where one person's work meets another's: an interface nobody agreed, a handoff that arrived late, a change one team didn't hear about.
Say what you did at those points, such as the contract you wrote, the check-in you set up, or the question you raised before it became a problem.
The third is how you talk about the people you worked with. Describe others' work fairly and specifically, even when it caused you problems.
These three points are easier to state than to say out loud, and the hardest is the first one.
How to tell it
The usual order works: the situation, what you did, and the result. What makes or breaks a teamwork answer is whether each action has an owner.
“The mobile team built the screens. I owned the API they called, and I wrote the contract with their lead before either of us started.” Others' work is named, yours is clear, and the result can still belong to the team.
Name people by their role, such as “our designer” or “the finance analyst”, so the interviewer can follow who did what without a cast list. Then spend most of your time on the points where your work met theirs.
Naming others' work accurately also means not inflating your own part. If you recommended something and your manager decided it, say so. Interviewers often follow up on exactly that sentence, and a small honest role holds up better than a large vague one.
A quick test is to say the answer out loud and listen for each “we” attached to an action. If you practice in Kora, you pick your role, answer out loud, and get a follow-up when your answer leaves out what your part was. The examples below show what a clear part sounds like in six roles.
Example answers
In each made-up stronger answer, you can point to the sentence that says what the candidate did and the sentence that says what someone else did. Check whether your own answer has both.
Software engineer
Question: “Tell me about a time you helped a colleague get better at their work.”
Weaker
“A new engineer on my team was really struggling and kept missing deadlines on his tickets. The sprint was at risk, so I just took over his biggest ticket and finished it over the weekend. We hit the release, and the team was really grateful.”
Finishing the work fixed the sprint but didn't help the colleague, and nobody agreed to the handover. The interviewer can't tell whether the teammate learned anything or felt sidelined.
Stronger
“A new engineer joined our payments team and his first two pull requests sat in review for over a week. Each round came back with a long list of comments, mostly about our retry and error-handling conventions, which weren't written down anywhere.
I asked him what was slowing him down, and he said he couldn't tell which comments were rules and which were preferences. So I offered to pair with him for an hour on his next change, with him driving.
Afterwards I wrote up the five conventions we'd hit, and our tech lead added them to the review checklist. I also told the lead I'd take the first review on his next few changes, so the feedback came from one person in one batch.
His third pull request went through in two days, and a month later he was reviewing other people's error handling.”
The candidate asked before helping, kept the teammate in charge of his own work, and agreed the review role with the lead. The result is the colleague's progress, not the candidate's heroics.
Follow-ups to expect: What did your colleague need to improve? What did you do to help them improve?
Product manager
Question: “Tell me about a feature you shipped with engineering and design. What was your role?”
Weaker
“We launched saved searches last year. We did a lot of user research, we went through several rounds of design, and we shipped it in one quarter. Adoption was really strong, and it was a great team effort.”
Every action belongs to “we”, so the interviewer can't tell whether the candidate set the goal, made the trade-offs or simply attended the meetings.
Stronger
“I was the product manager for saved searches on our job board. Our designer ran the interviews and owned the flows. Two engineers built it, and the tech lead chose to reuse our existing alerts service.
My part was the scope and the trade-offs. Halfway through, engineering found that instant alerts would add three weeks. I took the question to five of the customers we'd interviewed, and most only checked daily.
So I proposed a daily digest for launch. The designer reworked the email in two days, and I wrote up why we'd cut instant alerts so sales could answer customers who asked.
We launched on time. About a fifth of active job seekers saved a search in the first month, and instant alerts went on the roadmap for the following quarter.”
Each person's part is named before the candidate's own, and the candidate's role is a specific decision with the evidence behind it.
Follow-ups to expect: What was your own role in that work? How did everyone involved keep their work in step?
Product designer
Question: “Tell me about a time an engineer said your design could not be built.”
Weaker
“I designed inline editing for our orders table, so people could change any cell directly. The engineers said it couldn't be built with our table component. I explained that users really needed it, and in the end they built a custom version, although it took a lot longer than planned.”
The engineers' reason never appears, and the candidate wins by insisting. The extra time is presented as the engineers' problem rather than a cost the candidate chose.
Stronger
“I designed inline editing for our orders table, so support agents could change any cell without opening the order. Our front-end lead said the table only renders the rows on screen, and editing cells inside it would break scrolling and lose people's changes.
I asked her what would be cheap to build instead. She said anything opened outside the table, such as a panel for one row, would work with the component as it was.
So I checked our session recordings. Agents almost always changed one field on one order, usually the delivery address. I redesigned it as an edit drawer that opens from the row, with the address at the top.
She built it in a sprint. Edits took agents about half as long, and I now bring rough flows to the front-end lead before I start detailed designs.”
The engineer's constraint is stated fairly, the candidate asks what is feasible instead of defending the original, and the user evidence decides the redesign.
Follow-ups to expect: How did you find out what made the design hard to build? Which part of the design did you keep because it mattered most to users?
Data analyst
Question: “Tell me about an analysis you delivered with other teams. What was your role?”
Weaker
“I worked with finance and data engineering on a churn analysis. I pulled all the data, built the model and made the dashboard. Finance loved it and now uses it every month.”
This is too much “I”. The other teams appear only as the audience, so the interviewer can't tell what they contributed or how the work fitted together.
Stronger
“Finance asked why revenue churn was higher than the customer churn we reported. My job was the analysis. Data engineering owned the billing tables, and a finance analyst knew which contract changes counted as churn for their reports.
The first week, my numbers didn't match theirs. I set up a half-hour call with both of them and we went through ten accounts line by line. Downgrades were the gap: finance counted them, and our definition didn't.
Data engineering added a downgrade flag to the billing table, which only they could do safely. I rebuilt the analysis on it, and the finance analyst checked my totals against their quarter-end report before anything went out.
Downgrades turned out to be about 40% of revenue churn, which moved the retention team's focus to pricing tiers. The definition we agreed is now written into our metrics docs.”
Each team's part is named, the candidate's role is clear, and the call that resolved the mismatch shows how the work was kept in step.
Follow-ups to expect: What did the other people or teams contribute? How did everyone involved keep their work in step?
Program manager
Question: “Tell me about a program you delivered with several teams. What was your role?”
Weaker
“I managed the single sign-on launch for enterprise customers. I ran weekly status meetings, tracked all the risks in a spreadsheet, and kept leadership updated. It launched on time and customers were happy.”
These are the routine tasks of any program. The answer doesn't name the teams, what each one did, or a moment where the candidate's work changed what happened.
Stronger
“I ran the single sign-on launch for our enterprise customers. The identity team built the integration, support wrote the setup guides, and sales ops chose the first ten customers.
I didn't build anything. My part was the plan and the joins between teams. Three weeks out, I noticed that support's guides were based on a screen identity had since changed, and neither team had flagged it.
I got the identity lead and the support writer on a call that afternoon. We agreed that identity would post every screen change in a shared channel, and that I'd check the guides against the build each Friday.
We launched with the first ten customers on the planned date. Support had two setup tickets in the first month, and the Friday check is now part of how we run launches.”
The candidate says what they didn't do as well as what they did, and the story turns on a join between two teams, which is where a program manager adds the most.
Follow-ups to expect: What was your own role in that work? What did the other people or teams contribute?
Consultant
Question: “Tell me about a time you worked with people very different from you in background or working style.”
Weaker
“On one project I worked with a client manager who was very old-school and didn't like slides. It was frustrating, but I stayed professional and adapted to his style, and we got along fine in the end.”
“Old-school” is a label, not a description, and “adapted to his style” doesn't say what the candidate changed. It also edges toward complaining about the client.
Stronger
“On a cost project for a manufacturer, I worked day to day with the plant's maintenance manager. He'd run maintenance there for twenty years and made decisions on the floor, not in documents. My instinct was to send a slide pack before each weekly meeting.
After two weeks he hadn't opened any of them, and our meetings were going in circles. I asked him how he'd prefer to work, and he suggested we walk the floor together on Tuesday mornings.
So I brought one printed page with three numbers and the question we needed answered, and we discussed it standing next to the problem. He pointed out that two of our proposed changes would put repairs in the middle of shift changes, when the line was busiest.
We dropped those two changes and kept four. His team adopted the new maintenance schedule in the first month, and I've used the one-page format with operations clients since.”
The difference is described respectfully and specifically, the candidate changes how they work instead of asking the client to change, and the client's knowledge improves the result.
Follow-ups to expect: What particular problem did that difference cause in the work? What did you change in your own approach to work with them?
Helping a teammate without taking over
Many teamwork questions are really about a teammate who was struggling: someone new, overloaded or stuck. Interviewers expect you to help, even when it's outside your own work. Amazon writes this into its Ownership principle: owners act for the whole company, beyond their own team.
Helping doesn't mean quietly rewriting their work. The strongest answers show that you checked first. Ask the teammate what would help, or agree with the lead or project manager which piece you'll take on. A reply on r/recruitinghell frames it as respecting how the team and its stakeholders already work.
That balance is what interviewers hope to hire. An engineering interviewer describes looking for a team player who is helpful and a bit proactive without needing to be micromanaged.
Two related questions turn the same situation around, and need the same specifics. If you were the one who was stuck, say where you were stuck, what you'd already tried, and exactly what you asked for. Asking early, with a specific question, is a teamwork skill in itself.
If you raised a concern about a colleague's work, say what the concern was and how you raised it with them first, privately and with specifics. Keep it about the work, not the person.
Students and early-career candidates often reach for a group project where one partner didn't contribute. It can work, but it's a well-worn story. If you use it, describe coaching or encouraging the partner rather than “convincing” them, and give it a real outcome.
Not every teammate is struggling, though. Some simply work differently from you.
Working with people who work differently from you
Some teamwork questions ask about people very different from you in background or working style. They test whether you adjusted, not whether you tolerated them. One reply on Reddit gives a concrete example: switching to short bullet-point emails for a colleague who struggles with long paragraphs.
The stronger answers also show you know your own way is a style, not the right way. Name what you changed, and what you learned from the other person's approach. If their way turned out better for the work, say so; it shows the self-awareness these questions are probing.
If the story is really about a dispute with a difficult team member, it's a conflict question rather than a teamwork one. Tell me about a time you had a conflict covers how to show the other person's view fairly and how you worked it out.
What makes the answer go wrong
Most weak teamwork answers blur who did what, or how you treated the people involved. These are the common versions:
- Too much “we”. It hides you: the interviewer can't tell whether you led the work or watched it. Behavioral interview mistakes that hide your best work covers this in more detail.
- Too much “I”. It sounds as if you did the team's job alone. A candidate who interviewed at Meta said afterward that their answer focused too much on their own work and not enough on how they worked with others.
- “That isn't my job.” A senior engineer who gave a careful, scope-guarding answer about a struggling teammate was rejected. The Reddit thread about it drew hundreds of upvotes for one blunt reply: you help your struggling teammate as best you can.
- Badmouthing a coworker. A hiring manager lists it among the red flags in interviews.
Other ways it gets asked
The question comes in several wordings, and the same story usually works with a change in emphasis. Each still needs a real example, even when it's phrased as a hypothetical.
“Are you a team player?” or “What role do you usually play on a team?” Don't answer with adjectives. Give one short story that shows the role, then say whether it's typical for you.
“How do you work with engineers and designers?” Common for product managers and designers. Describe one project from idea to launch, and say where your work handed over to theirs and how you handled the disagreements along the way.
“How do you help shape technical decisions when you aren't the one building?” Common for program managers. Your part is the questions you asked, the trade-offs you made visible and the decisions you got recorded, not the technical answer itself.
“Tell me about a time you helped a colleague get better at their work.” For engineers this often means code review, pairing or mentoring. Say what the colleague needed to improve and how you helped, and let the result be their progress rather than yours.
“Tell me about a time you worked with other teams.” This is the core question in a different wording, and the program manager and data analyst examples above answer it.
Teamwork questions ask about your part in shared work. When the question is about getting people who don't report to you to change course or commit their time, it has become a leadership question. The leadership guide covers that, and the STAR method examples show how to put either kind of answer in order.