“What are your weaknesses?” How to answer in a tech…

The weaknesses question usually comes paired with strengths, near the end of a screening call or in the final round. The Sobes question bank has it the way it sounds in real life: "What are your strengths and weaknesses (soft skills)? What are you trying to improve?", "Name your strengths and weaknesses". The first version has been opened more than 3,000 times: plenty of people prepare for it, even though it is asked less often than salary or the reason for leaving.

Everyone knows the stock answer from the internet: "I'm a perfectionist" or "I work too much". The interviewer knows it too and has heard it four times this week. After that answer they either leave the field in their notes empty or ask again: "Okay, what else?" And that is where the script runs out.

What they are actually checking

The interviewer doesn't need a list of your flaws. They look at three things:

Whether you can see yourself from the outside. Someone who can't name a single weakness usually can't see problems in their own code or estimates either.
What you do about it. A weakness that is being worked on is fine for a manager. A weakness they discover three months into the project is not.
Whether it is critical for the role. An analyst who dislikes talking to stakeholders and a developer who dislikes conference talks will be scored differently for a similar answer.

The second half of the question as it appears in the bank, "what are you trying to improve", tells you what is expected: a plan, not a confession.

Why "perfectionist" doesn't work

It is a strength dressed up as a flaw, and it shows. The answer gives the interviewer no information and also signals that you dodged the question. If perfectionism really gets in your way, say how: "I drag out code reviews because I nitpick." That is a real weakness, and it fits the formula below.

The formula

Three parts, about forty seconds:

A real weakness, named specifically. Behavior is better than a character trait: "I underestimate deadlines", not "I'm an optimist".
What you do about it. A technique, a habit, an agreement with the team.
How it shows up now. Honestly: better, but not gone.

The third part is what separates a real answer from a memorized one. A weakness you have "completely overcome" sounds as fake as perfectionism.

Five examples

Estimating deadlines

I consistently underestimate. I give the deadline for the case where everything goes smoothly, and it never does. Now I break a task into pieces of a day or less and add a third on top of the sum. I still miss, but by a day or two instead of a week, and I warn people early, not on the due date.

It works because every manager knows the problem, and the technique is specific and checkable.

Public speaking

I find it hard to speak in front of a big audience: at a demo for forty people I start rushing. To get used to it, I took over our team's internal demos every two weeks, and I run through the talk out loud before each one. In front of my own team I'm calm now. In front of the whole company I'm still nervous, but I do it.

For a developer this weakness is not critical, and willingness to practice something unpleasant looks good.

Delegating

It's easier for me to do something myself than to explain it. When I started leading a team of four, that quickly became a problem: I was the bottleneck. Now, if a task takes me two hours and a teammate a day, I deliberately give it to the teammate and only look at the result in review. My hands still reach for the keyboard, especially when a deadline is on fire.

This is an answer for a team lead or a senior moving toward management. More on what those interviews expect is in the article on the team lead interview.

Depth versus speed

I like digging to the root cause, and I can spend half a day on something that doesn't affect the task. Now I set a limit: one hour of investigation, then I post what I found in the chat and ask whether it's worth digging further. Half the time the answer is no.

The reverse version is just as honest: "I work fast and sometimes miss edge cases, so before sending code to review I go through my own checklist."

Documentation

I'm bad at documenting. I close the task, the explanation stays in my head, and six months later colleagues come with questions. I agreed with the team that we don't merge without a short description in the ticket. For my own tasks I keep the rule. Big architecture docs I still write late.

A rule you agreed on with the team is stronger than a promise to "try to do better".

What not to name

A weakness the role can't survive. A tester who is "inattentive to details" or an analyst who "finds it hard to talk to people" has withdrawn their own application.
Traits that read as being hard to work with: "I can't stand stupid people", "I say everything to people's faces".
Other people's flaws presented as yours: "I expect too much from colleagues".
A technical gap in the vacancy's stack. That is a different kind of weakness, and the technical round will find it anyway. But "in Kubernetes I'm a user, not an administrator" fits fine as an answer to what you want to improve.
Nothing. "I don't know, I don't think I have weaknesses" is worse than any example above.

If they ask "what else?"

Prepare two weaknesses, not one. The second can be shorter: name it, say what you do. And be ready for "give me the last time it got in the way". If there is no such time, the weakness is invented, and people can hear that. Stories about those moments are built the same way as a story about a mistake, which is covered in the article on conflict and failure questions.

How to prepare your answer

Open your recent retros, code reviews, or manager feedback and write down what you were told more than once. That is your material, and nothing has to be made up. If you used Sobes Copilot in interviews, look at the Progress screen: it shows the topics rated as weak in two or more interview reviews.

Pick two weaknesses, write three sentences for each using the formula, and say them out loud. Then test them in conversation: run an HR-mode mock interview and give this answer in the same session as your "tell me about yourself". It helps when the two don't contradict each other.