What do interviewers evaluate in Conflict questions?

Interviewers listen for signals like: Did you actually understand the other person's position, or just label it? Did you make your own reasoning explicit, or assume it was obvious? Did you separate the technical disagreement from the personal one?

gitGood.dev

GeneralAdvanced Premium

Conflict with a Coworker

The most universal behavioral question. Tested everywhere. The signal is in how you investigate the disagreement, not in how you 'won.'

About this theme

Conflict-with-a-coworker is the most universally tested behavioral prompt. Every interview loop at every level asks some version of it. The reason: real engineering work has friction, and how you handle that friction determines your effective leverage. The signal interviewers want is not "I won the argument." It's: did you investigate the other person's reasoning before disagreeing? Did you make your own reasoning explicit? Did you negotiate a path that respected both perspectives, or did you escalate prematurely? Did you maintain the working relationship after, or did you burn it? Common pitfalls: telling stories where the other person was clearly wrong (interviewers don't believe you - and even if true, it's a low-signal story), framing the conflict as won/lost (real conflicts end in synthesis, not victory), or staying surface-level on the actual disagreement.

What interviewers are evaluating

→Did you actually understand the other person's position, or just label it?
→Did you make your own reasoning explicit, or assume it was obvious?
→Did you separate the technical disagreement from the personal one?
→Did you escalate when escalation was the right move, and did you avoid it when it wasn't?
→Did the working relationship improve or degrade after the conflict?
→Did you change your mind on anything, or did you 'win'?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a conflict you had with a coworker. How did you resolve it?
?Describe a situation where you had to work with someone difficult.
?Tell me about a time you disagreed with a peer's technical approach. What happened?
?Walk me through a time you had to give difficult feedback to a colleague.
?Describe a project where two teams had competing priorities. How did you navigate it?
?Tell me about a time you had to escalate a peer disagreement.
?Describe a time you were wrong in a conflict. How did you handle it?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: Investigated before disagreeing

Prompt: "Tell me about a conflict you had with a coworker. How did you resolve it?"

Situation: About a year ago, I was a senior engineer on a backend team. A staff engineer on a partner team (let's call her J) and I disagreed about how to integrate our two services. I wanted a synchronous REST API; she wanted us to publish events to her team's Kafka topic. We'd been going back and forth in design review for two weeks and weren't converging.
Task: The deadline was approaching, and our managers had started saying 'just pick one.' I felt my approach was right but realized I was being defensive rather than open. I decided to actually investigate her reasoning.
Action: I asked her for 30 minutes outside design review. I started by saying 'I want to understand why you prefer the event-driven approach. I'll listen first.' She walked me through three things I had not fully internalized: (1) Their team had recently been bitten by a synchronous coupling that took down both services during a downstream incident. (2) Their team's on-call burden was already high and synchronous coupling adds debug complexity for them, not just for us. (3) Their service was scaling 3x faster than ours and synchronous calls would force them to scale up faster than they'd like. I left thinking she was 70% right. I came back a day later and said 'I'm going to argue your side now and tell me where I'm wrong.' She corrected one technical detail (event ordering wasn't quite as I'd characterized it). I then said: 'I'd like to go with the event-driven approach. I had two real concerns - (a) failure visibility, (b) team learning curve - and I'd like to scope solutions to both before we commit.' She agreed. We co-designed the failure-visibility piece (DLQ + alerting on failed-to-process events with our team's contact). I led an internal session to bring my team up to speed on Kafka.
Result: Integration shipped 1 week behind original schedule but with a much cleaner architecture. Zero coupling-related incidents in the next 12 months. J and I co-led two more cross-team integrations after that and the working relationship was visibly better - we'd built explicit trust through the disagreement. I learned to recognize when I'm being defensive vs being persuaded; that pattern recognition has saved me weeks of unproductive arguing in subsequent disagreements.

Why this works

What makes this strong: (1) The candidate's initial position was wrong, and they tell that story honestly. Interviewers love hearing 'I was 70% wrong' more than 'I was right.' (2) Specific investigation - asked questions, listened, came back, even argued the other side. (3) Solved real residual concerns (failure visibility) rather than capitulating fully. (4) Working relationship improved. (5) Reflection on a transferable lesson (recognizing defensiveness in oneself). (6) Quantitative outcome (zero coupling incidents) tied to the architectural choice.

STRONG

Strong: Difficult feedback

Prompt: "Tell me about a time you had to give difficult feedback to a colleague."

Situation: On a previous team, I was the senior engineer working with a mid-level engineer (let's call him A) who'd joined six months earlier. He was technically strong but had a habit of taking on too many tasks and missing deadlines, then working overnight to catch up. The team was beginning to discount his estimates because they were unreliable.
Task: His manager had given general feedback ('improve your time management') but A wasn't visibly changing. I'd built a working relationship with him and felt I was the right person to give specific feedback. I had no formal authority over him.
Action: I asked for a 1:1 over coffee. I framed the conversation explicitly upfront: 'I want to share specific feedback that I think will help you. Some of it will be uncomfortable. Are you open to that right now, or should we do it another time?' He said go. I gave him three specific examples from the prior month - the project he committed to in 2 weeks that took 4, the bug fix he said he'd land on Friday that landed Wednesday, the design doc he said he'd review in 2 days that took 5. For each, I described the impact: another engineer was blocked, the team had to replan, my own work depended on his estimate. Then I named the pattern: 'You take on more than you can deliver, then catch up by overworking. The team is starting to plan around your estimates being optimistic. I think this is hurting you more than helping - you're working overtime and getting weaker reviews.' He pushed back at first ('I delivered everything') and I said 'Yes, eventually - the issue is the gap between commitment and delivery, not whether you delivered.' We then talked about what was actually happening. He said he didn't know how to push back on requests. I shared my own approach: when someone asks me to take something on, I respond with what I'd have to deprioritize, and let them decide. We role-played that conversation for one of his current commitments. I followed up two weeks later with a check-in.
Result: His estimates got measurably more accurate over the next quarter. He explicitly thanked me 6 months later. He was promoted the following review cycle. I learned that direct feedback delivered with care lands better than indirect 'have you considered' framing. I also learned to ask permission upfront ('are you open to feedback right now') - that's the single highest-leverage pattern in giving difficult feedback.

Why this works

What makes this strong: (1) Specific feedback with examples and impact, not generic. (2) The candidate had no formal authority - this is peer-to-peer feedback, the harder kind. (3) Investigation of the underlying cause (he didn't know how to push back). (4) Practical help (role-played the conversation), not just diagnosis. (5) Follow-through with a check-in. (6) Captured the lesson at the technique level (asking permission). The story shows the candidate can navigate hard interpersonal moments without becoming the bad guy.

WEAK

Weak: 'I won the argument'

Prompt: "Tell me about a conflict you had with a coworker."

Situation: I had a coworker who disagreed with my technical approach on a project.
Task: I had to convince them I was right.
Action: I explained my reasoning and showed them the data. They eventually agreed and we went with my approach.
Result: The project was successful and we shipped on time.

Why this is weak

Why this is weak: (1) Frames the conflict as won/lost rather than synthesized. (2) No real investigation of the other person's reasoning - the candidate just 'explained.' (3) The other person 'eventually agreed' is suspicious; real strong stories include the candidate updating their own view. (4) No reflection on what they learned. (5) No mention of how the relationship continued. Bar Raisers and senior interviewers are specifically trained to spot this pattern - it suggests the candidate experiences disagreement as a fight to be won.

Common pitfalls

×Stories where the other person was clearly unreasonable. Interviewers don't believe these stories.
×Win/lose framing. Real conflicts end in synthesis. If your story has a clear winner (you), the interviewer will downgrade.
×Skipping the part where you investigated the other person's reasoning. 'I disagreed and explained why I was right' is the most common weak pattern.
×Stories where you escalated immediately. Escalation has a place, but premature escalation is a red flag.
×Generic resolution. 'We talked it through and agreed' without specifics signals you don't remember (or didn't pay attention).
×Skipping the relationship outcome. Strong stories include what happened to the working relationship after.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'what would you do differently?' - have a real answer that's about the conflict, not 'I'd do it the same.' Real reflection finds something.
→If asked 'what did you learn?' - the strongest answers name a specific technique or pattern you now use.
→If asked 'how did the relationship continue?' - have an answer. If the relationship deteriorated, own that and explain how you'd handle it differently.
→If asked 'when do you escalate?' - have a heuristic. 'When the disagreement is about values, not facts' or 'when timeline pressure is forcing a forced choice' are reasonable answers.
→If asked 'what if you were wrong in this conflict?' - your story should already include moments of being wrong. If not, acknowledge what you might have missed.

Related behavioral themes

Googleyness

Google

Not a soft round. Structured questions about collaboration, ambiguity, learning, and motivation - scored against rubrics, not vibes.

FREE

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Learning from Failure

Microsoft

Microsoft's Growth Mindset core. Also tested at Google, Anthropic, and any company that screens for self-awareness. The signal is whether you actually changed.

Companies that test this theme

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

GeneralAdvanced Premium

Conflict with a Coworker

The most universal behavioral question. Tested everywhere. The signal is in how you investigate the disagreement, not in how you 'won.'

About this theme

What interviewers are evaluating

→Did you actually understand the other person's position, or just label it?
→Did you make your own reasoning explicit, or assume it was obvious?
→Did you separate the technical disagreement from the personal one?
→Did you escalate when escalation was the right move, and did you avoid it when it wasn't?
→Did the working relationship improve or degrade after the conflict?
→Did you change your mind on anything, or did you 'win'?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a conflict you had with a coworker. How did you resolve it?
?Describe a situation where you had to work with someone difficult.
?Tell me about a time you disagreed with a peer's technical approach. What happened?
?Walk me through a time you had to give difficult feedback to a colleague.
?Describe a project where two teams had competing priorities. How did you navigate it?
?Tell me about a time you had to escalate a peer disagreement.
?Describe a time you were wrong in a conflict. How did you handle it?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: Investigated before disagreeing

Prompt: "Tell me about a conflict you had with a coworker. How did you resolve it?"

Situation: About a year ago, I was a senior engineer on a backend team. A staff engineer on a partner team (let's call her J) and I disagreed about how to integrate our two services. I wanted a synchronous REST API; she wanted us to publish events to her team's Kafka topic. We'd been going back and forth in design review for two weeks and weren't converging.
Task: The deadline was approaching, and our managers had started saying 'just pick one.' I felt my approach was right but realized I was being defensive rather than open. I decided to actually investigate her reasoning.
Action: I asked her for 30 minutes outside design review. I started by saying 'I want to understand why you prefer the event-driven approach. I'll listen first.' She walked me through three things I had not fully internalized: (1) Their team had recently been bitten by a synchronous coupling that took down both services during a downstream incident. (2) Their team's on-call burden was already high and synchronous coupling adds debug complexity for them, not just for us. (3) Their service was scaling 3x faster than ours and synchronous calls would force them to scale up faster than they'd like. I left thinking she was 70% right. I came back a day later and said 'I'm going to argue your side now and tell me where I'm wrong.' She corrected one technical detail (event ordering wasn't quite as I'd characterized it). I then said: 'I'd like to go with the event-driven approach. I had two real concerns - (a) failure visibility, (b) team learning curve - and I'd like to scope solutions to both before we commit.' She agreed. We co-designed the failure-visibility piece (DLQ + alerting on failed-to-process events with our team's contact). I led an internal session to bring my team up to speed on Kafka.
Result: Integration shipped 1 week behind original schedule but with a much cleaner architecture. Zero coupling-related incidents in the next 12 months. J and I co-led two more cross-team integrations after that and the working relationship was visibly better - we'd built explicit trust through the disagreement. I learned to recognize when I'm being defensive vs being persuaded; that pattern recognition has saved me weeks of unproductive arguing in subsequent disagreements.

Why this works

STRONG

Strong: Difficult feedback

Prompt: "Tell me about a time you had to give difficult feedback to a colleague."

Situation: On a previous team, I was the senior engineer working with a mid-level engineer (let's call him A) who'd joined six months earlier. He was technically strong but had a habit of taking on too many tasks and missing deadlines, then working overnight to catch up. The team was beginning to discount his estimates because they were unreliable.
Task: His manager had given general feedback ('improve your time management') but A wasn't visibly changing. I'd built a working relationship with him and felt I was the right person to give specific feedback. I had no formal authority over him.
Action: I asked for a 1:1 over coffee. I framed the conversation explicitly upfront: 'I want to share specific feedback that I think will help you. Some of it will be uncomfortable. Are you open to that right now, or should we do it another time?' He said go. I gave him three specific examples from the prior month - the project he committed to in 2 weeks that took 4, the bug fix he said he'd land on Friday that landed Wednesday, the design doc he said he'd review in 2 days that took 5. For each, I described the impact: another engineer was blocked, the team had to replan, my own work depended on his estimate. Then I named the pattern: 'You take on more than you can deliver, then catch up by overworking. The team is starting to plan around your estimates being optimistic. I think this is hurting you more than helping - you're working overtime and getting weaker reviews.' He pushed back at first ('I delivered everything') and I said 'Yes, eventually - the issue is the gap between commitment and delivery, not whether you delivered.' We then talked about what was actually happening. He said he didn't know how to push back on requests. I shared my own approach: when someone asks me to take something on, I respond with what I'd have to deprioritize, and let them decide. We role-played that conversation for one of his current commitments. I followed up two weeks later with a check-in.
Result: His estimates got measurably more accurate over the next quarter. He explicitly thanked me 6 months later. He was promoted the following review cycle. I learned that direct feedback delivered with care lands better than indirect 'have you considered' framing. I also learned to ask permission upfront ('are you open to feedback right now') - that's the single highest-leverage pattern in giving difficult feedback.

Why this works

WEAK

Weak: 'I won the argument'

Prompt: "Tell me about a conflict you had with a coworker."

Situation: I had a coworker who disagreed with my technical approach on a project.
Task: I had to convince them I was right.
Action: I explained my reasoning and showed them the data. They eventually agreed and we went with my approach.
Result: The project was successful and we shipped on time.

Why this is weak

Common pitfalls

×Stories where the other person was clearly unreasonable. Interviewers don't believe these stories.
×Win/lose framing. Real conflicts end in synthesis. If your story has a clear winner (you), the interviewer will downgrade.
×Skipping the part where you investigated the other person's reasoning. 'I disagreed and explained why I was right' is the most common weak pattern.
×Stories where you escalated immediately. Escalation has a place, but premature escalation is a red flag.
×Generic resolution. 'We talked it through and agreed' without specifics signals you don't remember (or didn't pay attention).
×Skipping the relationship outcome. Strong stories include what happened to the working relationship after.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'what would you do differently?' - have a real answer that's about the conflict, not 'I'd do it the same.' Real reflection finds something.
→If asked 'what did you learn?' - the strongest answers name a specific technique or pattern you now use.
→If asked 'how did the relationship continue?' - have an answer. If the relationship deteriorated, own that and explain how you'd handle it differently.
→If asked 'when do you escalate?' - have a heuristic. 'When the disagreement is about values, not facts' or 'when timeline pressure is forcing a forced choice' are reasonable answers.
→If asked 'what if you were wrong in this conflict?' - your story should already include moments of being wrong. If not, acknowledge what you might have missed.

Related behavioral themes

Googleyness

Google

Not a soft round. Structured questions about collaboration, ambiguity, learning, and motivation - scored against rubrics, not vibes.

FREE

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Learning from Failure

Microsoft

Microsoft's Growth Mindset core. Also tested at Google, Anthropic, and any company that screens for self-awareness. The signal is whether you actually changed.

Companies that test this theme

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →