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.

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.

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

Four-beat structure:

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.

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.

About the author: Alex Chen 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.