The senior engineer across the table has heard “I’m a perfectionist” so many times that it now works against you: you either don’t know your own gaps or you won’t say them out loud, and both are worse than whatever real weakness you were covering. The question sounds like a trap, and the old advice to disguise a strength as a flaw is exactly what turns it into one.
What the interviewer wants is narrow and specific. Can you look at your own work and name where it falls short, and have you done anything about it. That’s the whole test. A weakness with no repair story reads as stagnation. A polished non-answer reads as someone who’ll get defensive the first time a code review goes sideways.
What the question is really scoring
Two signals, and they’re independent. The first is calibration: whether your view of yourself matches how a manager would describe you after six months. Someone who says their weakness is “caring too much about quality” has failed the calibration check before finishing the sentence, because no manager writes that in a review. The second is your feedback loop. Weaknesses aren’t disqualifying; a broken relationship with feedback is. The interviewer is trying to predict what happens the first time they tell you your design doc is wrong.
On an engineering loop this usually comes from the hiring manager or a senior IC, often near the end of a behavioral round, sometimes right after “tell me about a conflict with a coworker.” They’re not grading your vocabulary. They’re building a small model of how you behave when the work gets hard and someone points at your mistake.
The answers that get you quietly dinged
The disguised strength (“I work too hard,” “I hold myself to impossibly high standards”) is the most common and the most transparent. Interviewers have a name for it and they file you under coached-but-not-self-aware. The blank non-answer (“I can’t really think of one”) is worse, because now you look either evasive or unable to reflect on your own work at all. Then there’s the confession that torpedoes the role: telling a team lead you dislike collaborating, or telling an on-call-heavy team that you freeze under pressure. The point isn’t to be maximally candid. A weakness that sinks the role helps no one, and least of all you.
Pick a weakness that’s real and off to the side
The safe zone is a genuine weakness that sits to the side of the job’s center, that you can improve, and that you’re already visibly improving. The “to the side” part is what people skip. If you’re interviewing for a backend role, a weak spot in design mockups is fine; a weak spot in reasoning about concurrency is not, because that is the job. Match the flaw to the edges of the role.
The improvement half matters more than the weakness itself. “I used to do X, here’s what I changed, here’s where I am now” is the shape that lands, because it demonstrates the exact loop the question checks for. Skip it and even a well-chosen weakness sounds like a complaint.
Weaknesses that work for engineers, with the framing that sells them
A few that hold up in real loops, and what a manager actually hears when you say them.
| Weakness you name | How a manager hears it | What turns it into a pass |
|---|---|---|
| “I’m a perfectionist” / “I work too hard” | Coached non-answer, zero self-awareness | Nothing. Drop it entirely. |
| “I can’t think of one” | Evasive or genuinely unreflective | Nothing. Drop it entirely. |
| “I go too deep in code review and slow PRs down” | Real, and shows judgment about tradeoffs | Say how you fixed it: you now separate blocking issues from nits and label which is which |
| “I stay heads-down and under-communicate progress” | Common, coachable, low risk for most ICs | Point to the habit you built: written status updates, opening draft PRs earlier |
| “I avoided presenting my work to a room” | A real growth edge, not role-critical | Evidence: a brown-bag you ran, an RFC you walked the team through |
| “I’m optimistic on estimates” | Relatable, slightly risky if unmanaged | Show the mechanism: you break tasks down, pad deliberately, and track your own miss rate |
| “I try to own too much instead of delegating” | Strong signal for senior and lead candidates | Frame it as something you’re unlearning as you mentor and hand off work |
Two of these are worth expanding, because they map to how engineers actually get in their own way. Going too deep in review is the perfectionist’s real, usable form: instead of claiming you love quality, you admit that early on you’d block a pull request over a variable name and forget the author just wanted to ship a fix. The under-communication one is almost universal among strong ICs who prefer to disappear into a problem and surface with a finished answer. Both are safe precisely because they’re common and because the fix is concrete and checkable.
The follow-up is the real question
Whatever you name, expect “and what are you doing about it?” or “give me an example.” Some interviewers skip straight to the example and treat your first answer as a warm-up. This is where the disguised-strength answers fall apart, because there’s no real example to give. Prepare the story, not the label. One concrete instance with a before and after beats three abstract weaknesses.
“Early on I’d treat any review comment as a reason to rewrite the whole change, which slowed everything down and annoyed people who just wanted a one-line fix. So I started splitting blocking feedback from preferences, and I ask the reviewer which one it is when that isn’t obvious. My changes merge faster now and I argue about style a lot less.”
Notice what that does. It names a real behavior, shows the cost, describes a specific change, and points at an outcome. No hedging, no thesaurus. A hiring manager can picture working with that person, which is the entire point of asking.
New grad versus senior, and the hostile version
If you’re early-career, lean on technical or process gaps you’re actively closing: a language you’re still slow in, testing habits you’re building, getting comfortable reading a large unfamiliar codebase. Nobody expects a new grad to be strong everywhere, so the bar is mostly “do you know what you don’t know yet.” For senior and staff candidates, the interesting weaknesses shift toward scope and people: delegating, letting go of the implementation, saying no, managing up. A staff engineer whose only admitted weakness is a rusty framework hasn’t thought hard enough about the leadership half of the job, and a sharp interviewer will notice.
Occasionally you’ll draw the interviewer who pushes back: “that’s not really a weakness” or “give me another one.” Don’t panic and don’t retreat into a worse answer to fill the silence. Keep a second real weakness in your pocket, and read the pressure as part of the test, because it is. Staying calm and specific under a follow-up you didn’t rehearse is itself the signal they’re fishing for.
The candidates who do best here treat the question like a bug report about themselves: acknowledge it, show the fix, move on. The ones who struggle are still trying to win the question. You don’t win it. You use it to prove you can hear something uncomfortable and respond like a professional, which happens to be the thing the job will ask of you every week.
Practice the behavioral round:
