How would you handle an unresponsive teammate?
Company: Apple
Role: Software Engineer
Category: Behavioral & Leadership
Difficulty: medium
Interview Round: Technical Screen
## Scenario
You are working on a project with a hard deadline. A teammate who owns a critical task has become unresponsive (misses standups, does not reply to messages, and no visible progress). The rest of the team is blocked.
## Questions
1. What steps would you take in the first 24–48 hours to unblock the project?
2. How would you balance empathy (they may have personal issues) with accountability and delivery?
3. When, how, and to whom would you escalate if the situation doesn’t improve?
4. How would you communicate status and risks to your manager and stakeholders?
5. After the deadline, what would you do to prevent recurrence (process or team changes)?
Quick Answer: This question evaluates interpersonal leadership and project-management competencies—including communication, accountability, escalation judgment, stakeholder risk communication, and empathy—in a software engineering, behavioral and leadership context.
Solution
## What a strong answer should demonstrate
- **Ownership & bias for action:** You unblock the team quickly without waiting indefinitely.
- **Empathy + professionalism:** You assume good intent but still manage delivery risk.
- **Clear communication:** You keep stakeholders informed with facts, not blame.
- **Good escalation judgment:** Escalate early enough to protect the deadline, but not as a first move.
- **Process improvement:** You reduce single points of failure going forward.
## A solid step-by-step approach (with reasoning)
### 1) Confirm the problem using multiple channels (same day)
**Goal:** Distinguish “busy” vs “blocked” vs “truly unavailable.”
- Check existing signals: commit history, ticket updates, Slack/Teams status, calendar.
- Send a short, specific message:
- What you need (status, ETA, blocker)
- When you need it (e.g., “by EOD”)
- Offer help (“Can I jump on a 10-min call?”)
- Try a second channel if no response (Slack + email; if your culture supports it, a quick call).
**Pitfall to avoid:** sending vague “ping” messages that don’t clarify urgency.
### 2) Reduce project risk immediately (same day)
**Goal:** Unblock delivery while the root cause is still unknown.
- Identify what is blocked and create a **plan B**:
- Can you **re-scope** to ship an MVP?
- Can you **parallelize** by splitting the task into smaller pieces?
- Can someone else start on integration, tests, or scaffolding?
- If needed, start a **temporary re-assignment**:
- Ask another teammate (or yourself) to take over the most critical path.
- Request access, docs, and context (design doc, PRs, partial code) to minimize ramp-up.
**Key framing:** “I’m doing this to protect the deadline, not to punish anyone.”
### 3) Have a direct, private conversation (within 24–48 hours)
If you reach them:
- Be respectful and factual: describe impact (blocked tasks, timeline risk).
- Ask open-endedly: “Is something blocking you? Anything I can do?”
- Agree on concrete next steps:
- A small deliverable within 24 hours (e.g., design outline, partial PR)
- A clear ETA
- Update cadence (e.g., daily check-in until back on track)
If they mention personal issues:
- Don’t probe for details; focus on what support is possible.
- Suggest involving manager for workload adjustment/time off.
### 4) Escalate appropriately (early, with options)
**When to escalate:**
- The work is on the critical path and you’re within days of a deadline.
- You cannot get a response after repeated attempts.
- You suspect a health/emergency situation, or the person is fully unavailable.
**How to escalate (to manager/lead):**
- Use a neutral, delivery-focused summary:
- Facts: last contact, what’s blocked
- Risk: what deadline is impacted
- Actions taken: attempts to contact, mitigation started
- Ask: reassign ownership, adjust scope, or formal check-in
**Pitfall:** escalating with blame (“they’re lazy”). Keep it about impact and risk.
### 5) Communicate to stakeholders with clarity
- Provide a brief status update:
- Current state
- Risk level
- Mitigation plan and updated ETA
- Avoid naming/attributing individual performance issues in broad channels.
### 6) After-action: prevent recurrence
Focus on system fixes:
- Reduce single points of failure:
- Shared ownership, pairing on critical components
- Better documentation, design reviews
- Improve visibility:
- Smaller tasks, frequent PRs, clear definitions of done
- Early risk flags in standup (“blocked > 1 day triggers help/escalation”)
- Agree on team norms:
- Response expectations during work hours
- Backup owners for critical tasks
## STAR-style example outline (easy to deliver in interview)
- **S:** Critical feature due Friday; teammate owns API changes; unresponsive since Tuesday.
- **T:** Ship on time; avoid team being blocked.
- **A:** Tried multiple channels; offered help; split tasks; took over integration; informed manager with facts; re-scoped nonessential parts.
- **R:** Delivered MVP on time; later rebalanced workload and added “backup owner + daily PR” practice, reducing future risk.
## Common edge cases to mention
- **If there’s a possible emergency:** involve manager/HR per policy rather than repeatedly contacting.
- **If you’re not the lead:** still take initiative to mitigate, but align escalation with your manager/tech lead.
- **If it’s a recurring pattern:** document impact and work with manager on performance process (not public shaming).