What are you trying to improve most (professionally)
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers ask this to see whether you have honest self-awareness, a meaningful growth edge, and a credible plan for getting better. They are usually not looking for a polished weakness; they want evidence that you can identify the next constraint on your effectiveness and work on it deliberately. At higher levels, they also want to see whether the improvement area matches the scope of the role you are pursuing.
Key Insights
- You do not need to pick a dramatic flaw, but you do need to pick something real. A fake weakness or an over-packaged strength-in-disguise usually signals low self-awareness.
- The strongest answers show an active improvement loop: how you identified the issue, what you changed, how you are measuring progress, and what is still unfinished.
- You should choose an improvement area that is appropriate for your level. A senior or staff candidate focusing only on a narrow coding habit can sound like they are not thinking at the level the role requires.
What interviewers probe atlevel
Top Priority
Pick a genuine skill gap that matters for doing your job better, not a personality quirk or a disguised strength.
Good examples
🟢I'm working on getting better at breaking down ambiguous tickets instead of waiting until I'm fully stuck before asking for help.
🟢I'm trying to improve my debugging process so I can isolate issues more systematically rather than trying fixes one by one.
Bad examples
🔴I'm trying to improve caring less about quality because I can be too detail-oriented sometimes.
🔴The main thing I'm improving is learning every framework faster, because right now I just need more exposure.
Weak answers pick something performative or too broad to act on; strong answers identify a concrete job-relevant limitation the candidate can actually work on.
Valuable
Example answers atlevel
Great answers
One thing I'm actively trying to improve is how I work through ambiguity before asking for help. Early on, I would either ask too quickly or spend too long stuck because I wasn't sure what counted as enough independent effort. I started keeping a short note of what I tried, what I observed, and what I think the next likely cause is before I reach out. That has made my questions much more specific, and my mentor has told me it's easier to help me now because I come with clearer context. I'm definitely still working on it, but I feel like I'm getting better at making progress on my own without disappearing into a rabbit hole.
Right now I'm focused on getting better at writing maintainable, well-tested code so the next person (or future me) isn't blocked by unclear components. On my last couple of tickets I made it a rule to add at least one unit test and a short README for the module before I consider the work done, and I ask a teammate to skim the README during code review. That practice has already cut down on follow-up bug fixes and made reviews quicker, because reviewers can run the tests and understand the intent faster. I'm still learning how to choose the most important edge cases to cover and how to balance test time with shipping, but I prioritize coverage for logic that historically caused regressions.
Poor answers
Professionally, I'm trying to improve perfectionism. I care a lot about doing things well, so sometimes I spend extra time making sure everything is polished. I've been trying to remind myself to move a little faster, but overall I think it's a good problem to have because it means I take quality seriously. In general I just want to keep getting better at everything as I gain experience.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late June, 2026
Late June, 2026
Early January, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.