Tell about a time when you had to go against the norm and push for a change
Asked at:
PayPal
Amazon
Meta
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can recognize when an accepted way of working is no longer serving the team or business, and whether you can influence change without relying on authority. Interviewers are usually looking for judgment, courage, and pragmatism: did you challenge the norm for a meaningful reason, understand why the norm existed, and drive a better outcome responsibly? For more senior candidates, it also reveals how well you navigate resistance, align others, and scale change beyond yourself.
“Describe a time when you challenged an established way of doing things.”
“Tell me about a time you pushed back on 'how we've always done it.'”
“Have you ever seen a team habit or process that wasn't working and tried to change it? What happened?”
“Give me an example of when you had to advocate for a different approach even though it wasn't the popular one.”
Key Insights
- You should explain why the existing norm made sense in the first place. If you treat it as obviously dumb, you miss a chance to show judgment and empathy for the people who created or defended it.
- Going against the norm is not the same as being contrarian. Strong answers show that you identified a meaningful problem, tested your view, and took responsibility for improving the outcome rather than just challenging the status quo.
- You should make the result legible. Don't stop at 'I convinced people' or 'we changed the process'—show what improved, what tradeoffs you managed, and whether the change stuck.
What interviewers probe atlevel
Top Priority
Even at junior level, interviewers want to see that you didn't frame everyone else as wrong or outdated—you tried to understand their reasons first.
Good examples
🟢I learned the team kept the manual checklist because a previous automation had hidden failures, so I proposed a version that still kept the risky step visible.
🟢I asked why the guide hadn't been updated and found that ownership was unclear, so I took on drafting it instead of just criticizing the gap.
Bad examples
🔴People were just resistant to change, so I kept repeating that my way would be faster until they agreed to try it.
🔴The team was being old-fashioned, and I had to push them a bit because they were stuck in habit.
Weak answers reduce others to stubbornness; strong answers show curiosity about the underlying concerns or history.
For junior candidates, influence usually means doing homework, making a concrete suggestion, and helping with the implementation—not winning a debate.
Good examples
🟢I wrote down the repeated setup issues, drafted a first pass of the updated guide, and asked my mentor to review it so the team could decide from something concrete.
🟢I suggested a small automation, built a safe prototype for the non-risky steps, and showed how it would still leave room for a manual verification step.
Bad examples
🔴I told my lead the current approach didn't make sense and kept bringing it up in standup until it changed.
🔴I felt strongly about fixing the onboarding issue, so I sent a message saying the guide needed to be redone and waited for someone to pick it up.
Weak answers stop at raising the issue; strong answers lower the cost of saying yes by doing useful preparatory work.
At junior level, the bar is showing that you noticed a real problem in your day-to-day work and spoke up for a practical improvement, not that you reinvented the team.
Good examples
🟢I noticed our manual release checklist caused repeated missed steps, so I suggested a small script and checklist update after seeing the same issue happen twice.
🟢Our onboarding guide was out of date and new engineers kept asking the same setup questions, so I proposed rewriting the guide after collecting the common failure points.
Bad examples
🔴The team usually named files one way, but I preferred a different style, so I pushed to change it because it felt cleaner to me.
🔴I didn't like that we had to ask for code review from two people, so I argued against it since it slowed me down.
Weak answers are preference-driven; strong answers are problem-driven and tied to observable pain.
Valuable
Persistence at junior level should look like steady follow-through and adaptation, not stubbornly pushing the same argument.
Good examples
🟢When the first draft of the guide didn't get traction, I asked what would make it easier to adopt and reorganized it around the most common setup failures.
🟢When there was concern about automation, I narrowed the change to the safest steps first so the team could gain confidence before doing more.
Bad examples
🔴My lead didn't agree at first, so I kept insisting because I knew my approach was better.
🔴People didn't update the guide after I mentioned it, so I stopped bringing it up and focused on my own work.
Weak answers show either rigidity or passivity; strong answers show persistence paired with adaptation.
Example answers atlevel
Great answers
In my first year on a backend team, the norm was to follow a manual release checklist exactly as written, even though several steps were repetitive and easy to miss. After seeing one release delayed because a step was skipped, I asked why we hadn't automated parts of it and learned the team had tried before but lost visibility into one risky verification step. I put together a small script for the safe repetitive parts, kept the manual verification explicit, and walked through it with my mentor and the teammate who owned releases. We tried it on a lower-risk service first, then adjusted the order of a couple of steps based on feedback. After that, releases were a bit faster and, more importantly, we stopped missing the specific step that had caused confusion. What I learned was that pushing for change worked much better once I understood why the old process existed instead of assuming it was just outdated.
At my previous job as a junior frontend developer, the team routinely prioritized visual polish and fast shipping, and accessibility fixes were usually pushed to an undefined 'later' backlog. After answering a few support tickets from users who couldn’t navigate our product with a keyboard, I felt strongly we were excluding real customers and raised it in our weekly planning. I built a small, accessible version of our signup flow that handled keyboard focus and used screen-reader-friendly labels, then demoed it side-by-side with the current flow to show the difference. I suggested adding three lightweight accessibility checks to our definition of done and offered to update the shared component library with accessible patterns. The team agreed to try the checks for the next two sprints; we caught and fixed several issues before release and saw fewer accessibility-related support requests. I learned that bringing concrete examples and low-effort fixes made it much easier to change team norms around inclusivity.
Poor answers
On my team people used a pretty old release process, and I felt it was inefficient. I told them we should automate it because manual steps don't really make sense anymore, and I brought it up a few times in standup until we changed some of it. The team eventually agreed, and I think that showed I was willing to challenge the status quo. I usually try to do that when I see something that could be cleaner.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid May, 2026
Mid-level
Tell the time when you challenged the status Quo
Early May, 2026
Amazon
Senior
Mid September, 2025
PayPal
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.