Library
MetaSoftware Engineer· Behavioral

Tell me about a time you disagreed with your manager. How did you handle it?

Meta's engineering culture explicitly values 'Move Fast' and respectful, explicit disagreement. Interviewers ask this to test two things: that you'll push back on a bad decision rather than silently comply, AND that you'll commit fully once the call is made. Both halves matter. A candidate who never pushes back signals passivity; a candidate who can't commit after disagreeing signals friction. The framing engineers use internally is 'disagree and commit' — make your case with data, then row hard in whatever direction the team chooses.

How to think about it

Five beats: (1) the disagreement and what was at stake, (2) the data or reasoning behind your view, (3) the channel you used to raise it (1:1, doc, meeting?) and the tone, (4) the decision that was made, (5) how you committed — not begrudgingly, but visibly.

Weak · sample answer

44/100

Yeah, my manager and I disagreed about something once. He wanted us to use a microservice for a feature and I thought we should just add it to the existing service.

I told him I thought he was wrong but he insisted, so we did it his way.

Adversarial framing, no data
'He insisted' makes the manager sound unreasonable and you sound resigned. Interviewers will worry about how you handle pushback in either direction.

It ended up being a lot more complicated than it needed to be, like I'd said it would be.

Vindication-as-conclusion is a red flag
Ending with 'I was right' signals you'll re-litigate decisions after the fact. The interviewer wants 'I committed and made the best of it', even if you turned out to be right.

I think the lesson is that sometimes you have to push back when you think something is wrong.

Why this scores weak

Frames the disagreement adversarially ('he insisted'), shows no data behind the candidate's view, and ends with vindication rather than commitment. Two red flags in one answer: the candidate sounds both unable to make their case and unable to commit after the call.

Key takeaways

  • Lead with data or reasoning, not 'I thought he was wrong.'
  • Describe the channel you used — 1:1, written doc, group meeting — because tone matters.
  • End with how you committed after the call, not whether you turned out to be right.

Average · sample answer

71/100

About six months into my role, my manager proposed splitting our notifications system into its own microservice. The system was getting bigger and harder to reason about, and the idea was that a separate service would let us scale it independently.

I disagreed. My view was that the complexity wasn't actually in the volume — it was in the business logic — and a microservice would just move the complexity to the network boundary while adding ops overhead.

Clear technical position with reasoning
'Complexity in the business logic, not the volume' is the kind of crisp framing interviewers respond to.

I raised it in our 1:1. I walked through three specific cases where I thought a microservice boundary would actually make the code harder, not easier. He pushed back — he said the scaling was the long-term concern, not the current logic. We talked through it for about 30 minutes.

Right channel, specific cases
1:1 was the right channel and citing three specific cases is exactly what 'data-driven disagreement' looks like in practice.

In the end he decided to go ahead with the split. I committed to it and did the migration work, and it ended up being fine. Some of my concerns played out — the network boundary did add complexity in a couple places — but on balance the team has been able to ship faster.

Commitment is told, not shown
'I committed and did the work' is correct but unspecific. What did *visible* commitment look like — owning the most complex piece? Writing the migration doc? Helping a teammate ramp on the new service?

Why this scores average

Solid disagreement story with a clear position, real data, and the right channel. Held back by glossing over the commitment phase — 'I committed and did the work' is the right outcome but the interview wants to see *how* commitment looked.

Key takeaways

  • When you commit, name a specific thing you did that signaled commitment — owned the riskiest migration piece, wrote the rollout doc, mentored teammates onto the new system.
  • Be willing to acknowledge what you got *right* in your original concerns without making it the headline.
  • End with what the team got out of the decision, not what you got out of being right or wrong.

Strong · sample answer

90/100

Six months into my role, my manager proposed splitting our notifications system into its own microservice. The pitch was independent scaling, since notifications traffic was growing 30% quarter over quarter and our shared service was starting to feel the pressure.

I disagreed. My read was that the scaling pressure was real but solvable in-place — we hadn't tuned the worker pool in 18 months — and that the actual pain point was business-logic complexity in the routing layer, which a service boundary wouldn't fix. Splitting would just push the same complexity onto a network call.

Names the *actual* problem, not the proposed solution
Reframing the disagreement from 'service vs. monolith' to 'which problem are we solving' is a senior-engineer move.

I raised it in our next 1:1 — I felt the disagreement was substantive enough to need real time, not a Slack thread. I came with two pieces of data: a profiling run showing 80% of our latency was from a specific routing rule, not from contention, and a small worker-pool tuning experiment I'd run in staging that showed we could absorb the next two quarters of growth without a split.

Channel + tone + data
Choosing the 1:1 over Slack signals respect for the disagreement. Bringing a staging experiment turns 'I think' into 'here's what the data says'.

He took it seriously. He acknowledged the profiling data but raised two concerns I hadn't weighted enough: the routing-layer complexity would *also* be hard to refactor inside the monolith, and he was thinking 18 months out — past the point where the worker-pool tuning would carry us. We agreed I'd write up the in-place option as an alternative for the team's tech leadership review, with him reviewing the draft.

Disagreement becomes collaboration
Notice how the disagreement opens into a structured comparison rather than a winner-takes-all. The manager isn't a blocker, he's a reviewer of your proposal.

The tech leadership review went with the split, ultimately, because of the 18-month scaling argument. I committed visibly: I volunteered to own the routing-layer extraction (the piece I'd thought would be hardest), wrote the migration doc, and ran the brown-bag session for the rest of the team when we cut over.

Commitment is specific and visible
Volunteering for the hardest piece is the load-bearing detail. It's the unambiguous signal of 'disagree and commit' — you took on the work you were most skeptical of.

Eighteen months later the split is paying off — the notifications service is handling 4x our original traffic without the rest of the system feeling it. My original concern about routing-layer complexity also turned out to be real, and we ended up refactoring it inside the microservice; that work would've been harder in the monolith because the test surface was bigger. So the call my manager made turned out to be the right one, and I'm glad I committed to it rather than half-rowing.

Updates own beliefs in public
Ending with 'his call turned out to be right' — said sincerely, with the reasoning — is the senior engineer's version of intellectual honesty. It also lands the 'commit' half of 'disagree and commit' decisively.

Why this scores strong

Reframes the disagreement from solution-vs-solution to which-problem-are-we-solving, brings real data through the right channel, turns the disagreement into a collaborative review rather than a standoff, commits visibly by owning the riskiest piece, and ends by updating own beliefs in public. Every beat of 'disagree and commit' is present and load-bearing.

Key takeaways

  • Reframe the disagreement from 'A vs B' to 'what problem are we actually solving?' — it almost always opens up better options.
  • Choose the channel deliberately and say why: 1:1 for substantive disagreements, Slack for tactical ones, group docs for cross-team decisions.
  • Volunteer for the piece you were most skeptical of after the call goes against you — it's the strongest possible commitment signal.
  • End by updating your beliefs in public, with reasoning. Sincere 'his call was the right one' beats 'we made it work' every time.