Search
⌘K

Tell me about a time where you proactively proposed a change.

Asked at:

Meta

Amazon

Amazon

Expedia

R

Roo


Try This Question Yourself

Practice with feedback and follow-up questions

What is this question about

Interviewers want to see that you notice important problems without being told, can frame a clear hypothesis for improvement, and move an idea from proposal to measurable impact. They’re probing for ownership, judgment about scope, and the ability to balance speed with rigor. Strong answers show right-sized evidence, thoughtful trade-offs, and how you earned buy-in and closed the loop.

Key Insights

  • Start with a crisp problem statement and a testable hypothesis. You’re not pitching a tool; you’re solving a pain with an expected outcome.
  • Right-size the evidence. Show how you validated the idea cheaply (pilot, metric, survey) before asking others to commit.
  • Name the costs and risks up front and how you mitigated them. Proposals without downsides sound naive; owning trade-offs signals maturity.

What interviewers probe at
level

Top Priority

Show you thought about downside and have a rollback or small, safe step.

Good examples

🟢I proposed enabling the new linter in warning-only mode first to surface issues without blocking merges.

🟢I suggested swapping the HTTP client behind an interface with a feature flag to roll back if errors spiked.

Bad examples

🔴I said there were no downsides to adding the linter because code quality always helps.

🔴I proposed replacing the library in one PR, not considering breakage risk.

Strong answers anticipate failure modes and limit blast radius; weak ones assume only upside.

Own a small rollout, check the metric, and report back on what changed.

Good examples

🟢After isolating flaky tests, CI re-runs dropped from 30% to 12%; I shared a short post with the team.

🟢The setup script cut onboarding from 90 to 45 minutes on two new hires; I added it to the README.

Bad examples

🔴I merged the change and moved on; I assume it helped because no one complained.

🔴I said it worked but didn’t compare before/after numbers.

Strong answers quantify results and communicate; weak ones leave impact implied.

Do a cheap test or data pull to validate the pain and expected gain before asking others to switch.

Good examples

🟢I sampled 50 CI runs and found 30% re-runs from one flaky suite; that informed my targeted fix proposal.

🟢I timed the local setup on two laptops and recorded a 90-minute average; that baseline set our goal.

Bad examples

🔴I felt CI was slow based on a few runs, so I asked to change providers without any numbers.

🔴I proposed a new library and said it would be faster, but I hadn’t benchmarked our use case.

Strong responses include simple, relevant measurements; weak ones rely on anecdotes or vibes.

Anchor your proposal on a real pain the team feels and state what you expect to improve and how you’ll know.

Good examples

🟢PRs were stuck for hours due to flaky tests; I proposed isolating tests that hit the database, expecting to reduce CI re-runs by 30%.

🟢New hires took days to set up dev environments; I proposed a script to bootstrap services, hypothesizing we could cut setup time in half.

Bad examples

🔴Our codebase felt messy, so I suggested we add a new linter because I prefer its rules.

🔴I proposed switching to a different HTTP client since it looked more modern, but I didn’t tie it to any specific issue.

Strong answers focus on a real, measurable pain with a hypothesis; weak answers are preference-driven with no expected outcome.

Valuable

Share a concise rationale, ask for feedback, and incorporate it without getting defensive.

Good examples

🟢I summarized the proposal in three bullets, asked for concerns, and added a rollback plan based on feedback.

🟢I met with a skeptical teammate, learned their concern was test coverage, and added tests to address it.

Bad examples

🔴I posted a long doc and was frustrated no one read it; I assumed they just didn’t care.

🔴When my idea was questioned, I repeated myself and said we should just try it.

Strong answers show listening and adaptation; weak ones treat pushback as obstruction.

Propose something you can own end-to-end or pilot safely in your lane.

Good examples

🟢I piloted the linter on our repo first, documented results, and asked other teams only after proving value.

🟢I scoped the refactor to a module with tests and paired with a senior for review.

Bad examples

🔴I proposed an org-wide tooling change and expected teams to adopt it, but I couldn’t support it.

🔴I tried to refactor a critical service alone and got blocked for weeks.

Strong answers match scope to influence and support; weak ones overreach without a plan.

Question Timeline

See when this question was last asked and where, including any notes left by other candidates.

Mid December, 2025

Google

Google

Senior

Mid July, 2025

R

Roo

Senior

Early July, 2025

Expedia

Senior Manager

Comments

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