Search
⌘K

What are you trying to improve most (professionally)

Asked at:

Meta

Oracle


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.

  • What's the main area you're focused on developing professionally right now?

  • If you had to pick one thing you're trying to get better at in your career, what would it be?

  • What skill or behavior are you most intentionally working on at the moment?

  • Where do you think you still have the most room to grow professionally?

  • What's the next thing you're trying to level up in how you work?

Growth
Ownership
Leadership

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 at
level

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.

A good answer includes 2-3 specific actions you are taking now, not just an intention to improve.

Good examples

🟢I've started writing down what I've tried before asking for help, so I can ask a focused question and avoid either spinning or escalating too early.

🟢I'm using a simple debugging checklist and reviewing it with a teammate after incidents to see where my process broke down.

Bad examples

🔴I'm improving it by trying to be more mindful and just practicing when it comes up.

🔴I know it's important, so I've been focusing on it and paying more attention.

Weak answers describe hope; strong answers describe repeatable habits, structures, or feedback loops.

It is okay to be early in your growth, but you need to sound aware of your real patterns rather than polished for the sake of sounding good.

Good examples

🟢I noticed I sometimes ask for help either too early or too late, so I'm working on recognizing the middle ground where I've done enough to ask a focused question.

🟢One thing I've been improving is confidence in code reviews, because I used to stay quiet unless I was completely certain.

Bad examples

🔴My biggest thing is that I work too hard and sometimes care too much about getting things right.

🔴I guess I can be a perfectionist, which is good overall but can slow me down a little.

Weak answers are reputation-protecting scripts; strong answers reveal a believable pattern the candidate has genuinely observed in themselves.

Valuable

Show that the improvement area came from observation or feedback, not random self-help language.

Good examples

🟢I noticed a pattern in my first few tasks where I spent a long time blocked before asking a targeted question, and my mentor pointed out the same thing.

🟢After a couple of bugs took me too long to diagnose, I realized I didn't have a repeatable debugging approach, and my reviewer reinforced that.

Bad examples

🔴I just generally felt this was an area to improve because everyone always has to get better at communication.

🔴It's something I picked because it's a common interview question and I know it's important.

Weak answers feel generic and ungrounded; strong answers show that the candidate used evidence from real work to identify the issue.

You do not need a perfect ending, but you should show some sign that your effort is changing outcomes.

Good examples

🟢A recent task that would have stalled me before moved faster because I came to my mentor with a narrow question and the relevant logs instead of a general 'I'm stuck.'

🟢I've seen progress in code reviews because I now catch and explain root causes more often, and my reviewer has mentioned that my investigations are getting sharper.

Bad examples

🔴I'm still working on it, but I think I'm definitely better now because I've put a lot of effort into it.

🔴It hasn't come up in a clear way yet, but I feel more confident about it.

Weak answers assert improvement; strong answers provide observable signs that behavior and outcomes actually changed.

Example answers at
level

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.

Early January, 2026

Meta

Mid-level

Mid October, 2025

Meta

Senior

Early August, 2025

Meta

Senior

Your account is free and you can post anonymously if you choose.