Tell me about a time when you changed your mind about something important
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess whether you can update your beliefs when new information appears, especially when the topic mattered and you were initially invested in a different view. They are looking for intellectual honesty, sound judgment, and evidence that the change in mind came from real learning rather than passivity or pressure. Strong answers also show what you did after changing your mind and whether your reasoning process improved afterward.
Key Insights
- Pick something genuinely important where you had a real point of view at first. If the original opinion was trivial or obviously wrong, the story gives very little signal about judgment.
- You should explain why your original view was reasonable at the time, what specifically changed it, and how you verified that the new conclusion was better. The learning process matters more than the plot twist.
- Don't frame changing your mind as simply deferring to authority. The strongest answers show curiosity, evidence-seeking, and a visible behavior change after the decision.
What interviewers probe atlevel
Top Priority
Don't stop at 'I agreed'; show what you did next and how your future work changed.
Good examples
🟢I reworked the implementation, added the simpler instrumentation we agreed on, and later used the same 'measure before optimizing' approach on another ticket without needing to be prompted.
🟢After the bug-fix discussion, I wrote down the failure pattern and started checking for that class of issue before proposing changes in similar areas.
Bad examples
🔴Once I changed my mind, I updated the code and we moved on.
🔴I accepted the feedback and finished the task the other way.
Weak answers end at agreement; strong answers show changed execution and a repeatable lesson.
Valuable
Example answers atlevel
Great answers
On a recent feature, I was convinced we should add caching right away because the page felt slow in my local testing, and I thought that would make the launch safer. A teammate asked me to first check whether the slowdown was actually happening with realistic data, so I ran a small test and found most of the time was coming from one unnecessary request, not repeated computation. That changed my mind because adding caching would have made the code more complex without solving the main problem. We removed the extra request instead, and the page became fast enough with much simpler code. The part I took away was to measure the real bottleneck before optimizing, and I've used that approach on later tasks too.
At my last job in retail operations, I was sure the best way to reduce mistakes was to add a more detailed checklist for the team before each store opening. I had seen a few missed steps, so I thought the answer was to make the process tighter and more formal. After watching the team for a week, I realized the real issue was that the checklist itself was too long for the busy morning rush, so people were rushing through it or skipping parts entirely. That changed my mind because I saw that adding more rules was actually making the problem worse. I helped shorten the checklist and grouped the most important tasks at the top, and the number of misses dropped. What I learned was to look at how people actually work before deciding that a process needs more steps.
Poor answers
I changed my mind about how to build a small internal page on my internship. I wanted to structure it one way, but the senior engineer preferred a different pattern because that's how the team usually did it. I switched to their approach and finished it pretty quickly. It worked out well because there was less debate and the code matched the rest of the project.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early June, 2026
Late May, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.