Tell me about a time where you proactively proposed a change.
Asked at:
Scale AI
Meta
Amazon
Expedia
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see whether you notice opportunities for improvement without being told, and whether you can turn an observation into an actual change. They are usually not just looking for ideas; they want evidence of judgment, initiative, and follow-through. At higher levels, they also care whether the change was appropriately scoped, influenced others, and improved how a team or organization operates.
“Describe a time you saw something that could be improved and took the initiative to change it.”
“Can you give me an example of when you introduced a better way of working?”
“Tell me about a time you didn't wait to be asked and proposed a solution to a problem.”
“What's a change you pushed for on your team, and how did you get it adopted?”
“Have you ever noticed a recurring issue and driven an improvement before anyone assigned it to you?”
Key Insights
- You need more than 'I had an idea.' Show the full loop: what you noticed, why it mattered, how you validated it, what resistance or uncertainty existed, and what changed because you pushed it forward.
- A strong answer usually starts before the proposal itself. Explain how you recognized the problem or opportunity and why you believed a change was worth pursuing rather than just being a personal preference.
- Don't frame proactivity as going around people or forcing your solution through. The best answers show initiative paired with judgment: you brought evidence, adapted to constraints, and made it easy for others to say yes.
What interviewers probe atlevel
Top Priority
At staff level, your influence should reflect cross-team credibility and the ability to align people who have different incentives or constraints.
Good examples
🟢Different teams had different concerns about the shared capability, so I tailored the pitch to each one, addressed migration cost directly, and incorporated feedback into the rollout plan.
🟢I framed dependency reviews as a way to reduce surprise work rather than add process, and I worked with a few teams to shape a version that fit their planning rhythm.
Bad examples
🔴I explained that the shared capability was the right architectural choice and expected teams to align around that.
🔴I told teams they needed dependency reviews because their current planning process was too informal.
Weak answers rely on expert opinion alone; strong answers build buy-in by respecting local realities and making the change easier to adopt.
Even at junior level, proactivity means helping make the change real, not just mentioning it once and moving on.
Good examples
🟢After suggesting the checklist, I drafted the first version, asked a teammate to review it, and updated it after we found a few missing steps.
🟢I proposed the FAQ page and then collected the common questions, wrote initial answers, and shared the link so people could start using it right away.
Bad examples
🔴I brought up my idea in standup and assumed the team would take it from there.
🔴I sent a message suggesting a fix and considered it done once people reacted positively.
Weak answers confuse raising a point with owning a change; strong answers show initiative in doing the work needed to move the idea forward.
Valuable
Even for a small change, show that you checked whether it helped instead of assuming success because it was implemented.
Good examples
🟢After we added the checklist, I asked the next new teammate whether it covered the confusing setup steps, and we made one more update based on that feedback.
🟢I checked a few weeks later and saw that people were asking those repeat questions less often, which suggested the FAQ was actually being used.
Bad examples
🔴The checklist was added to the doc, so I considered the problem solved.
🔴I made the FAQ page and people seemed happy with it, which was enough for me.
Weak answers equate implementation with impact; strong answers show some evidence that the change improved the original problem.
You do not need a formal analysis, but you should show you checked whether your idea solved a real problem and was practical for the team.
Good examples
🟢Before writing the checklist, I asked two teammates which setup steps were easiest to miss so I focused on the real problem areas.
🟢I looked through recent support messages to see which questions were repeated most often before drafting the FAQ.
Bad examples
🔴I was sure the checklist would help, so I put it together without asking anyone whether the missing step was actually a common issue.
🔴I created the FAQ page based on what I remembered people asking, without checking whether those were still the main questions.
Weak answers assume the candidate's intuition is enough; strong answers show lightweight validation and practical thinking.
Example answers atlevel
Great answers
On my last team, I noticed that new engineers, including me, kept getting stuck on the same local setup step when trying to run one of our services. It wasn't a huge issue by itself, but it kept costing people time and interrupting whoever happened to know the fix. I suggested adding a short setup checklist to our team documentation, and before writing it I asked two teammates which steps were most commonly missed so I could focus on the real pain points. I wrote the first version, had a teammate review it, and we linked it from the onboarding page. When another engineer joined a few weeks later, I checked in with them and found one missing step, so I updated the checklist. After that, we saw a lot fewer setup questions in chat.
At my last job I worked on a small front-end team and noticed we kept recreating buttons, headers, and spacing rules slightly differently in each feature, which led to dozens of nit-picky PR comments and frustrated designers. I proposed we adopt a tiny shared set of UI components plus a one-page style guide so people wouldn't have to guess which spacing or color to use. To lead by example I implemented a simple button component, wrote clear usage notes, and walked the team through it during our weekly demo so we could iterate quickly. After a couple of quick updates the team started using the shared components from the repo and referencing the guide in PRs. Over the next month we saw far fewer style-related review comments and less back-and-forth with design, which let us deliver features faster and with better consistency.
Poor answers
One time I proactively proposed that our team reorganize the task board because I thought it was too cluttered. I made a new column layout and showed everyone how I thought it should work, and people were generally fine with it. It made the board look cleaner and easier to read. I like doing that kind of thing because I notice when processes feel messy.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early April, 2026
Scale AI
Senior
Mid December, 2025
Senior
Mid July, 2025
Roo
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.