Skip to main content

How to Answer "What Is Your Greatest Weakness?" in a Tech Interview

Choose an honest weakness, explain its impact, and show credible progress. Includes a worked data-engineer answer and follow-up questions that test the evidence.

By Vikas D11 min readUpdated 8 October 2026

Software engineer with ~6 years experience, primarily JavaScript and Node, London

Connect on LinkedIn
interviewsbehavioral interviewsinterview questions
On this page

Answer the greatest-weakness question with one real work habit, the cost it caused, and a specific change you have already practiced. Explain what has improved and what still needs attention, without presenting a development area as either a hidden superpower or a permanent character flaw.

Short answer: Choose a weakness you can discuss honestly under follow-up questions. Give one brief example, describe your corrective habit, and support your progress with a recent observation. Aim for about a minute as a rehearsal target, then let the interviewer ask for detail. A polished claim of being completely fixed is less useful than a precise account of how you manage the difficulty now.

Start with feedback you can recognize

Do not begin by searching for a list of impressive weaknesses. Begin with a moment when your approach made work harder for someone else. A review comment, a delayed handoff, or a teammate's request for clearer updates can give you something concrete to examine. You need a behavior you recognize, not an accusation you repeat because someone senior said it.

Write down the event before choosing a label. "My colleague could not continue because I had not shared my assumptions" is more useful preparation than "communication." The event tells you what you did, who experienced the consequence, and where a correction could have helped. A broad label leaves all three questions unanswered.

Use these prompts to build a private shortlist:

  • What feedback have I heard more than once?
  • When did someone need to chase me for information?
  • What task do I postpone even when I know it matters?
  • Which corrective habit have I actually used recently?

An answer should reflect your experience. Tulane Career Services' discussion of the weakness question encourages candidates to start with a real difficulty, describe actions, and explain progress instead of copying a script. Treat that as a preparation principle, not a promise about how any particular interviewer will respond.

You may find several plausible topics. Keep their factual details separate. Combining one person's feedback, another project's consequence, and a third project's result into a single incident creates a cleaner story at the expense of accuracy. If your progress spans several projects, say so explicitly.

Check the job requirement before choosing the story

There is no weakness that is automatically safe for every software or data role. Delaying a request for help can affect delivery, collaboration, and reliability. Calling it a minor communication habit does not remove those consequences. Read the actual responsibilities and consider what the example would reveal about your readiness for them.

This is a fit check, not an instruction to hide a missing essential qualification. If the interviewer asks directly about an ability you lack, answer directly. When you have a choice of several true development areas, choose one you can explain with enough context and evidence to give a fair picture of your current work.

Question to ask yourselfWhat a useful answer needs
Does this affect a central responsibility?Evidence of present capability and any remaining limits, not a reassuring label
Was the behavior isolated or repeated?An accurate description of frequency rather than "always" or "never"
What could a colleague observe changing?A visible action, such as an earlier update or a clearer handoff
Have I tested the change under pressure?A relevant recent example, or an honest statement that the evidence is limited
Does the story depend on confidential details?Enough generalized context to explain your contribution without exposing private information

For example, a role requiring independent production incident leadership makes late escalation especially consequential. An answer about that behavior needs to address current incident procedures and demonstrated judgment. A personal time limit for ordinary debugging cannot substitute for the team's response requirements.

Avoid turning this assessment into a numeric score. There is no reliable formula in which three reassuring attributes cancel out one essential capability gap. The point is to identify the question a hiring manager would reasonably ask next and decide whether you can answer it truthfully.

Nadia's answer: keep the behavior, remove the unsupported rescue story

The following is a hypothetical teaching example, not a report about a real employee or employer. Nadia is a data engineer preparing to explain her tendency to investigate alone for too long. Her example concerns a development ingestion task using test data, not a production outage.

During the task, a row-count check failed. Nadia spent 90 minutes inspecting her transformation code before sharing her notes. Once she asked, a colleague pointed out that an input column name had changed. The review was delayed while Nadia investigated. These details establish the cost of her behavior without requiring a claim about customer impact.

Her first draft is weak:

"I'm a perfectionist. I like solving things myself, but now I ask for help earlier, so it has become a strength."

The problem is not the word "perfectionist" alone. The answer hides the actual behavior, omits its effect on the review, and declares a positive ending without evidence. Replacing the adjective while keeping those omissions would not improve it much.

Nadia rewrites her preparation notes around facts she could explain:

  • Behavior: She kept investigating after she stopped making progress.
  • Cost: A colleague could not complete the review while she remained blocked.
  • Change: For non-urgent development work, she now shares a short problem summary after 30 minutes without progress.
  • Observation: On the next two blocked tasks, she shared her notes within that limit.
  • Limit: Two examples show initial adherence, not proof that the habit will hold in every setting.

A spoken answer could be:

"I can stay with a blocked investigation too long before asking for another perspective. On a development ingestion task, I spent 90 minutes checking my code before sharing a failed row-count check. A colleague then spotted a changed input column, and I had delayed our review. For non-urgent work, I now set a 30-minute checkpoint: if I have no new evidence, I send the failing check, what I tried, and my next question. I used that checkpoint on my next two blocked tasks. It is still a habit I need to watch, but I am making the blockage visible earlier."

Notice the narrow conclusion. Nadia says she shared information earlier. She does not say that the new habit reduced resolution time by a particular percentage. Different problems can take different amounts of time, and the example does not establish how long either later task would have taken without the change.

The checkpoint also has a defined scope. It applies to non-urgent development work. If a production incident requires immediate notification, Nadia follows that process immediately. A development habit should never be described as a universal waiting period before asking for help.

Let the interviewer test the correction

A useful preparation exercise is to ask follow-up questions that expose gaps in your own story. Do this before you rehearse smoother wording. If the explanation collapses when someone asks what changed, the next step is better evidence, not better delivery.

Here is how Nadia's hypothetical discussion might continue:

Interviewer: "How do you know the checkpoint helped?"

Nadia: "I know I made the blockage visible earlier on two later tasks. I did not measure total time saved, so I would not claim that. The difference I can describe is when I shared my findings."

Interviewer: "Why did you wait so long in the first place?"

Nadia: "I thought asking before I had exhausted my own ideas would look unprepared. Writing down my evidence helped me distinguish a useful request from simply handing someone an unexplained problem."

Interviewer: "Would you wait 30 minutes during an incident?"

Nadia: "No. That checkpoint is for non-urgent development tasks. During an incident I would follow the team's notification and response process."

Interviewer: "What happens if you have made progress at the checkpoint?"

Nadia: "I decide what evidence I expect from the next step and when to check again. The aim is to notice when I am repeating the same investigation, not to interrupt every task at a fixed time."

These answers add distinctions instead of adding heroic results. The development task, the later observations, and the emergency exception remain consistent. That consistency makes the account easier to assess, even if the interviewer still wants more evidence of independent work.

The most credible improvement claim is the one you can explain without enlarging it when someone asks a follow-up question.

Choose evidence that matches the claim

A course, a checklist, and a better outcome are different kinds of evidence. Each can support an answer, but they support different conclusions. Taking a course shows that you took action. Applying its lessons in a relevant task says more about changed behavior. Neither automatically proves a permanent improvement.

If you struggle with concise explanations, for example, drafting shorter notes is an action. A colleague being able to identify the requested decision from those notes is an observation. Claiming that your communication problems are solved goes beyond both. Keep the scale of your conclusion close to the scale of what you observed.

Use a simple distinction when reviewing your answer:

Evidence availableClaim it can reasonably supportClaim to avoid
You started a corrective practiceYou have begun addressing the problemThe weakness has disappeared
You used it on two recent tasksYou have early evidence of changed behaviorIt works under all conditions
A colleague gave specific feedbackSomeone observed that particular changeEveryone now considers you strong in that area
You recorded comparable outcomes over timeYou can describe a measured pattern with contextYour action alone caused every improvement

You do not need a percentage to sound credible. A clear account of an observable change can be more useful than an impressive number with an unclear denominator. If you have no measurement, use the available evidence and acknowledge its limits. Never create a result because the answer feels unfinished without one.

If the correction is recent, explain how you intend to review it. That future check belongs at the end as a next step. It must not replace the action you have already taken or be presented as an outcome that has already happened.

Keep the answer proportionate without disguising the weakness

The temptation to say "I care too much" comes from trying to control the interviewer's judgment. It often removes the information they need to understand your work. A Forage article republished by Penn Career Services cautions against that kind of disguised boast and recommends discussing a real weakness and your work on it.

A useful middle ground is specific, bounded language. "I sometimes send technical detail before stating the decision I need" gives the listener something concrete. "I am terrible at communication" makes a broad claim about your abilities. "My communication is too thorough" tries to turn the same issue into praise. Neither extreme helps explain the actual behavior.

Before rehearsing, remove three kinds of distraction:

  • Excuses: Explain the circumstances without making a colleague responsible for your choice.
  • Extra weaknesses: Answer the question asked rather than volunteering an inventory of unrelated shortcomings.
  • Claims about the interviewer: Do not say that every hiring manager wants the same answer or uses the same scoring criteria.

Penn Career Services notes in its strengths and weaknesses interview session description that students in mock interviews can be more comfortable listing weaknesses than highlighting strengths. That is a useful reminder to keep this one answer in proportion to the whole conversation. You still need to explain what you can contribute.

Rehearse aloud once with a timer, then ask a practice partner to summarize the weakness and the correction. If they remember only the background story, shorten the setup. If they remember only that you made a mistake, make the corrective action clearer. If they cannot identify any remaining limitation, check that you have not promised a complete cure you cannot support.

Questions candidates ask about the weakness answer

Must it literally be my single greatest weakness?

You do not need to rank every personal limitation. Choose a meaningful professional development area that answers the question honestly. If the interviewer narrows the question to a particular responsibility or asks about a known gap, address that directly instead of switching to your prepared topic.

Can I mention a technical skill I am still learning?

Yes, when it is a real and relevant development area. Explain what you can currently do, where you still need help, and what practice you have completed. Do not describe an essential skill as mastered because you finished a tutorial, or use an unrelated tool gap to avoid discussing the responsibility the interviewer asked about.

Is perfectionism always a bad answer?

The label is usually too vague on its own. If the real issue is spending too long refining low-impact details, name that behavior and its cost. Explain how you now decide when the work is sufficient. Do not end by claiming that the weakness simply proves your high standards.

What if I have only just started improving?

Say that. Describe the action already taken and the limited evidence you have so far. You can explain how you will check progress, but distinguish that plan from a result. If another genuine development area has stronger recent evidence, it may be easier to discuss accurately.

What can I use without full-time work experience?

A course project, volunteer responsibility, internship, or part-time job can supply a relevant example. Identify the setting clearly and explain your own contribution. Do not inflate a student project into a commercial engagement. The useful detail is what you noticed and changed, not the prestige of the setting.

What if they ask for three weaknesses?

Prepare a few distinct development areas so you can respond to that request. Give a brief correction for each and offer detail where the interviewer wants it. Avoid splitting one issue into three near-identical labels, or inventing a third weakness while under pressure just to complete the list.

Should I say the weakness is fixed?

Only if that description is accurate, and explain the evidence. Often it is more precise to say that a behavior is better managed through a habit you still use. If the question concerns a current weakness, relying entirely on a problem from years ago may leave the present-day question unanswered.

Prepare the evidence around your answer

Practise these patterns on AlgoExpert
Recommended
200+ video-explained coding interview questions organised by the patterns covered on this page, with timed practice and solution walkthroughs.
Start practising

An external resource we recommend. AlgoExpert is not affiliated with us and we earn nothing from this link.

Continue your prep

Pair this guide with role-specific question sets and sample answer outlines.