Search
⌘K

Tell me about a time you received pushback on a project

Asked at:

Meta


Try This Question Yourself

Practice with feedback and follow-up questions

What is this question about

Interviewers use this question to see how you respond when your ideas or plans are challenged. They are usually less interested in whether the pushback existed and more interested in how you diagnosed it, how you engaged with the other person, and whether you drove toward a better outcome without becoming defensive. At higher levels, they also look for whether you can handle legitimate resistance that comes from broader organizational constraints, not just individual disagreement.

  • Describe a time someone challenged your approach on a project. What did you do?

  • Tell me about a project where others didn't agree with your plan at first.

  • Have you ever faced resistance to something you were trying to drive? Walk me through it.

  • What's a time you had to respond to objections on a project you were working on?

  • Can you share an example of a project where your idea or execution plan was questioned?

Conflict Resolution
Communication
Ownership
Leadership

Key Insights

  • Pushback is not automatically a sign that others were wrong or obstructive. Strong answers show that you treated the pushback as information about risk, priorities, incentives, or missing context.
  • You do not need to 'win' the disagreement for this story to work. A mature answer can end with a changed plan, a compromise, or even your original idea being rejected for good reasons.
  • Be explicit about what you did after hearing the objection. Many candidates describe the disagreement itself but never show investigation, adaptation, or follow-through.

What interviewers probe at
level

Top Priority

A strong junior answer ends with a real resolution and shows that the working relationship stayed healthy.

Good examples

🟢We agreed on a safer version of the change, shipped it, and afterward my reviewer told me they appreciated that I worked through the concern with them.

🟢The final solution combined both perspectives, and the next time we worked together the review went much faster because there was more trust.

Bad examples

🔴We never fully agreed, but I finished my part and it worked out, so the disagreement wasn't really an issue.

🔴After I explained my reasoning, they stopped pushing back and I just moved on.

Weak answers end when the argument stops; strong answers end when the work and relationship both improve.

You want to show that you were neither stubborn nor passive: you considered the feedback, then adapted or defended your idea thoughtfully.

Good examples

🟢After hearing the concern, I changed the implementation to handle the risky case but kept the simpler parts of the original idea.

🟢I agreed with some of the feedback, but I also explained why one part of the approach still made sense and proposed a smaller version to test it safely.

Bad examples

🔴Once I got pushback, I dropped my idea right away because I assumed the more senior engineer probably knew better.

🔴I stayed with my original plan because I had already implemented most of it and didn't want to rework things.

Weak answers show either rigidity or over-deference; strong answers show judgment.

At junior level, interviewers mainly want to see that you stayed curious instead of assuming the other person was just blocking you.

Good examples

🟢When my reviewer pushed back, I asked what specifically felt risky to them and learned they were worried about edge cases I had missed.

🟢My manager questioned the timeline, so I set up a quick follow-up and asked whether the concern was complexity, testing, or business priority before changing the plan.

Bad examples

🔴I had already thought through the solution, so when my teammate pushed back I just explained it again until they agreed to let me proceed.

🔴My lead said my approach was risky, but I felt they were being overly cautious, so I kept working and showed results later.

Weak answers treat pushback as friction to overcome; strong answers treat it as a signal to investigate.

Valuable

You do not need a huge analysis, but you should show that you did more than argue from opinion.

Good examples

🟢To address the concern, I put together a small test and shared what happened so we could talk about concrete tradeoffs.

🟢I compared the two options on effort and failure cases and used that to discuss which one fit the deadline better.

Bad examples

🔴I told them I had seen similar code work before, so we should just try it.

🔴I felt the pushback was mostly preference, so I kept explaining why my version was cleaner.

Weak answers rely on personal preference; strong answers create shared facts.

Example answers at
level

Great answers

On a recent bug fix, I proposed a quick change that I thought would solve the issue, and a more experienced engineer pushed back during code review. Instead of just defending it, I asked what worried them most, and they pointed out that my change handled the main path but could break a less common case. I took an hour to test that scenario and they were right, so I changed the approach to be a little more robust while still keeping the fix small. I replied in the review with the updated reasoning and test results, and we merged it the same day. What I liked about that situation was that the pushback made the solution better, and afterward that engineer was more comfortable reviewing my changes because they saw I would engage with feedback seriously.

At my last role at a small startup, I built a signup flow and proposed client-side validation to cut down on user errors. The product manager pushed back, worried it would add development time and block our release. I asked which errors were most costly and offered a compromise: implement validation for the two fields causing the most support tickets, add clear inline messages, and add a lightweight analytics event so we could measure impact after launch. We delivered that smaller change on schedule, and within two weeks support tickets dropped for those errors. From that experience I learned to prioritize fixes that deliver measurable user benefit and to present trade-offs up front so stakeholders can make informed decisions.

Poor answers

I was adding a feature for an internal tool and another engineer pushed back because they thought my approach was too simple. I had already spent a lot of time on it, so I explained that the requirement was straightforward and that we didn't need to overcomplicate it. They still had concerns, but I finished the work and it ended up being fine. After that, people mostly left me alone on that project because they saw I could get it done.

Question Timeline

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

Mid December, 2025

Meta

Mid-level

Early September, 2025

Meta

Senior

Tell me a time when you think there will be a pushed back on a change

Mid July, 2025

Meta

Mid-level

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