Describe a situation where a team member was struggling and what you learned from it
Asked at:
Meta
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you respond when someone around you is underperforming, overwhelmed, or stuck. They want to see whether you notice problems early, approach the person with empathy and judgment, and take appropriate action for your level rather than ignoring the issue or trying to "fix" the person unilaterally. The "what you learned" part tests self-awareness: strong candidates show they updated how they support others, communicate expectations, or structure work in the future.
“Tell me about a time someone on your team was having a hard time. How did you handle it?”
“Have you worked with a teammate who was stuck or underperforming? What did you do, and what did you take away from it?”
“Describe a situation where a colleague needed more support than usual. What happened?”
“Can you give me an example of noticing a team member was struggling and stepping in appropriately?”
“What's a time you learned something important from trying to help a struggling coworker or direct report?”
Key Insights
- You do not need a dramatic performance problem for this story to work. A strong example often involves someone capable who was blocked by ambiguity, confidence, workload, or context you took time to understand.
- You are being evaluated on judgment, not heroics. Show that you supported the person in a way appropriate to your role and knew when to coach, partner, escalate, or adjust the work instead of simply taking it over.
- The learning matters as much as the rescue. You should be able to name how this changed your future behavior with teammates, not just that the immediate situation eventually worked out.
What interviewers probe atlevel
Top Priority
At junior level, interviewers mainly want to see curiosity and empathy instead of snap judgments about why someone was struggling.
Good examples
🟢'I noticed a teammate was stuck on a bug for a few days, so I asked if they wanted to walk me through what they'd tried. That conversation made it clear the real issue was that the service behavior wasn't documented, not that they lacked effort.'
🟢'Someone on my project was quiet and not making progress, so I checked in one-on-one and learned they were new to that part of the codebase and didn't know who to ask. That changed how I tried to help.'
Bad examples
🔴'A teammate kept missing pieces of the task, so I assumed they weren't paying attention and I just rewrote that part myself so we could move on.'
🔴'They seemed behind, and I figured they probably just needed to work faster, so I started reminding them more often about the deadline.'
Weak answers infer character flaws from surface symptoms; strong answers investigate and update their understanding before choosing a response.
You are not expected to manage performance as a junior engineer, but you are expected to be helpful, collaborative, and to pull in the right support when needed.
Good examples
🟢'I offered to pair for an hour, shared the notes and examples that had helped me, and then suggested we loop in our tech lead for broader context since I didn't want to guess.'
🟢'I helped break the work into smaller steps, checked in after they tried the next piece on their own, and brought our manager in once it was clear the timeline might slip.'
Bad examples
🔴'They were having trouble finishing their part, so I just completed it myself and told them what I changed afterward.'
🔴'I kept giving them advice in code review even though it wasn't helping, because I didn't want to bother our lead with it.'
Weak answers either overstep or disappear into passivity; strong answers provide meaningful help while respecting their actual authority and limits.
Valuable
Even as a junior candidate, you can stand out by talking about the teammate as a capable person having a hard time, not as dead weight.
Good examples
🟢'They were smart and putting in effort, which is why I wanted to understand what wasn't clicking instead of assuming they couldn't do it.'
🟢'I tried to be careful not to embarrass them in front of the group, so I checked in privately and focused on the task rather than making it personal.'
Bad examples
🔴'They just weren't very strong technically, so I tried to limit how much of the project depended on them.'
🔴'I could tell they were the type who needed a lot of hand-holding, so I kept things simple for them.'
Weak answers flatten the person into a deficiency; strong answers preserve dignity and assume positive intent while still addressing the issue.
Example answers atlevel
Great answers
On a project at my last internship, another intern and I were splitting up a small internal tool, and I noticed he had been stuck on his part for a couple of days and had gone pretty quiet in our chat. I asked if he wanted to walk me through what he had tried, and that made it clear he wasn't avoiding the work—he was confused by an older service that barely had any documentation. We paired for a bit, I shared the notes I'd made when I first learned that area, and then we pulled in our mentor to confirm one design choice instead of guessing. After that he was able to finish the task himself, and we still hit our deadline. What I learned was not to assume a lack of progress means a lack of effort; now when someone seems stuck, I try to understand whether they need context, not just answers.
At a small startup where I was the most junior engineer on a three-person team, one of my teammates started missing small deadlines and seemed increasingly frustrated with routine tasks. When I offered to pair for a bit, he showed me that our automated build-and-test system was flaky and took a long time to give feedback, so he was spending hours chasing transient failures instead of actually making progress. I reproduced the problem locally, tracked down a timing bug in a test helper, and fixed the test so it no longer failed intermittently; I also wrote a short script teammates could run quickly before committing and documented the steps. After that he could move forward without the repeated wasted effort and we shipped the feature on time. I learned that not all struggles are about skill—sometimes small, practical improvements to tooling and process unlock a lot of productivity and confidence.
Poor answers
A teammate on a class project was struggling with their part of the backend, and it was slowing the group down. I had already done something similar before, so I just took over that piece and sent them the final version so we wouldn't miss the deadline. It worked out because the project was submitted on time and the rest of the team appreciated that I moved quickly. I learned that when someone is behind, sometimes the best thing is just to handle it yourself.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid February, 2026
Meta
Manager
Mid December, 2024
Amazon
Mid-level
Describe a situation where a team member was struggling and what you learned from it
Hello Interview Premium
Your account is free and you can post anonymously if you choose.