What the interviewer is really checking

Three short questions come up in almost every behavioral round, and each one is a probe for a specific risk, not small talk. "Why are you looking to change?" checks whether you're running toward something or fleeing a mess. "What are you looking for in a new role?" checks whether your criteria are self-aware and actually match what the role offers. "What's your greatest strength or weakness?" checks self-awareness, and whether you can name a real limitation without false modesty or a thinly disguised brag.

The shape of a strong answer

Each answer should run 30 to 45 seconds: state the answer plainly, back it with one concrete detail, then stop.

Why are you looking to change? Pick a reason about growth, not escape: scope, scale, technology, or ownership you don't have yet. Never bad-mouth a current employer or manager, even if it's true. It reads as a risk you'll say the same thing about this company in two years.

What are you looking for in a new role? Name 2-3 concrete criteria, like team size, stack, or ownership level, and tie at least one directly to something this specific role offers. "Good culture" or "growth opportunities" with no detail sounds like you haven't thought about it.

Greatest strength or weakness? For strength, pick one relevant to the role and back it with a specific example, not just an adjective. For weakness, pick something real and specific, then describe the concrete system you use to manage it. "I'm working on it" alone isn't a system.

Remember: each of these three answers needs exactly one concrete detail. A generic answer without one sounds rehearsed in the worst way.

Worked example

Why are you looking to change? "I've grown a lot at my current company, but it's a 12-person engineering team, and I've hit the point where the interesting technical problems, the ones at real scale, don't exist here yet. I want to work somewhere with more traffic and more engineers to learn from."

What are you looking for? "Three things: a codebase with enough scale that performance actually matters, a team where I can learn from senior engineers instead of being the most senior person in the room, and ownership of a problem end to end rather than a slice of a ticket queue. This role's backend rewrite project looks like exactly that."

Greatest weakness? "I default to solving problems myself before asking for input, which works fine solo but slows a team down. I've missed chances to get feedback earlier. I've started forcing myself to post a design doc before writing code, even a rough one, specifically so someone can catch a bad assumption before I've sunk two days into it."

Common mistakes

• Criticizing a current employer or manager, even when the criticism is fair.
• Saying "good culture" or "growth opportunities" with no specific detail behind it.
• Disguising a brag as a weakness, or offering a weakness with no system for managing it.
• Running past 45 seconds and drifting into unrelated backstory.

Remember: frame "why changing" around what you're moving toward, never around what you're fleeing.