In this article
Before you start
Why interviewers ask this
A manager who delays this conversation hurts the person, the team and their own record. GitLab's handbook calls a failure to address performance concerns in time "a reflection on the manager's performance" and says it harms the team and the business (GitLab Handbook, September 2025). Interviewers use the question to separate a candidate who diagnoses from one who punishes, and one who acts from one who drifts. A weak answer jumps straight to a performance plan or to firing.
A strong answer names the cause, shows fairness to the person and says what happens at the end. Candidates report the question in engineering manager loops at AI labs and large tech companies (see the engineering manager interview hub), sometimes as a story ("tell me about a time") and sometimes as a hypothetical. Because the interviewer cannot see your team, they listen for specifics: what you said, what you wrote down and what changed.
The low performer question from first principles
- Low performer
- A low performer is an employee whose sustained results fall short of the written expectations of the role, judged over a period and against a bar the person was told about, not someone who had one bad month.
- Skill gap
- A skill gap is a shortfall in capability, such as technical depth, prioritisation or communication, that remains even when the person is motivated, and it is addressed by coaching, training, tools or a mentor.
- Will gap
- A will gap is a shortfall in motivation or conduct in a person who has the skills for the role, such as disengagement or behaviour that hurts colleagues, and it is addressed through coaching on expectations and conduct, with the consequences stated.
In plain words
Handling a low performer is like treating a cough. A doctor asks questions before choosing a medicine, because one cough can have several causes and each needs a different treatment. Prescribing before asking is the usual mistake. The analogy breaks in one place. A patient comes for help, but an employee may not know there is a problem, so the first job is to make the problem visible and fair. Said precisely, the answer has five moves: find the cause, say it plainly, agree a plan with dates, protect the team and decide. GitLab's handbook uses a skill-based and will-based model in the same way, to find the root cause and then choose the plan (GitLab Handbook, September 2025).
Step 1: Find the cause, skill or will
Finding the cause means deciding whether the shortfall is a gap in skill or a gap in will before any plan is written. The input is a pattern, such as missed deadlines, slow replies, unclear status of work or colleagues working around the person; GitLab lists all of these as warning signs. The output is a cause you can check.
Look at history first: earlier reviews, whether the person has taken enough time off, and whether something has changed in their life, which are the three checks GitLab names (GitLab Handbook, September 2025). Then ask the person what is in the way. Keep a third cause open: unclear scope or missing support. What you now know: which kind of problem you have, and therefore what the plan contains and what is fair.
If the interviewer asks how you tell skill from will, say: "I check whether the person delivered when the work was clear and they were engaged, from their history and an honest conversation, and whether the gap is in what they can do or in how they act."
Step 2: Say it plainly, with specifics
Feedback that works names the situation, the behaviour and the impact, then asks for the other person's view. The Center for Creative Leadership (CCL) describes the situation-behavior-impact (SBI) model: name the specific setting, describe the observable action without judgement, and explain its effect. Its extended version adds intent, a question such as "what were you hoping to accomplish?", which turns the talk into a two-way conversation (CCL, August 2025).
The input is two or three dated examples; the output is a conversation the person can repeat back to you. Say what the expectation was, what you saw and what it caused. Write down what was agreed afterwards. What you now know: the person has heard the gap in words they can check.
Step 3: Agree a time-boxed plan with checkpoints
A time-boxed plan is a short written agreement with observable goals, the support you will give and dates to review progress. The input is the cause from step 1 and the examples from step 2; the output is goals the person can check themselves. For a skill gap, GitLab lists coaching, specific training, extra tools or guidance, and a mentor or buddy for an agreed period. For a will gap, the plan is about expectations and conduct. Say who does what by when and what follows either outcome.
How long a plan runs depends on company policy and local law, so involve your human resources (HR) team early; GitLab calls early contact with its team-member-relations group essential (GitLab Handbook, September 2025). One case does not wait for a plan: behaviour that breaks the code of conduct, such as harassment, goes to HR at once; GitLab tells any manager who sees it to contact its team-member-relations group immediately (GitLab Handbook, September 2025). What you now know: both sides can tell on the review date whether it worked.
Step 4: Protect the team while the plan runs
The rest of the team pays for a low performer, so a good answer says how their workload and trust are protected. GitLab lists signs of that cost: other team members start working around the person, frustration lasts, and delivery suffers. Google's research on 180 teams names dependability, where members reliably complete quality work on time, as one of five dynamics of effective teams (Google re:Work).
Move work on the critical path to reliable owners for now, and watch for high performers quietly absorbing the gap. Tell the team what they need to plan around, not the details of the plan. The team health page covers how to see strain early. What you now know: the team can keep delivering while one person improves.
Step 5: Decide when the plan ends
The decision is the step candidates skip: at the review date the plan has worked, partly or not, and the manager acts on that. GitLab says all team members are offered coaching and feedback before a decision to exit them, and that it may move to separation after documented coaching without improvement. Name the outcomes aloud: reset the bar, extend once with a reason, change the role, or end the employment with dignity. What you now know: a plan without a decision is only a delay.
Step-by-step description
- Decide whether the gap is skill or will.
- Name the situation, behaviour and impact.
- Write goals, support and review dates.
- Protect the team's work while the plan runs.
- At the review date, act on the result.
- Finding the cause means deciding whether the shortfall is a gap in skill or a gap in will before any plan is written.
- The decision is the step candidates skip: at the review date the plan has worked, partly worked or not worked.
The two causes of step 1 lead to different coaching, which the table below sets side by side. A skill gap is a shortfall in capability that remains even when the person is motivated, and a will gap is a shortfall in motivation or conduct in a person who has the skills for the role. The signs come from GitLab's lists. GitLab makes documented coaching the first step for both types and, for a skill gap, names training, tools, guidance or a mentor for an agreed period (GitLab Handbook, September 2025). For a will gap, the coaching is about expectations and conduct.
Text description of the diagram
- A skill gap is a shortfall in capability that remains even when the person is motivated.
- A will gap is a shortfall in motivation or conduct in a person who has the skills for the role.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
A Staff-level answer shows a diagnosis, a fair process, protection of the team and a decision, in about a minute. It treats the plan as a tool, not as the goal.
How do you handle a low performer?
I start by finding out what kind of low performer I have, because a skill gap and a will gap need different plans. I look at their history, check whether anything has changed, and ask what is in the way. Then I give specific feedback on what I saw and its effect, and agree a written plan with observable goals, the support I will give and review dates, with HR involved early. While it runs I move critical work so the team is not carrying the gap. At the review I decide: reset, extend once with a reason, change the role or exit. I judge myself on whether the person and the team always knew where they stood.
What makes it Staff-level: it names the cause before the plan, it includes the team and it ends on a decision with the options spoken aloud.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Diagnosis | Assumes laziness | Separates skill from will | Checks history, life changes and unclear scope too |
| Feedback | "I tell them to improve" | Specific, with an example | Specific, with their intent heard |
| Plan | None, or dismiss at once | Written goals and dates | Support named, HR involved early, conduct breaches to HR at once |
| Team | Not mentioned | Workload shifted | Trust and workload protected, high performers watched |
| Decision | Drifts | States the outcome | Options named, dignity kept |
Three variants of this question
"Tell me about a low performer you hired."
Own the hiring side first: say what the interview loop missed and what you changed in how you assess that skill. Then use the five steps as the spine of the story, with one measurable change and one thing you would do differently. The behavioral interviews hub covers how to shape the story.
"What would you do with a low performer who is well liked and senior?"
Treat the bar the same way, because the team watches whether standards apply to everyone. Check whether the role's expectations changed, then give the same specific feedback; seniority changes the conversation, not the fairness.
"What if the person says they are overloaded?"
Take it seriously and test it: compare their load with colleagues' and check scope against the written expectations. If the claim holds, the fix is yours to make; if it does not, say so with the evidence from the earlier examples.
Common mistakes
- Jumping to a plan. (wrong) "I put them on a plan straight away." (right) "First I find out whether it is skill, will or something I created."
- Vague feedback. (wrong) "I told them they needed to step up." (right) "I described the missed review on a named day and what it blocked."
- Forgetting the team. (wrong) A story with only two people in it. (right) Say who took on the work and how you protected them.
- No ending. (wrong) "We worked on it for a while." (right) State the outcome and the date you decided.
- Blaming the person for a gap you created. (wrong) Ignoring unclear scope. (right) Name what you changed on your side.
Follow-up questions
How do you manage poor performers?
Use the same sequence each time: cause, specific feedback, a written plan with review dates, protection of the team and a decision. Consistency is what makes the process fair.
What is the difference between a skill problem and a will problem?
A skill problem is a capability gap in a motivated person; GitLab answers it with coaching, specific training, tools or a mentor (GitLab Handbook, September 2025). A will problem is a motivation or conduct gap in a person who has the skills, so the coaching conversation is about expectations and what happens if they are not met.
When do you involve human resources?
Early. GitLab calls early contact with its team-member-relations group essential, partly to keep feedback within local labor rules. The people management round shows where this fits in a whole answer.
What if the low performer has a personal problem?
Ask, listen and adjust support first. GitLab asks managers to check that all is well in the person's personal life and to give appropriate support before judging the shortfall; tell your own manager and HR what you need to.
How would you handle an engineer who creates conflict with team members but is still performing well?
Treat it as a will gap: output is fine, conduct is not. GitLab's handbook covers the case of someone who is technically performing but has will-based issues, and the path is the same sequence, with specific feedback on the behaviour and its effect on colleagues (GitLab Handbook, September 2025). Strong output does not exempt anyone from the bar, and conduct that breaks the code of conduct goes to HR at once. The conflict between two engineers page covers the case where the tension is between two people.
Can you give an example of an underperforming employee, your actions and how it ended?
Tell it in the five-step order: the cause you found, the feedback you gave, the written plan and its dates, how you protected the team, and the decision at the end. Name the outcome plainly, whether the person recovered, moved role or left, and what you would do differently. Use an illustrative composite only if you say it is one; keep every figure one you can stand behind.
- Diagnose first: skill, will, or something the manager created.
- Give specific feedback on what you saw and what it caused.
- Agree a written, time-boxed plan with support and review dates.
- Protect the team while the plan runs.
- End on a decision; a plan without one is a delay.
Sources
- Underperformance, The GitLab Handbook — GitLab (content last updated 2025-09-04), 4 Sep 2025
- Closing the gap between intent vs. impact: the SBII feedback model — Center for Creative Leadership, 19 Aug 2025
- Understand team effectiveness (Project Aristotle), Google re:Work — Google re:Work (originally published 2015; month and day not stated on the page), 1 Jan 2015