Career Growth, Failure & Salary Negotiation

Career Growth, Failure & Salary Negotiation

These questions show up in almost every final round. They test self-awareness, career direction, and how you handle hard conversations.

Walk me through your career trajectory.

Keep it chronological and tight — 2-3 minutes max. I start with how I got into engineering, mention key milestones like a first job, a big project, or a role change, and connect each transition to a reason. “I moved to [company] because I wanted to work on larger-scale problems” is better than “I left because the pay was better.” I end with where I am now and what I’m looking for next.

The thread matters. “I started with UI, moved into architecture, and now I want to do system design at scale” shows direction. Random job-hopping without a story looks unfocused.

What’s your biggest professional failure and what did you learn?

Pick a real failure, not a trivial one. Own it fully.

• Situation — “I shipped a database migration that corrupted user data for a small percentage of users.”
• What went wrong — “I tested the migration on a clean database but didn’t test against databases with edge-case data from older app versions.”
• What I did — “I rolled out a fix within hours, personally reached out to affected users, and rebuilt the data from server-side backups.”
• What I learned — “I now always test migrations against production-like data dumps, and I added a migration testing step to our release checklist.”

Don’t minimize it. Don’t blame others. Show what changed and make it clear the same mistake won’t happen again.

What are your strengths?

Pick 2-3 strengths relevant to the role. Back each one with a specific example.

• “I learn new technologies quickly. When my team adopted Jetpack Compose, I ramped up within a couple of weeks and started writing production Compose code before most of the team had finished the tutorials.”
• “I’m good at breaking complex problems into manageable pieces. When I had a vague ‘improve performance’ mandate, I profiled the app, identified the three biggest bottlenecks, and tackled them one by one.”

“I’m a hard worker” tells nothing. “I pick up new codebases fast, which lets me contribute within the first week” is specific and believable.

What are your weaknesses?

Pick a real weakness. Show awareness and what I’m doing about it.

“Sometimes I move too fast and miss small details. I’ve caught myself shipping code with edge cases I didn’t think through. I’ve started having someone else review my work, and I write unit tests for scenarios I might overlook.”

Things to avoid:

• Disguised strengths — “I care too much about quality” is not a real weakness
• Disqualifying weaknesses — “I’m bad at meeting deadlines” is too risky
• No improvement plan — “I’m bad at documentation” without saying what I’m doing about it

Where do you see yourself in 5 years?

This isn’t a commitment. It’s about showing direction.

I’m honest about my growth — “I want to go deeper into Android platform engineering” or “I want to move toward a tech lead role where I can influence architecture decisions across teams.” I connect it to the company — “Your company works at a scale where I can grow into that kind of role.”

Don’t say “I want your job.” Don’t say “I don’t know.” Even a general direction is better than nothing. A good answer shows ambition without sounding like I’ll leave in a year.

Why do you want to work at this company?

Generic answers kill you here. “I like the company culture” says nothing. Be specific.

• Mention something about the product or technology — “Your app handles 50 million DAU, and I want to build at that scale”
• Mention the engineering culture — “I read your engineering blog about the migration to Compose, and the approach was exactly how I’d do it”
• Connect it to career goals — “I’m looking for a role where I can contribute to open-source and your team actively maintains public libraries”

Do the research. Read their engineering blog, check their GitHub repos, look at their tech stack. Specific knowledge shows genuine interest.

Why are you leaving your current role?

Never badmouth a current or previous employer. Even if the environment was toxic, frame it positively.

• Growth-focused — “I’ve learned a lot, but I’ve hit a ceiling. I want to work on problems at a larger scale”
• Opportunity-focused — “I’m looking for a team that works with [specific technology] because that’s where I want to grow”
• Challenge-focused — “My current role has become routine. I’m looking for new technical challenges”

Never say “my manager is terrible,” “the pay is bad,” or “I’m bored.” Lead with growth, not complaints.

How do you approach salary negotiation?

I research my market value before the conversation — levels.fyi, Glassdoor, Blind. I know what the role pays at similar companies.

• I try not to give a number first — “I’d like to understand the full scope of the role and the compensation structure before discussing numbers”
• I think in total compensation, not just base — base, bonus, RSUs, signing bonus, benefits. A lower base with strong stock can be worth more over 4 years
• If they give a number, I don’t accept or reject immediately — “Thank you, I’d like to take a day to review the full package.” This is normal and expected
• I use competing offers as leverage, not ultimatums — “I have another offer at $X. I’d prefer to work here because [genuine reason]. Is there flexibility?”

The negotiation starts before the offer. The stronger my interviews, the more leverage I have.

How do you evaluate a job offer beyond salary?

I look at the full picture, not just the number.

• Base salary — Guaranteed income. This is what mortgage lenders care about
• Equity — What’s the vesting schedule? For public companies, RSUs have real value. For startups, stock options are speculative
• Bonus — Is it guaranteed or performance-based? “Up to 15% bonus” often means 10-12% in practice
• Signing bonus — One-time payment. Good for bridging the gap if I’m leaving unvested equity
• Benefits — Health insurance, 401k match, PTO policy, parental leave. These have real monetary value
• Growth — Is there a clear promotion path? Will I learn new things? Will I work with people better than me?
• Work-life balance — Are evenings and weekends respected? What’s the actual culture, not the stated one?
• Team and manager — I can have a great company but a bad team. I try to talk to future teammates during the process

A role where I grow significantly in 2 years sets me up for a much larger jump next time.

How do you handle a counter offer from your current employer?

My general rule — if I decided to leave, I leave. Counter offers rarely fix the underlying problem.

• Why did I start looking? If it was growth, culture, or management issues, a salary bump doesn’t fix that
• My employer now knows I was looking. In some companies, this changes how they see me
• If they could pay me more all along, why did it take a resignation to offer it?
• Sometimes a counter offer just buys them time to find a replacement

There are exceptions — if I genuinely love the team and the only issue was compensation, a counter offer might make sense. But I’m honest with myself about the real reasons I was interviewing.

Tell me about a time you failed at something significant. How did you recover?

This is about recovery specifically. I pick a real example.

• Situation — “I led the migration from our legacy networking stack to Ktor. I underestimated the complexity and we missed the deadline by two sprints.”
• Impact — “Features that depended on the new networking layer were delayed. The PM was frustrated, and the team’s morale dropped.”
• Recovery — “I restructured the migration to be incremental — new features used Ktor, old features stayed on the legacy stack temporarily. I set up a migration tracker so everyone could see progress.”
• Result — “We completed the migration over the next quarter without blocking any feature work. I learned to always do a proof-of-concept before committing a team to a large migration.”

The point is that failure didn’t paralyze me. I assessed the situation, adjusted, and delivered.

How do you stay current with technology?

I follow official sources — Android Developers blog, Kotlin blog, Jetpack release notes. These matter more than random articles. I read source code when I use a library. Understanding Retrofit’s interceptor chain teaches more than any tutorial.

I build side projects to learn by doing. Even small things like “rebuild this screen in Compose” help. I follow specific engineers — Jake Wharton, Romain Guy, Zac Sweers — because their writing goes deeper than documentation. I also write about what I learn, because writing forces me to understand something thoroughly.

The goal isn’t to know every new library. It’s to understand trends well enough to make informed decisions for my team.

How do you handle imposter syndrome?

It shows up whenever I join a new team. Everyone seems to know so much, and I feel like I should already know everything they know. I remind myself that they had months or years to learn this codebase. I focus on learning one area deeply first instead of trying to understand everything at once.

Every time I push through that initial discomfort, I reach a point where I’m contributing meaningfully. The feeling doesn’t go away entirely, but I’ve learned to trust the process.

Tell me about a production incident you caused. What happened and what changed?

I own it and explain what I fixed systemically.

• Incident — “I pushed a change that caused a null pointer crash on the home screen. Our crash-free rate dropped from 99.8% to 97% within an hour.”
• Response — “I noticed the spike in Firebase Crashlytics, identified the root cause within 30 minutes, pushed a hotfix, and rolled it out as an expedited release.”
• What changed — “I added a pre-merge CI step that runs smoke tests on the most critical user flows. I also set up crash rate alerting so we catch regressions within minutes, not hours.”

A good answer shows three things: fast response, root cause analysis, and a systemic fix that prevents recurrence.

How do you talk about gaps in your resume?

Be brief and matter-of-fact. “I took six months off to travel and recharge after a demanding project. During that time, I contributed to open-source projects and completed a course on system design.”

Don’t apologize — a gap is not a flaw. If the gap was due to a layoff, I say so directly. Layoffs are common and carry no stigma. “The company had layoffs. I was part of the reduction. I used the time to [what I did].”

What questions should you ask the interviewer?

Always have questions ready. “No questions” signals low interest.

• “What’s the biggest technical challenge the team is facing right now?”
• “How does the team handle code reviews and technical decisions?”
• “What does a typical sprint look like?”
• “What brought you to this company?”
• “What does success look like in this role in the first 6 months?”

Avoid questions easily answered by the job posting. Don’t lead with “how soon can I get promoted” or ask about PTO and benefits — save those for HR conversations after the offer.

How do you handle burnout?

I recognize the signs early — constant fatigue, cynicism about work, declining quality. I don’t wait until I’m completely drained.

• I set boundaries. Working evenings and weekends occasionally is normal. Every week is unsustainable
• I talk to my manager — “I’m feeling stretched thin. Can we deprioritize some of this?” A good manager will help
• I take real breaks. A week off where I check Slack isn’t a real break
• If the burnout is from monotony and not overwork, side projects or learning something new can help re-energize me

Common Follow-ups

• How do you decide when it’s time to leave a company?
• What would you do in your first 30 days in this role?
• How do you handle a situation where you’re not growing in your current role but can’t leave yet?
• Tell me about a time your career plan changed unexpectedly. How did you adapt?
• How do you approach negotiating a promotion with your current employer?
• What’s the most valuable feedback you’ve ever received?
• How do you build a personal brand as an engineer without being self-promotional?