Underperforming Teammate Interview Question

Underperforming Teammate Interview Question: Your Answer Starts Too Late

You've got a story ready. A teammate fell behind, you noticed, you had a chat, things improved. Clean narrative, three minutes, done. You've rehearsed it in your head during the commute and you're feeling pretty good about it.

Most candidates answer this question exactly that way. And most candidates score "meets bar" at best.

The question isn't asking whether you can confront someone. It's asking whether you can diagnose before you judge. That single step, the one that happens before you open your mouth, is where interviewers separate strong hires from everyone else. The step most people skip entirely and then wonder why they got a mixed signal on behavioral.

This Question Is Not About a Difficult Coworker

There's a version of this question that's really about conflict: "Tell me about a time you worked with a difficult person." That one tests emotional regulation and boundary-setting. If you want the full breakdown, the difficult teammate guide covers that arc separately.

This one is different. Underperformance is a gap between what someone is contributing and what the team needs. The reasons can be a dozen things: unclear expectations, a skills deficit, something going wrong outside work, burnout, a mismatch between the role and what they thought they signed up for. Or, yes, sometimes a genuine effort problem.

The error most candidates make is treating it like conflict from the start. They describe noticing the problem and going straight to "I talked to them about it." That's a conflict arc. The performance arc has a step before the conversation, and skipping it is what interviewers notice. It's the difference between "I confronted the problem" and "I understood it first."

The Attribution Test

Social psychologist Lee Ross identified the fundamental attribution error in 1977: when we observe someone else behaving unexpectedly, we systematically overweight character explanations ("they're unmotivated") and underweight situational ones ("the requirements weren't clear" or "they're dealing with something outside work").

Developers do this constantly. When your own code breaks, it's an environmental issue, a flaky test, an upstream service. When a teammate's output drops, the instinct is: checked out, not a team player, just isn't performing. Same cognitive bias, wildly different conclusions depending on whose behavior is under the microscope.

The strong-hire answer starts with curiosity, not a verdict. You noticed a pattern. You asked yourself what might be causing it. You gathered more data before drawing a conclusion. Only then did you decide what to do.

The weak-hire answer treats the underperformance as setup for your heroic intervention. The teammate's internal state is a black box. You never wondered why. You just responded. It sounds confident. It reads as incurious.

What Gets Scored

Four signals get explicitly watched:

1. Diagnosis before judgment. Did you investigate the root cause before labeling this a people problem? Root causes split roughly into: skills gaps (can they do the work), will gaps (are they motivated), personal circumstances (is something external affecting them), and expectation gaps (do they know what good looks like). Each has a different remedy. Good performers see the category before picking the response.

2. Private, direct, and curiosity-first. The conversation should have happened one-on-one before anything else. Not in a team meeting. Not in a Slack thread. And it should have opened with something like "I noticed X, is everything okay?" not "You've been missing deadlines and I need you to step up." The first is diagnostic. The second is a verdict with a thin veil of politeness.

3. Escalation timing. When you looped in a manager, and why. Escalating immediately signals you're not comfortable addressing peer issues directly. Never escalating signals you let team performance suffer to avoid discomfort. The right answer shows a specific moment when it became clear this needed to go upward, and a reason that makes sense.

4. Outcome with mechanism, not miracle. Interviewers distrust answers where the teammate simply "turned things around." What specifically changed? What did you agree to together? What did you check in on, and how often? Without the mechanism, it sounds like you had a pep talk and got lucky.

Where the Time Goes

S + T: 15 to 20%. Context only. Who was on the team, what you were building, why this person's contribution mattered. Don't editorialize about the gap yet. If you spend half your time-box here, you have nothing left for the part that matters.

A: 55 to 60%. Four beats:

Observe and check assumptions. What did you actually see, over how long, and what alternative explanations did you rule out before concluding there was a real problem?
The private conversation. How you opened it matters more than what was said in the middle. Curiosity signals: "I wanted to check in," "I noticed X," "I could be missing context." Accusation signals: "You need to," "The team has noticed."
The collaborative plan. What you agreed on together, not what you decided and told them. If you came in with observations and built next steps together, that's a strong signal. If you arrived with a fixed solution, that's a weak one.
What happened afterward. Follow-ups, check-ins, the moment you knew it was working, or the moment you knew you needed to escalate.

R: 25 to 30%. What changed, how you verified it, what the experience changed about how you work with teammates.

What a Strong Answer Sounds Like

Here's what this actually looks like in practice. Notice that no one in this story is the villain.

Situation: We were four weeks into a six-week sprint to ship a new API integration. My teammate was responsible for the auth layer and I started noticing his pull requests were taking longer to arrive and required more back-and-forth than usual.

Task: I was the informal tech lead on the project. Nothing in my title said I owned his performance. But if the auth layer slipped, the whole integration slipped.

Action: Before anything, I spent a few days watching more carefully. Was this a new pattern or had I just started paying attention? It was new. His reviews were also taking longer to complete, and he was slower to respond in Slack. Those weren't signs of laziness. They looked more like someone context-switching heavily or dealing with something outside work.

I asked him to grab coffee. I opened with: "I wanted to check in, you seem a bit stretched lately, am I reading that right?" That question alone opened a real conversation. He was splitting time across two projects and hadn't told anyone because he didn't want to seem like he couldn't handle it. The second project had come in informally from another team lead.

We made a specific agreement: he'd tell that team lead we couldn't afford to split the auth work any further until the integration shipped, and I'd back him up in that conversation if he needed it. We added a quick 10-minute sync every other day for the rest of the sprint.

Result: The auth layer shipped on time. More importantly, he told me afterward it was the first time someone had asked what was getting in the way rather than pointing at the gap. I built that into how I work with teammates now. If someone's output changes, I check the environment before I check the person.

The Five Killers

1. Starting with the verdict. "He just wasn't pulling his weight" as an opener tells the interviewer you never asked why. That's an attribution error wearing a confidence costume. It sounds decisive. It reads as someone who would make a bad people manager.

2. Describing how you covered for them. Quietly doing their work while hoping they'd catch up sounds supportive. It isn't. It removes any signal that something is wrong and rewards the underperformance with silence. Interviewers read this as enabling. It's the code equivalent of catching someone's bugs in your own review and not saying anything, then being surprised when the bugs keep coming.

3. Going to the manager first. Escalating before you've had a direct peer conversation signals discomfort with accountability at the peer level. Unless the situation involved misconduct or a power dynamic that made the conversation unsafe, the conversation should happen between you first. "I wasn't sure it was my place" is not the framing you want here.

4. The miraculous turnaround. "After we talked, he really turned things around." What specifically did he change? What did you two agree to? Without the mechanism, the story has no weight. You had a pep talk and got lucky. Two weeks later the interviewer writes "vague on follow-through" in their notes and moves on.

5. Making it a character story. The underperformer should not be the villain. Describing someone as "checked out," "not a team player," or "always making excuses" shows the interviewer exactly how you'll describe your future teammates when they disappoint you. These are ticket-title descriptions of a human being, and it flags poorly.

How the Bar Shifts at Senior Levels

For early-career roles, interviewers want to see that you can have a direct peer conversation and follow through. That's the floor.

At senior and staff level, the question changes. They're not just asking whether you can handle one person. They're asking what you do when the problem is structural. Maybe the underperformance is a symptom of unclear team-level expectations, or a poorly scoped role, or a gap in how onboarding worked. Senior engineers are expected to see the system around the person, not just the person.

A strong senior answer has all the same beats, but adds a layer: after resolving the immediate situation, did you do anything to prevent it from recurring? Did you flag the structural issue? That's the difference between solving a performance problem and improving how the team runs. It's the same muscle tested by influence without authority questions: your ability to shape outcomes without a formal mandate.

Practice This Out Loud

Reading your STAR structure in your head and delivering it in a conversation are completely different skills. One feels smooth. The other reveals every gap you glossed over in your head. Hesitation between the beats reads as uncertainty about whether any of it is true.

SpaceComplexity does live voice mock interviews so you can practice this the way it actually happens, not the way it sounds in your shower.

The underperforming teammate question feels softer than a systems design question, but it's scored just as deliberately. Answer it like you'd answer a hard technical problem: diagnose first, then act, then reflect.