“What’s your greatest weakness?” has a reputation as a trick question, and plenty of candidates answer it as one: they pick a strength in disguise and hope nobody notices. Interviewers notice. The question is much closer to a self-awareness test than a trap, and the candidates who do well treat it that way.
What the question is checking
An interviewer asking about weaknesses is trying to learn three things.
First, do you know where you’re less effective? Everyone has patterns that cost them or their team something. A candidate who can’t name one either hasn’t reflected or won’t say.
Second, do you act on what you know? Naming a weakness is half an answer. The other half is what you changed and whether it’s working.
Third, is this weakness a risk in this particular role? A slow writer might be fine on a team that rarely writes design docs and a real problem on a fully remote one.
Harvard’s career office calls these “negatively framed questions” and gives advice that fits engineering interviews well: be honest, take responsibility, and “focus on behaviors, not personality traits.” That last point is the one most answers miss.
Choosing a weakness that’s honest and survivable
Run your candidates through four filters.
- It’s real. You can name a specific time it caused a problem. If you can’t, it’s either not your weakness or not significant enough to discuss.
- It’s a behavior. “I wait too long to raise blockers” can be observed and changed. “I’m introverted” is a trait, and saying it invites the interviewer to fill in what that means for the job.
- It isn’t a core requirement. A backend engineer saying “I find debugging production issues hard” has named the job. “I tend to write the design doc after I’ve started building” is a real weakness that most teams can work with.
- You’re working on it. You have a mechanism, a habit or a tool you use, and some evidence from after you started.
Weaknesses that pass these filters for many engineers include escalating blockers late, polishing work too long before sharing a draft, accepting more review requests than you can handle, going quiet in large meetings, or under-documenting decisions for colleagues in other time zones. Only use one if it’s true of you.
Answers that backfire
The humblebrag (“I’m a perfectionist”, “I work too hard”) is the most common and the least effective. The interviewer hears an evasion, and worse, they’ve learned nothing they can score.
“I can’t think of one” reads as a lack of self-awareness, even when it’s nerves.
The fatal flaw is the opposite mistake: so candid that it disqualifies you. Honesty doesn’t require choosing the weakness most relevant to the job.
A fixed-long-ago weakness (“I used to be bad at Git”) sidesteps the question. If you use something mostly resolved, say what’s still hard about it.
Worked example: raising blockers too late
A good answer has four beats: what the weakness is, a time it cost something, what you changed, and the evidence plus what remains. Here’s the same weakness answered twice.
Weak version (illustrative):
I’d say I’m a bit of a perfectionist. I sometimes spend too long making my code perfect, but I’m learning to let go and ship things faster.
It’s a strength dressed as a weakness, with no example, no cost and no mechanism. The interviewer can’t evaluate any of it.
Stronger version (illustrative; use it as a pattern, not a script):
I used to wait too long before raising blockers. If I was stuck, I’d try to solve it alone for two or three days, partly because asking felt like admitting I couldn’t do it. On one integration, that meant the team found out late in a sprint that the partner’s API didn’t support the batch endpoint we’d designed around, and we lost most of the sprint reworking it.
Since then I use a simple rule. If I’ve been stuck on the same problem for half a day, I post what I’ve tried in the team channel, and anything that threatens a date goes to my lead the same day. On my most recent project, that surfaced an authentication problem with a vendor on day two instead of week two. It still doesn’t come naturally, especially on a new team, so I keep the half-day check as a calendar reminder rather than trusting my judgment in the moment.
It names a behavior, gives one real cost, describes a mechanism simple enough to believe, offers evidence, and admits the habit isn’t fully automatic. That last sentence makes the answer more credible, not less.
How the answer changes with seniority
A junior engineer can reasonably name a skill gap (“I haven’t worked much with distributed tracing, so I’ve been instrumenting a side project with OpenTelemetry”), provided there’s a learning plan behind it.
For senior and staff roles, interviewers expect a weakness at the level of how you work with others and how you spend your time, because that’s where senior engineers succeed or fail. Examples that fit that level:
- Holding on to implementation work instead of handing it to someone who’d grow from it
- Waiting for consensus when a decision needed an owner
- Being blunter in code review than a less experienced author can absorb
- Starting to write things down only after a project gets complicated
A senior candidate who answers with “I’m still learning Kubernetes” can sound like they haven’t noticed their job changed. It isn’t wrong, it just answers a junior engineer’s version of the question.
Follow-ups to prepare
“How do you know it’s improving?” Point to something observable: a later project, a comment in a performance review, or a lead who said the early warnings helped. “I feel like I’m better” isn’t evidence.
“What would your last manager say your weakness is?” Your answer should be consistent with what a reference would say. If your manager would name something different, prepare that one as well, because reference checks do happen.
“Give me another one.” Have a second weakness ready that passes the same four filters.
“How would that show up here?” Answer honestly, then explain how your mechanism would carry over. For the blocker example: “On a team spread across time zones, a half-day delay costs more, so I’d post blockers in writing even sooner.”
Interview practice: a weakness for a senior role
You’re interviewing for a senior backend role that includes mentoring two junior engineers. Draft a weakness answer, then answer the follow-up: “What would your last manager say?”
Answer: what a strong response looks like
Start with the filters. A senior role with mentoring makes “I’m impatient with juniors” risky, because it hits a core requirement, while “I hold on to interesting implementation work” is relevant and survivable. It shows you know the role is partly about growing others, and it names a real temptation.
A reasoned answer might run like this, adapted to your own history: describe a project where you wrote the tricky part yourself while a junior colleague handled routine tickets, explain what that cost (they didn’t grow, and you became the bottleneck for reviews), then describe the change, such as pairing on the first hard ticket and handing the next one over with a review checkpoint. Evidence could be that colleague later owning a component on their own.
For the manager follow-up, consistency matters more than polish. If your manager would say the same thing, say so and mention when they raised it. If they’d say something else, give that weakness honestly with its own mechanism. Interviewers trust a candidate whose self-assessment matches what others would report.
Keep preparing
- Behavioral and HR interview questions
- Behavioral and HR multiple-choice questions
- Behavioral Interviews: A Clear STAR Story
- Behavioral: Building a Career Growth Plan, on turning feedback into a plan
- Harvard Mignone Center: answering negatively framed questions