Interview questions · Apple
How would you handle an unresponsive teammate?
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.
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
- What steps would you take in the first 24–48 hours to unblock the project?
- How would you balance empathy (they may have personal issues) with accountability and delivery?
- When, how, and to whom would you escalate if the situation doesn’t improve?
- How would you communicate status and risks to your manager and stakeholders?
- After the deadline, what would you do to prevent recurrence (process or team changes)?
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).
Community answers
Nothing here yet.
Join in on CSWork →