Guides

How to Answer \"What Are Your Weaknesses?\" Without Sounding Fake

How to answer "What is your greatest weakness?" with real (not fake) examples — the 3-part formula, 10 sample answers, and what hiring managers actually want.

Practical guideInformational13 min read
How to Answer \"What Are Your Weaknesses?\" Without Sounding Fake

The worst answer to "What's your greatest weakness?" is "I'm a perfectionist." Interviewers have heard it hundreds of times. Same with "I work too hard" and "I'm too detail-oriented." These aren't weaknesses dressed up as strengths — they're red flags that signal you're avoiding the question.

The interviewer isn't trying to catch you out. They're checking three things:

  1. Self-awareness. Can you accurately see where you fall short?
  2. Maturity. Can you talk about a real flaw without sounding defensive or making excuses?
  3. Growth orientation. Are you actively working on it, or is it a fixed limitation?

A good answer hits all three in 45-60 seconds. The structure that works:

  1. Name a real weakness that's plausibly true and won't disqualify you from the role.
  2. Give one specific example of when it created a problem.
  3. Describe the concrete action you've taken to work on it, with results if you have them.

That's it. Below: the formula, the categories of weakness that work (and the ones that don't), and 10 sample answers you can adapt to your real background.

The 3-part formula

Part 1: Name a real weakness

The weakness has to be (a) actually a weakness, (b) not a deal-breaker for the role, and (c) believable. Three quick filters:

  • Would I admit this to a former colleague? If yes, it's real.
  • Would it disqualify me from this specific job? A weakness in public speaking is fine for a backend engineer; it's a real problem for a sales role.
  • Is it a skill or behavior, not a personality trait? "I struggle to delegate" can be improved. "I'm shy" sounds fixed.

Categories that almost always work:

  • A specific skill gap — public speaking, financial modeling, technical writing, a specific tool.
  • A bias toward one mode of working — preferring deep work over shallow work, preferring async over real-time, preferring structure over ambiguity.
  • A management or collaboration style issue — struggling to delegate, slow at giving direct feedback, prone to over-engineering before talking to users.
  • A communication blind spot — under-communicating progress, over-communicating to the wrong audience, defaulting to written when verbal would land better.

Categories that don't work:

  • "Perfectionist," "workaholic," "too detail-oriented" — these read as fake.
  • Anything core to the role (a backend engineer saying "I'm not great at coding," a CSM saying "I have trouble with customers").
  • Personality framings ("I'm introverted," "I have anxiety") — too personal, hard to act on.
  • Generic moral failings ("I'm too honest," "I'm too caring") — sound like deflection.

Part 2: Give a specific example

Generic "this is something I struggle with" answers don't land. You need one concrete moment when this weakness created a problem.

The example should be:

  • Recent enough to be relevant (last 1-2 years)
  • Specific (a project, a meeting, a decision)
  • Honest about the consequence

Example: *"At my last company, I led a project to migrate our auth system. I spent the first three weeks building the technical design without talking to the customer success team about how it would change their workflows. When I finally circulated the proposal, half of the edge cases I'd missed were ones CS would have flagged in week one. The project shipped six weeks later than it needed to because I had to redesign the data model after the fact."*

This is what self-awareness sounds like. The interviewer now believes you actually know your weakness because you can describe what it cost.

Part 3: What you've done about it

Show the work. The "growth" part of the answer is the part that proves you're not stuck with this weakness — you're actively shrinking it.

Examples of credible "what I've done":

  • "Now I run any non-trivial design through a peer review with people in adjacent functions before I scope the work."
  • "I've made it a personal rule to give one piece of direct feedback per 1:1 with each report — I track it in my notes."
  • "I joined a Toastmasters group six months ago and have given five practice talks since."
  • "I now write a Friday update every week with a 'what I'm worried about' section that forces me to surface ambiguous problems earlier."

The key: be specific about the *intervention*, not just the intent. "I'm working on it" isn't an answer. "Every Monday I do X" is.

If you have measurable results — even small ones — include them. *"Since I started doing this, the last three projects all shipped on schedule."*

10 sample answers across roles

1. Software engineer

> *"My biggest weakness is that I default to over-engineering. I'll spend a week designing a system to handle edge cases that won't show up for two years instead of shipping the simple version and iterating. The clearest example was a project at [Previous Co.] where I designed an event-driven system for a feature that ended up serving 100 requests a day — a single Postgres table would have been fine. What I've changed: now I write a one-page spec before I touch code that explicitly answers 'what's the simplest thing that would work for the next 6 months?' If I can't justify why the simple version won't work, I default to the simple version. The last four projects I've led shipped within the original estimate."*

2. Product manager

> *"I move to solutions too fast. Early in a problem space I'll jump to a proposed roadmap before I've done enough customer research, which tends to anchor the team on a direction that doesn't always survive contact with users. On the last big project at [Previous Co.], I proposed a solution after two customer interviews; we got eight weeks into building before research came back with feedback that pointed to a different problem. What I've changed: I now make a rule that I don't write a PRD until I've done at least 10 customer conversations, and I run my first hypothesis past research before I socialize it with engineering. Slower start, but the last two projects have shipped without major direction changes."*

3. Manager (first-line)

> *"I'm slow to give critical feedback. I'll let small things slide for weeks before raising them, and by the time I bring it up, the report is surprised because they had no signal something was off. The clearest example: I let a performance concern with a direct report go unaddressed for two months, and when I finally raised it in their review, they were blindsided. What I've changed: I built in a 'one piece of direct feedback per 1:1' rule for myself, and I track it in my notes. The feedback doesn't have to be big — it just has to be regular enough that nothing piles up. My most recent 1:1s have ratings have gone up across the team."*

4. Designer

> *"I'm slow to share work in progress. I want a design to be 80% polished before I show it, which means engineering and PM see ideas later than is useful, and we sometimes find out late that the technical constraints rule out the direction I was going. The example I think of: a project last year where I sat with a design for two weeks before showing engineering, and the data model they'd already started building made my approach impossible to ship. What I've done: I now share rough designs by end of day two of any project, even if they're embarrassing. The feedback loop is faster and engineering has flagged constraints earlier on the last three projects."*

5. Sales

> *"I lean toward over-discounting in late-stage deals. When a customer pushes on price near close, I want the deal to land and I'll concede more than I should. At [Previous Co.] I closed a $200K deal where I gave a 25% discount that, in hindsight, the customer would have signed at 10%. I left $30K on the table. What I've changed: I now bring my manager into any pricing concession over 15% before I make it, and I rehearse the no-discount close with my manager before late-stage calls. My average discount has dropped from 18% to 11% over the last six months."*

6. Marketing

> *"I tend to under-invest in measurement. I'll launch a campaign and not set up the attribution properly until two weeks in, which means I lose the early signal. On a big lifecycle email project last quarter, I launched without proper UTM tagging on the variations, and we couldn't tell which variant drove the result. What I've done: I now have a campaign-launch checklist that won't let me ship without the measurement layer ready. The next two campaigns I launched had clean attribution from day one."*

7. Customer success

> *"I'm slower than I should be at flagging churn risk to the account team. I'll see signal three or four weeks before I raise it, because I want to be sure before I create noise. The result is that by the time I escalate, there's less runway to save the account. The example: an account I lost last quarter where the buyer's executive sponsor had left two months earlier and I didn't loop in sales until renewal was 30 days out. What I've changed: I now have a weekly churn-signal review where I share anything I'm watching with the account team — they can sort the noise from the real risk. Two at-risk accounts in the last quarter have already been saved through earlier intervention."*

8. Engineer (career switcher)

> *"I'm still building muscle on system design at scale. My background is in early-stage startup engineering where the systems I built peaked at modest volume — I've had to learn the patterns for distributed systems without on-the-job experience. What I've done: I'm two months into Designing Data-Intensive Applications, I shadowed a senior engineer on the last two architecture reviews at my current company, and I've started owning the design doc for a service that handles 10x the volume of anything I've built before. Three months ago I couldn't have written that doc; now I can defend it in review. I'm aware this is the area where I'm growing fastest right now."*

9. New manager

> *"I'm still calibrating how much to delegate. I've spent eight years as an IC and I default to solving problems myself when delegating would be the better call. The clearest recent example: I rewrote a junior engineer's PR myself instead of leaving feedback and giving them the rep. What I've done: I now write down at the start of each week one thing I'd normally do myself that I'm going to delegate. It's deliberate, awkward, and the right move long-term. In the last six weeks I've delegated three things I would have done myself a quarter ago."*

10. Recent grad

> *"I'm not very experienced at working through ambiguity. School and internships gave me well-defined problems — I'm great when I know the answer is achievable. I've struggled when the problem itself is unclear. The example I think of: a senior project where the requirements changed mid-semester and I spent two weeks trying to clarify them instead of just picking a direction and iterating. What I've started doing: I now make myself write a one-paragraph framing of any new problem before I start working on it, even if I have to guess. Doing that explicitly forces me to commit to a direction earlier and adjust from there."*

Specific situations

When you're applying for your first job

A skill gap is the most honest answer. "I haven't yet worked in [specific environment]" is fine. The action part of the answer should describe what you've done to bridge it — coursework, side projects, internships, certifications.

When you're switching careers

Frame the weakness as something you're actively bridging through the transition. Don't apologize for it; show the work you're doing.

When you've been at the same company for a long time

A common weakness for long-tenured candidates: limited exposure to how other companies operate. Don't claim it as a flaw; name it specifically and describe what you've done (industry reading, networking, conference attendance) to bridge it.

When the interviewer pushes for a "real" weakness

If they push, take it as a sign they want depth, not deflection. Have a second weakness ready that's slightly more uncomfortable to share — something you genuinely struggle with. The willingness to go to the harder answer is itself the signal they're testing for.

Weaknesses to never use

A short blacklist:

  • "I'm a perfectionist." Read as fake by every interviewer.
  • "I work too hard." Same.
  • "I'm too honest." Reads as deflection.
  • "I care too much." Filler.
  • "I struggle with [thing core to the role]." Disqualifying.
  • "I have ADHD / anxiety / depression." Even if true, too personal and harder to handle in a hiring context. If you want to discuss accommodations, save it for after the offer.
  • "I'm bad at office politics." Reads as either naive or as a signal you'll be hard to work with.
  • "I don't have any weaknesses." Worse than perfectionist.

The honest framing that works

The candidates who consistently nail this question share one trait: they treat it as a chance to demonstrate self-awareness, not a chance to trick the interviewer. They name a real weakness, show what it cost, and prove they're working on it.

The interviewer leaves the conversation thinking "this person knows themselves and is actively getting better." That's a much stronger signal than any of the canned answers.

A related move: prep for the interviewer specifically

The "what's your weakness" question lands harder when you know what the team actually values. A weakness that reads as a deal-breaker on one team is irrelevant on another. The candidates who consistently ace this question are usually the ones who've talked to someone inside the company before the formal interview.

If you don't have a contact, finding the actual hiring manager or a teammate directly is the highest-leverage move. From there, a personalized note asking for a 15-minute call typically gets a reply rate of 40-60% — and the call itself gives you the context to pick the right weakness to share. The same prep also makes other common interview questions land more sharply.

FAQ

What's the best way to answer "What is your greatest weakness?"

Use a three-part structure: name a real weakness, give a specific example of when it created a problem, and describe the concrete action you've taken to work on it. Aim for 45-60 seconds.

What are good examples of weaknesses to share?

A specific skill gap (public speaking, financial modeling), a working-style bias (over-engineering, slow to delegate, leaping to solutions), or a collaboration blind spot (under-communicating progress, slow at feedback). Anything specific, recent, and actionable works.

What weaknesses should I avoid mentioning?

Avoid "perfectionist," "workaholic," "too detail-oriented," anything core to the role you're interviewing for, and personal mental-health framings. Also avoid claiming you have no weaknesses.

Should I share a real weakness or a strategic one?

Both — pick a real weakness that's strategically safe (doesn't disqualify you from the role). Faking a weakness reads as fake; sharing one that disqualifies you is self-sabotage.

How long should my answer be?

45-60 seconds. Short enough to stay focused; long enough to include the example and the action you've taken.

What if the interviewer pushes for a "real" weakness?

Have a second, slightly more uncomfortable weakness ready. The willingness to share the harder answer is itself the signal they're testing for.

Is it OK to say "I don't know"?

No. "Tell me about a weakness" is one of the most predictable interview questions; an unprepared answer signals the rest of the interview will be the same. Always have a real, prepared answer.

Keep reading

More from Guides

Resources