Why This Competency Matters

When interviewers ask 'tell me about a difficult coworker' or 'describe an unresponsive teammate', they are not asking you to identify problem people. They are probing four signals at once:

[ Self-awareness ]    Did you see your own role in the dynamic?
[ Empathy ]           Did you stay curious about why the person worked the way they did?
[ Adaptability ]      Did you actually change something, or just complain?
[ Trust ]             Did you describe a person without making them sound terrible?

This competency is uniquely sensitive in interview answers because there is a real person behind every story, and the way you describe them tells the interviewer almost as much as the resolution itself does. Engineers who casually label coworkers as 'lazy', 'toxic', 'incompetent', or 'difficult' are signalling something about themselves: that they default to character explanations for behaviour, that they are likely to bring those framings into the next team they join, and that their stories about future coworkers will sound the same. A strong answer here is one of the highest-signal moments in any behavioral round.

The single most important thing to internalise: the goal of a difficult-people story is not to convince the interviewer that the other person was actually difficult. The goal is to show that you handled a hard working relationship in a way that was fair to the other person, productive for the work, and showed evolution rather than avoidance. An interviewer who hears 'they were impossible to work with, but I survived' reads that as low empathy and a future risk. An interviewer who hears 'their style was different from mine in specific ways, here is what I tried, here is what worked' reads that as the rare and graded skill.

The Framing Rule: Behaviours, Not Labels

This is the rule that protects every answer in this competency:

[ Behaviour ]   What the person did, when, how often, and what it cost
[ Label ]       A character word for what kind of person they are

Behavioural framing: 'Their typical response time on async messages was about three days, which slowed our shared workstreams by roughly the same amount.' Specific. Falsifiable. Fair.

Label framing: 'They were unresponsive and lazy.' Imprecise. Unfair. Tells the interviewer about you, not them.

Every sentence in a difficult-people story should pass the behaviour-vs-label test. If you cannot say what the person did in observable, behavioural terms, you do not have enough information to be fair to them in the answer. If you can, the story will sound careful and senior even when describing genuinely hard situations.

A practical test: read your draft and circle every adjective applied to the other person. 'Slow' is borderline (what was the timescale?). 'Lazy', 'toxic', 'difficult', 'incompetent', 'arrogant' are all labels and should be replaced with descriptions of behaviour. After the rewrite, your story will be more accurate, fairer, and score higher.

Patterns That Show Up (Without Stereotyping)

There are recognisable patterns of working-style friction. Recognising them helps you describe what you actually experienced; it does not give you license to label the people who fit them. The five most common, with how to describe each behaviourally:

1. The slow responder. Person who takes substantially longer than the team norm to respond to async messages or PRs.

Behavioural framing: 'Their average response time on async messages was about three days; the team norm was about four hours.'

Label to avoid: 'Unresponsive', 'lazy', 'checked out'.

2. The status-game player. Person who frames their contributions in ways that maximise visible credit, often at the expense of clear work attribution.

Behavioural framing: 'In design reviews, they consistently introduced their contributions as if they had originated work that had actually started in someone else's draft.'

Label to avoid: 'Credit-hog', 'political', 'manipulative'.

3. The scope-creeper. Person who systematically expands the boundaries of agreed-on work.

Behavioural framing: 'Three out of five projects we had collaborated on had ended up about 40% larger than originally scoped, mostly through additions they had introduced after kickoff.'

Label to avoid: 'Out of control', 'feature-happy', 'bad at saying no'.

4. The dismissive senior. Senior person who treats junior input as automatically lower-value.

Behavioural framing: 'In the three design reviews I had attended where they were the senior reviewer, they had asked follow-up questions of the staff engineers but had moved past my comments without engaging.'

Label to avoid: 'Arrogant', 'dismissive of juniors', 'gatekeeping'.

5. The chronic cynic. Person whose default response to new ideas is criticism, often before the idea has been fully proposed.

Behavioural framing: 'In the last six new-project kickoffs, their first comment had been a concern about why the project would not work, before any of the framing had been laid out.'

Label to avoid: 'Negative', 'difficult', 'wet blanket'.

In each case, the behavioural framing is more useful for the candidate (it actually points at something to address) and fairer to the other person (it does not assume intent). The patterns are not boxes you put people into; they are descriptions of behaviour that may or may not be characteristic of someone in a specific period.

The Self-Awareness Step

The single biggest determinant of how a difficult-people story scores is whether the candidate describes their own role in the dynamic. The framing that scores well: 'this is what I observed, this is what I think contributed from my side, this is what I tried'. The framing that scores poorly: 'this is what they did, and I dealt with it'.

Four questions to ask yourself before drafting any difficult-people story:

1. What was I doing that may have made the dynamic worse?

Maybe you were sending async messages at a frequency that had its own cost. Maybe you were asking for credit in a way that triggered the credit-game pattern. Maybe you were proposing scope additions yourself and noticing them more in the other person. Self-awareness almost always finds something.

2. What did I not know about their context?

Were they oncall during the period you observed? Going through a hard quarter? Mentoring two juniors? Working a different time zone? The behaviour you observed might have a context you did not have access to.

3. What would the other person say if asked?

If you imagine the other person describing the same period of working together, what would they say? If you cannot honestly imagine a coherent version of their account that is not 'I was the problem', you have not done the work to understand them.

4. What would I want from this story if I were the other person?

The other person is likely also interviewing somewhere. They might describe this period to someone else. The version of the story you tell should be one you would be willing for them to hear. That standard alone improves most drafts.

What Great Looks Like (Rubric)

Strong difficult-people answers tend to score on six named signals.

1. Every description of the other person is behavioural, not character-level.

The rubric reads any character labels (lazy, toxic, arrogant) as red flags. Strong stories use precise behavioural descriptions and avoid labels entirely.

2. You name your own role in the dynamic.

'I had been sending three follow-up messages a day when one would have been enough; that was probably part of why their responses felt heavy' is the kind of self-awareness beat that signals senior-level maturity.

3. You stayed curious about their context.

A real beat where you tried to understand what was going on for them, not just react to it. 'I asked their manager (separately, framed as wanting to learn how they preferred to work) and learned they were oncall most of that quarter; that explained a lot of what I had observed.'

4. You actually tried something.

The story has a deliberate change you made: a new communication protocol, a different cadence, a structured ask, a one-on-one conversation. Stories that go from 'I noticed the problem' to 'I lived with it' miss the adaptability signal.

5. The relationship evolved or you escalated cleanly.

Not every difficult dynamic resolves. Strong stories either show evolution (the dynamic changed, often after a direct conversation) or a clean escalation (you raised it through legitimate channels and accepted the outcome). Stories where you 'avoided them forever' read as avoidance.

6. The reflection is about how you would handle it differently, not about how the other person should change.

'I would now have the direct conversation in the first month, not the third' is execution-level. 'They should have been more responsive' is wishing the other person were different and reads as not having learned anything.

The Four-Step Approach

1. Notice the pattern. Behaviourally, with specifics. Not 'they were difficult' but 'three of the last five PRs I had reviewed for them had a similar feedback loop'.

2. Name your own role. Honestly. The four self-awareness questions above are the workshop for this.

3. Try a deliberate change. A new protocol, a direct conversation, a structural fix. The change has to be specific enough that you can tell whether it worked.

4. Evolve or escalate cleanly. If the change worked, name how you can tell. If it did not, name the escalation you used and the outcome of that escalation.

Common Questions & Model Answers

The six prompts below cover roughly 90% of how this competency is probed. Each is a two-minute STAR answer that scores on the rubric above.

Prompt 1: 'Tell me about a difficult coworker.'

Model answer (strong, behavioural framing throughout, candidate names own role)

'In Q3 2023 I worked closely with a peer engineer on a six-week migration project. The friction was specific. Their typical response time on async messages was about two days; the team norm was about four hours, and I had calibrated my workstream around the team norm. I was sending follow-up messages when I had not heard back, sometimes three or four in a day, and the workstream felt heavier than it should have for both of us.

I owned figuring out how to make the collaboration work for the project.

I noticed the pattern in week one. I noticed my own role in week two. I had been sending follow-ups at a high cadence, and looking at my own messages, several of them were redundant and could have been batched into one. The cadence was probably making the response burden feel worse than it needed to be.

I tried a deliberate change. I batched my messages into a single end-of-day digest, marking each item as urgent or non-urgent, and gave them the explicit option of responding only to the urgent ones day-of. I also asked for a 30-minute conversation about how we were each working on the project, framed as wanting to figure out a sustainable cadence rather than as feedback. In that conversation I learned they were oncall for the quarter on a different rotation than mine, which I had not known, and they were also mentoring a junior engineer who was eating significant 1-1 time. None of that was visible from where I sat.

We agreed on a new protocol: I would batch async to a daily digest, they would respond by 5pm to anything marked urgent, and we would have a 20-minute live sync twice a week to clear non-urgent decisions. The dynamic shifted within a week. The project shipped on schedule. The relationship was stronger after the project than before, partly because we had had a structured conversation about how we worked.

The reflection is about how I framed the issue to myself initially. In week one I had been thinking of them as slow. By week two, when I named my own contribution and learned about their context, the framing had shifted to 'we have a cadence mismatch and we have not talked about it'. The mismatch was a shared problem with a shared fix, and most of the perceived difficulty had been on my side of the relationship, not theirs.'

What lands: explicit behavioural framing throughout (response times in numbers, not 'unresponsive'), the candidate naming their own contribution, learning the other person's context honestly, a deliberate change with a specific protocol, the relationship strengthened, and a closing reflection that says explicitly the perceived difficulty had been on the candidate's side as much as the other person's.

Prompt 2: 'Describe an unresponsive teammate and how you handled it.'

Model answer (strong, single specific behaviour, candidate tries multiple approaches)

'In Q1 2024 I was leading a small project where one of the three other engineers consistently took longer to provide PR reviews than the project required. We had committed to a launch date that needed about a four-hour PR turnaround as the team norm; their average was closer to a day and a half. The slip risk was real.

I owned figuring out how to keep the project on track without straining the relationship.

First, I asked behavioural questions of myself. Was I asking for review on PRs that were too large or contained too many concerns? Looking back, two of my PRs that quarter had been over 800 lines and would have been better as three smaller PRs. Was the timing of my requests bad? Several of my requests had landed late on Friday or just before lunch, which is genuinely worse review timing for most people. Some of the slowness was structural to how I was working.

Second, I had a direct conversation. I framed it as wanting to figure out a cadence that worked for both of us. I learned they were going through a heavy week of customer-facing work that was not visible in our project channel; they had not flagged it because they did not want to seem like they were not pulling weight. We agreed on three things: I would split large PRs more aggressively, I would mark PRs as urgent versus normal in the request itself, and they would set explicit expectations on review turnaround day-of when they could not meet the team norm. We also agreed that 'I have customer escalations today, expect 24 hours' was a fully acceptable response.

Their PR turnaround on my changes dropped from about a day and a half to about six hours over the next month, mostly because the change was on my side (smaller PRs, better timing, urgent marking). The project shipped on schedule. They thanked me later for raising it directly rather than escalating; they had been worried they were behind.

The reflection: the framing 'unresponsive teammate' was largely wrong in this case. The cadence mismatch was real but the cause was distributed: my PR sizes, my request timing, their unsignalled context, and a missing protocol about expectation-setting. I now default to having the cadence conversation in week one of any new collaboration rather than waiting for friction to surface.'

What lands: behavioural framing in numbers, the candidate identifying their own structural contributions (PR size, timing), a real conversation that surfaced context the candidate did not have, a multi-pronged change, an explicitly stated correction to the original framing ('the framing was largely wrong'), and a generalised lesson.

Prompt 3: 'Walk me through a time you had to work with someone whose style was very different from yours.'

Model answer (strong, style mismatch with no winner, both styles legitimate)

'In Q4 2022 I worked with a senior engineer on a quarter-long project. Our working styles were materially different. I default to async-first: write things down, decide via doc, schedule meetings only when async has stalled. They defaulted to live-first: have the conversation in person, document the outcome afterwards. Neither style is wrong; they are different defaults that suit different people.

I owned making the collaboration productive across the difference.

Week one was bumpy. I had written a design doc and was waiting for written feedback; they had read the doc, formed opinions, and were waiting for a meeting to discuss. We were each waiting for the other to do the next step. I noticed the pattern by Wednesday and I noticed my own role: I had not asked them how they preferred to give feedback, I had assumed my default was the protocol.

I asked for a 20-minute conversation about how we wanted to work together for the quarter. Their feedback was that they processed designs better in conversation, not in writing. My feedback was that I retained context better when decisions were written down. We landed on a hybrid: the doc was the artefact and the source of truth, but feedback would happen in a 30-minute weekly meeting and I would write the meeting notes back into the doc. The hybrid suited neither of us perfectly but worked for both.

The project shipped on schedule. The doc-as-source-of-truth combined with live-feedback-then-write-back has since become a pattern I use whenever I am working with anyone who prefers live discussion. I introduce it explicitly now in the first week of any new collaboration. I have used it on six subsequent projects with different collaborators, and it tends to work well across style differences.

The reflection: I had been treating my own working style as the default protocol. It was not the default; it was my default. The difficulty I had attributed to them was actually a missing alignment between two equally legitimate styles. Naming my own default was the unlock.'

What lands: explicit style description without judgment ('neither style is wrong'), the candidate noticing their own assumption about defaults, a real protocol that respected both styles, a generalised pattern the candidate now uses, and a reflection that flips the framing of the original difficulty.

Prompt 4: 'Tell me about a time you had to work with someone you did not get along with.'

Model answer (strong, no win-or-lose framing, mature handling)

'In Q2 2023 I was on a three-engineer team with a senior peer who I found hard to work with for the first two months of our collaboration. The specific friction was around design reviews: in the first six reviews where I had presented, their feedback had been delivered in a way I found brusque. Three or four times, they had cut me off mid-sentence. I had been carrying the friction quietly and it was affecting how I prepared for reviews.

I owned addressing it because the workaround (preparing more defensively, presenting less fully) was costing me and the team.

The first thing I did was check my own framing. Was the feedback substantively wrong, or just delivered in a style I found hard? Looking at the six reviews honestly, the feedback had been substantively useful in five out of six cases. The friction was about delivery style, not substance. That was an important separation.

Second, I noticed my own contribution. I had been answering their questions defensively, which had probably accelerated the cut-offs. I had also not signalled that I was midway through a thought when they had cut in. I had been hoping they would notice and stop, which is rarely how this works.

Third, I had a direct conversation. I framed it carefully: 'I want to share an observation about how design reviews are landing for me, and I want to hear your read'. I named the specific behaviour (cut-offs) without labelling it. I named my own role (defensive answering, not signalling midway-thought). They were thoughtful and a bit surprised; they had not been aware of the pattern at all. Their explanation was that they had been processing fast and had not realised they were cutting in. We agreed on a small protocol: I would say 'one moment' if they cut in mid-thought, and they would adjust. The protocol felt awkward for the first review and natural by the third.

Over the next three months, the dynamic shifted substantially. We continued to disagree on design substance, sometimes sharply, but the disagreement felt productive rather than personal. Six months later we were both on a different project together and the working relationship was easy.

The reflection: the original friction had two components, only one of which was about them. The other was about how I had been responding to them. I had been treating it as their problem to fix, when half of it was mine. The direct conversation with the specific behavioural framing was the fix.'

What lands: a real interpersonal friction handled with care, the candidate explicitly checking whether the substance was actually wrong before addressing the style, naming the candidate's own contribution to the dynamic, a small protocol that worked, a six-month follow-up showing the relationship is durable, and a closing reflection about the distribution of the original problem.

Prompt 5: 'Describe a coworker you struggled to communicate with and what you did about it.'

Model answer (strong, communication style mismatch, deliberate experimentation)

'In Q3 2024 I was collaborating with a PM on a multi-quarter initiative. Our communication patterns were misaligned in a specific way: they preferred high-level conceptual conversations, I preferred detailed concrete questions. We would leave meetings each thinking we had aligned, and a week later it would become clear we had been talking about different things at different levels.

I owned trying to fix the communication pattern because it was creating real rework.

I noticed the pattern after the third instance of misalignment. I noticed my own role: I had been asking abstract questions in their style ('what is the strategic intent of X') and getting abstract answers, then trying to translate them into concrete decisions in my head, where the translation was lossy. I had been mistaking conversational alignment for decisional alignment.

I tried a deliberate change. After every meeting with them, I started writing a short followup message: 'Confirming what I heard: A, B, C. Anything to add or correct?'. The first one I sent surfaced two real misunderstandings within an hour. The second surfaced one. By the fifth followup, the misunderstandings had largely dropped to zero, partly because they had started catching themselves on ambiguity in real-time and clarifying.

The followup-write-up has since become a default I use whenever I am working with anyone whose communication style is more conceptual than mine. I have used it in four other collaborations and it has caught real misalignments in each.

The reflection: the original difficulty was framed as 'they communicate vaguely', but it was more accurately 'we operate at different levels of abstraction and have not bridged'. The bridge was a small artefact (the followup write-up), not a change in either of our preferred styles. Neither of us had to communicate differently; we had to add a converging step in between.'

What lands: a specific communication pattern, the candidate noticing their own translation behaviour as part of the problem, a small concrete change with measurable signal (misunderstandings caught, then dropping), a generalised pattern, and a reframe of the original difficulty as a structural mismatch rather than a character trait.

Prompt 6: 'Tell me about a working relationship that did not get better, and how you handled it.'

Model answer (strong, honest non-resolution with clean escalation)

'In Q1 2023 I had a working relationship with a senior peer that did not improve over the six months we collaborated, despite real effort on both sides. The friction was around design-review feedback. They preferred extensive conceptual debate before any commitment; I preferred narrowing to a decision and then writing down the open questions. We had different styles and each had limited tolerance for the other's mode at the volume our collaboration required.

I owned trying multiple deliberate changes and, when those did not land us in a sustainable pattern, escalating cleanly.

Three things I tried, in sequence. First, I adapted to their style: I extended the conceptual debate phase, took longer to write decisions, and tried to find a rhythm that suited their preferences. Two months in, I had partly succeeded but my own work had slowed by about 20%, which my manager had flagged. Second, I tried a hybrid protocol similar to the one I have used in other collaborations: an artefact as the source of truth, scheduled live discussion, written-back outcomes. They disliked this because it converted the conceptual phase into something more concrete than they wanted. Third, I tried a direct conversation about how we wanted to work together for the rest of the project. We had a thoughtful 60-minute conversation, and it did not result in a working pattern that fit both of us. Some style differences are real and not all of them resolve.

At the four-month mark, I escalated to my manager. Not as a complaint about the other person, but as a request for help on the working dynamic itself. I framed it: 'we have tried three different protocols, none have stuck, our individual work outputs are both fine but the joint output is slower than it should be, what would you recommend'. My manager helped restructure the project so we had less direct overlap, with a shared artefact at the boundary rather than continuous joint work. That worked for both of us. Each of our individual streams ran cleanly, and the integration points were small enough to handle through the artefact.

The project shipped about four weeks late, which I had communicated to stakeholders at the time of the restructure. The peer and I have since worked on one other project where we had clearer role separation, and it went smoothly. My read is that we are not natural collaborators in dense joint work but are fine in projects with clear boundaries.

The reflection: not every working dynamic improves with effort. Knowing when to restructure rather than continue trying is part of the skill. I had been holding on to the assumption that I could find the right protocol, when the more honest read was that some style differences are persistent and the right move is structural separation. I now look for that signal earlier, and I am willing to escalate to a structural change at the 60-day mark rather than the 120-day mark.'

What lands: an honest non-resolution (neither party 'won', neither was characterised as the problem), three sequential attempts that the candidate is honest about not all working, a clean escalation framed as a request for help rather than a complaint, a restructure that respected both people's working styles, and a mature reflection about the limits of effort.

Pitfalls Specific to This Competency

Four traps that show up most often in difficult-people stories. The first is the most important by a wide margin.

1. Labels and characterisation. 'They were toxic', 'they were lazy', 'they were impossible to work with'. Even when these descriptions feel earned, naming them in an answer is one of the strongest negative signals in any behavioral round. The interviewer reads it as evidence the candidate defaults to character explanations and is likely to bring those framings into future relationships. Strong stories never label, only describe.

2. Making the other person the only problem. Stories where the candidate is faultless and the other person is the entire issue read as one-sided regardless of accuracy. Almost every difficult dynamic has contributions from both parties; naming your own honestly is the single biggest move.

3. Avoidance dressed up as resolution. 'I just learned to work around them' or 'I avoided them after that' are not resolutions. They might be the actual outcome of a real story, but if so, name that explicitly and reflect on what you would do differently. Avoidance presented as the answer scores poorly because it does not show evolution.

4. Stereotyping a pattern. Even the patterns named in this lesson (slow responder, status-game player, etc.) are not boxes you put people into. They are descriptions of behaviour that may or may not be characteristic in a specific period. Treat each story as a specific person in a specific context, not as a category. Avoid generalisations like 'I have worked with several people like this' because they imply that the category is the explanation.

Practice Prompts & Exercises

For each prompt below, draft a 250 to 350 word STAR answer using a real working relationship that was hard for you. For every story, run the behaviour-vs-label test: circle every adjective applied to the other person and replace any character labels with behavioural descriptions.

1. Tell me about a difficult coworker.
2. Describe an unresponsive teammate and how you handled it.
3. Walk me through a time you had to work with someone whose style was very different from yours.
4. Tell me about a coworker you struggled to communicate with and what you tried.
5. Describe a working relationship that took deliberate work to improve.
6. Tell me about a working relationship that did not improve, and how you handled that.
7. Walk me through a time you had to give difficult interpersonal feedback to a peer.

For every story, also run the four self-awareness questions: what was I doing that may have made the dynamic worse, what did I not know about their context, what would they say about this period, and what would I want from this story if I were them?

Bridge / Cross-References

This lesson is the most sensitive in the Teamwork & Collaboration category. The most useful Foundations companions:

• common-mistakes covers badmouthing coworkers as one of the largest interview red flags; this lesson is the deeper treatment.
• crafting-compelling-stories shapes the resolution arc without making the story adversarial.
• reading-the-question is useful here because difficult-people prompts can sound similar to conflict-resolution prompts but are graded on different signals (long-running pattern vs discrete disagreement).
• quantifying-impact matters even here: behavioural framing in numbers (response times, PR counts, project slip in days) is a key signal of the precision the rubric grades.

The next lesson, Building Consensus & Alignment, picks up where this one leaves off. Where this lesson is about navigating long-running dynamics with one person, that one is about getting many people aligned on a shared decision. The competencies overlap in stories where the candidate had to get buy-in across a group that included a difficult dynamic.