How to Answer 'Tell Me About a Conflict with a Coworker' in a CS Interview

How do you answer "tell me about a conflict with a coworker" in an interview?

Pick a peer-to-peer disagreement where you had to keep working with the person after, not a one-time argument with a stranger. Describe what you both wanted, what you did to find a path forward, and how the working relationship held up afterward. The interviewer is grading whether they'd want to sit next to you during a hard sprint. Stories where you "win" or where the coworker is "the bad one" both fail the question.

A coworker-conflict question is a behavioral interview question, a "tell me about a time" prompt graded on the specifics of a real story rather than a single correct answer. As of the 2026 hiring cycle, most structured loops at companies like Google, Amazon, and Microsoft ask some version of it precisely because day-to-day friction between peers is unavoidable, and they want to see how you repair it. Here's the part most candidates miss, and it trips up every new grad I coach: the grader isn't keeping score of who was right. They're picturing a hard week six months from now and asking whether you're the person who makes it worse. The rest of this page covers how this question differs from the general one, how to pick the right story, the four-beat frame, and the follow-ups that expose weak answers.

Why this question is different from a general conflict question

A general "tell me about a conflict" question is about whether you can handle disagreement. A "conflict with a coworker" question is about whether you can handle ongoing disagreement, the kind where you can't just walk away because you still have to ship code with this person tomorrow. If you only have one conflict story ready, drill the broader version too. See how to handle the general "tell me about a conflict" question, because interviewers often ask whichever framing fits the role.

The two questions feel similar but grade different things:

| General conflict | Coworker conflict | |---|---| | Did you handle a disagreement well? | Can you hold a working relationship through a disagreement? | | Did you "resolve" the issue? | Did the day-to-day collaboration continue? | | One-time event | Ongoing relationship dynamics | | What was the outcome? | What was the outcome AND what happened in the next two weeks? |

If you answer the coworker version with a one-time-disagreement story, the interviewer will probe further. Be ready with the ongoing-relationship part of the answer.

According to HBR research on team dynamics, the strongest predictor of engineering team performance isn't average individual skill. It's the team's ability to repair relationships after disagreement. That's exactly what the interviewer is measuring.

Pick the right story

Three rules:

Rule 1, the conflict was about work, not personality. Pick a disagreement where you and the coworker had genuinely different views on a technical, scoping, or process question, not a story about someone being annoying or hard to work with. "Different priorities" is a strong frame. "They were difficult" is not.

Rule 2, you had to keep working together after. This is the key distinction. If the conflict ended with you switching teams or never working with the person again, it's a weaker story for this question. The interviewer wants to hear how you operated AFTER the disagreement, when you still needed each other to ship.

Rule 3, you did something specific to repair the working relationship. The interviewer is grading the repair work, not the original argument. If your story doesn't include a specific thing you did to re-establish collaboration (a coffee, a frank conversation, a process change), pick a different story.

Good story candidates for new grads:

• A school group project where you and a teammate disagreed on architecture and had to keep collaborating for another month.
• An internship where you and another intern (or you and a peer engineer) disagreed on a technical approach and had to keep code-reviewing each other.
• A hackathon team where mid-event tensions threatened the team's ability to finish.
• A research project where you and a co-author disagreed on direction.

A working structure

The scaffold underneath every beat below is STAR. The STAR method is the Situation, Task, Action, Result frame interviewers expect for any "tell me about a time" story. Four beats:

Beat 1, the setup (15-20 seconds). Who, what you were working on, and what each person wanted. Keep it tight.

Example: "On my internship team, I was working with another intern on a backend service. We had two weeks to ship a feature, and we disagreed about the data model. I wanted a normalized schema; they wanted a denormalized one optimized for read performance."

Beat 2, the disagreement (20-30 seconds). What happened when you both held your ground.

Example: "We had two design meetings where neither of us moved. The third meeting got tense. At one point we were talking past each other and the senior engineer noticed and called a break. After the break I realized we were arguing about different problems: I was solving for future schema flexibility; they were solving for the read latency we'd actually be measured on."

Beat 3, what you did to repair (45-60 seconds). This is the meat. Walk through the specific steps you took to get the collaboration working again.

Example: "I asked them to grab coffee, away from the team. I led with what I'd missed, that I'd been so focused on long-term flexibility that I hadn't taken their read-latency concern seriously. We sketched a third option together that gave us most of both: a partly-denormalized schema with materialized views for the hot-read path. Back in the design meeting we presented it as our joint proposal, not as one of us 'winning.' The senior engineer accepted it that day."

Beat 4, how the relationship held up (20-30 seconds). What happened in the days and weeks after the conflict. This is what separates the strong answer from the average one.

Example: "More importantly, we kept working closely for the rest of the summer. They became one of my primary code reviewers and I learned a lot from how they thought about performance. I think the willingness to admit I'd been narrow on the schema question made the rest of the relationship easier."

The full answer comes in around 90-120 seconds.

How to build your conflict answer: a four-step method

The four beats above are what you say in the room. This is the order of operations to build the answer beforehand, so it comes out in your own voice instead of as a recited script. It maps onto the STAR method (Situation, Task, Action, Result), the standard scaffold for behavioral answers.

1. Pick a peer story where the relationship continued. List two or three real disagreements, then cross out any where you stopped working with the person. The keeper is one where you still needed each other after; that's the only kind this question rewards.
2. Set up the disagreement without a villain. Write one sentence on what each of you wanted, framed as competing priorities ("I was solving for schema flexibility; they were solving for read latency"). If your sentence makes the coworker the problem, rewrite it.
3. Walk through the specific repair work. Repair work is the concrete thing you did to get collaboration working again: a one-on-one away from the team, owning what you'd missed, building a joint proposal. This is the beat the interviewer actually grades, so make it the longest.
4. Close on how the relationship held up. End on the next two weeks: who became a go-to collaborator, what you learned from them, how the working relationship was after. Self-awareness plus a continued relationship is the whole point.

Run this once and you have a reusable answer. The same build powers the "tell me about a failure" question and most behavioral prompts, which is why the 40+ questions in the behavioral master guide share this skeleton. If you want the framework underneath it, the STAR, SOAR, CAR, and PAR breakdown shows which scaffold fits which story.

What to avoid

The villain story. Any frame where the coworker is "difficult," "stubborn," or "wrong" reads badly. The interviewer hears "this person can't see other perspectives" and ranks you accordingly. Even if you privately think the coworker was wrong, the interview is not the venue.

The win story. "And then they realized I was right" is the wrong ending. The interviewer is not impressed by candidates who win arguments; they're impressed by candidates who maintain relationships. End with what changed, not who won.

The non-resolution story. "We never really got past it" is a real outcome, but it should come with reflection on what you'd do differently and what you learned. Don't leave the interviewer with a flat unresolved ending.

Naming names. Don't say "my coworker Jake" in an interview. Use roles: "a peer engineer," "another intern," "the senior engineer I was paired with." Specificity about names suggests you'll be indiscreet about future colleagues too.

Personality conflicts. "We just didn't get along" or "they were hard to work with" tells the interviewer you can't separate task from personality. Frame every conflict as about the work, not the person.

Hierarchy stories at this question. "A conflict with my manager" is a different question. If asked specifically about a coworker, pick a peer story.

Three example stories that work for new grads

Story 1, architectural disagreement in a group project. "In a senior design course we had a four-person team. Two of us wanted to ship a thin MVP with hard-coded data; the other two wanted to build the full database layer first. We were three weeks from the deadline. I led the MVP camp and another teammate led the database camp. We had a tense whiteboard session that didn't resolve, so I asked her to grab coffee. Once we were one-on-one we agreed the real disagreement was about risk tolerance: she was worried we'd ship something that didn't demo well; I was worried we'd run out of time. We agreed on a compromise: two days to scaffold a real database, then MVP behavior on top, with a flag to deepen the database layer if we had time. We shipped both. After the project she and I co-authored the writeup and stayed close through senior year."

Story 2, code-review conflict at an internship. "During my internship another intern kept rejecting my PRs over what felt like style nits. After the second one I was frustrated and almost responded sharply on the PR. Instead I waited an hour and DM'd him asking if he had 15 minutes. In the call I told him I was struggling to tell which feedback was 'blocking' and which was 'preference,' and asked if we could agree on a tag for each. He said the same thing was bugging him from the other direction: he didn't want to come across as nitpicky but felt obligated to point everything out. We agreed to label feedback 'nit,' 'suggestion,' or 'blocker.' Reviews went from contentious to collaborative within a week."

Story 3, hackathon conflict that didn't fully resolve. "On a 48-hour hackathon I was working with two friends and we hit a wall around hour 30. I'd written a piece of the frontend that wasn't talking to the backend correctly. One teammate wanted to rewrite my frontend; I wanted to debug. We argued for 20 minutes when we should have been coding. I eventually said 'let's just try my path for an hour; if it's not working we'll do yours,' and he agreed. It worked, but barely. The project shipped but the rest of the hackathon was tense. Looking back, I should have suggested the time-boxed compromise in minute two, not minute twenty. The friendship is fine but I learned that when team energy is low, fast compromise beats winning the architectural argument."

Story 3 is honest about an incomplete resolution. The interviewer respects that.

When the interviewer probes

Common follow-ups:

• "What would you do differently now?"
• "How did you and the coworker work together after?"
• "Did you ever have a similar conflict with the same person again?"
• "Did anyone else get involved?"

Have answers ready. The follow-ups are where weak stories collapse: if you fabricated the conflict or sanitized it too aggressively, the probes will expose it.

Per the r/cscareerquestions community wiki on behavioral interviews, the most common failure mode on coworker-conflict questions is candidates running out of material on follow-up. They have a polished 90-second story and nothing behind it. Pick a story you can talk about for 5 minutes if probed; deliver 90 seconds of it.

Practice saying it out loud before the real interview

This answer reads fine on paper and falls apart the first time you say it to a stranger, usually right when the interviewer probes the repair beat. The fix is reps: say the four beats aloud until they sound conversational, then have someone push back with "what would you do differently?" so the follow-ups don't catch you flat.

If you're a CS senior deep into a grind of applications and still chasing the offer that ends the search, the gap is rarely knowing the frame. It's walking in able to deliver it in your own voice when the nerves hit. Run a practice interview and hear a strong conflict answer in your own words first, then see how live coaching turns a rehearsed story into the offer that ends the search; it starts at a $3 trial.

Key terms

Coworker-conflict question

The behavioral prompt asking about a disagreement with a peer. It probes whether you can hold a working relationship through friction, not whether you won the argument.

Behavioral interview question

Any "tell me about a time..." prompt graded on a specific real story rather than a single correct answer. The coworker-conflict question is one of the most common.

STAR method

The Situation, Task, Action, Result scaffold for behavioral answers. Here the disagreement is the situation and task, the repair is the action, and how the relationship held up is the result.

Repair work

The concrete thing you did to restore collaboration after the disagreement: a one-on-one, owning what you missed, a joint proposal. This is the part of the answer the interviewer actually scores.

The villain story

Any framing where the coworker is "difficult," "stubborn," or "wrong." It signals you can't separate the disagreement from the relationship, and it sinks the answer even when you were objectively right.

About the author: Sam K. is the founder of InterviewChamp.AI and writes about the modern tech interview from the inside: what changed, what works for new grads, and where the old playbook fails.