How to Answer 'What's Your Greatest Weakness?' in an Interview

How do you answer "what's your greatest weakness?" in an interview?

Pick a real weakness that doesn't disqualify you for the role, then walk through the concrete action you're taking on it. The structure is: name the weakness honestly → describe the cost it's had → show what you're doing about it → end with one piece of evidence the work is paying off. Avoid fake weaknesses ("I work too hard") and avoid weaknesses central to the job you're applying for.

The 4-part structure

A strong weakness answer runs 45-75 seconds and has four beats.

Beat 1 — Name it (10 seconds). A specific, real weakness. "I tend to over-engineer first drafts when I should be shipping a rough version first." Specific beats abstract. "I'm not good with deadlines" is too vague to land.

Beat 2 — Cost it had (10-15 seconds). Name a real moment when this weakness cost you something. "Last semester I spent two weeks polishing a class project before getting feedback from anyone. By the time I shared it, I'd built two features the prof didn't want."

Beat 3 — What you're doing about it (15-25 seconds). Concrete, falsifiable action. "Since then, every project I start now has a 'demo by Wednesday' rule — I show somebody something rough by the end of week one. I've done it on six projects since January."

Beat 4 — Evidence it's working (10-15 seconds). One piece of proof. "On my most recent internship project, my first demo landed three days in, and the team caught a wrong assumption that would've cost me two weeks. The discipline is paying off."

Per the Harvard Business Review on weakness questions, interviewers rate this kind of self-aware-with-action answer significantly higher than either polished humble-brags or unstructured honest confessions.

Weaknesses that work for new grads

If you're a final-year student or recent grad, three weakness categories tend to land well, because they're real for early-career engineers and they map to skills you can clearly grow:

• "I sometimes over-engineer instead of shipping a rough version." Maps to product instinct, which mid-level engineers are still building.
• "I'm still learning when to ask for help versus working through it alone." Maps to collaboration and time management.
• "I default to writing code before I'm certain the design is right." Maps to design judgment, which everyone refines through the first few years on the job.

Each of these is real, none of them disqualifies you for an engineering role, and each can be paired with a concrete action plan.

Weaknesses to avoid for any role

Three categories of answers consistently bomb:

• The humble-brag ("I care too much", "I work too hard", "I'm a perfectionist"). Interviewers have heard these so many times they now read as evasion.
• The disqualifier for the role you're applying to. Don't admit weak debugging skills in a debugging-heavy role. Don't admit "I'm not great with ambiguity" if you're interviewing at an early-stage startup.
• The non-weakness ("I sometimes get frustrated when others don't work as hard as I do"). This is just disguised contempt for your peers and reads as a culture-fit red flag.

The Indeed Career Guide on weakness questions flags these three patterns as the most-common ways candidates lose otherwise-winnable interviews on this single question.

When the interviewer pushes for "another one"

Some interviewers will ask for a second weakness right after you nail the first. They're testing whether the first one was rehearsed. Have a second one ready, of equal honesty:

"Sure — a second one I've been working on is [different real weakness]. The action I've been taking on that is [different concrete action]."

The second answer doesn't need to be as polished. The fact that you have one at all tells the interviewer the first answer wasn't a memorized line.

About the author: Alex Chen is the founder of InterviewChamp.AI and writes about the modern tech interview from the inside — what changed, what works for new grads, and where the old playbook fails.