How to Answer “What Is Your Greatest Weakness?”
Learn why the “What is your greatest weakness?” question matters, how to craft genuine STAR-based answers, and practical tips for tech professionals to prepare strong examples from work experience.
Most candidates either dodge this question or confess something that tanks them. Both are mistakes.
This question isn’t a trap. It’s a check on self-awareness. Hiring managers want to know: can you see yourself clearly? And when you find a gap, do you do something about it?
Pick the Right Weakness
Choose something real. Not a core skill for the role. Not “I work too hard.”
Good targets: delegation, cross-functional communication, a specific technical area outside your main stack, time estimation, public speaking.
Bad targets: anything the job actually requires, anything you’re not actively improving, or anything framed as secretly a strength.
Structure Your Answer
Use STAR: Situation, Task, Action, Result. The action and result carry the most weight.
The formula:
Name the weakness directly
Give a brief situation where it showed up
Describe what you did about it
Share the measurable outcome
Keep it under two minutes.
Three Real Examples
Limited OAuth experience (early-career engineer)
I was integrating a third-party auth service with no background in OAuth. I enrolled in an online course, paired with a senior engineer, and built a small proof-of-concept to test edge cases before touching production. Integration shipped on schedule with zero security incidents. I now own auth decisions on my team.
Delegation (first-time tech lead)
As a new team lead, I was doing too much myself instead of trusting the team. I set up a testing framework workshop, documented clear test plans, and started daily check-ins to unblock people without taking over their work. The beta shipped two days early, test coverage went up 30%, and junior devs reported stronger confidence in the QA process.
Cross-functional communication (mid-level engineer)
Frontend and backend kept misaligning on API specs. I kept avoiding the difficult conversations about ownership. To fix it, I introduced a shared API-spec Slack channel and biweekly syncs with a standing agenda. API bugs dropped 50%. Deployment frequency increased 20%.
What to Avoid
Don’t say you’re a perfectionist unless you can back it with a real story. Don’t pick something trivially unrelated to the role. Don’t trail off without a result.
The goal isn’t confession. It’s proof that you know yourself and act on what you find.