Tell me about a time you disagreed with a cross-functional partner.
Asked at:
Meta
Lyft
Oracle
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you handle disagreement when authority is diffuse and incentives differ. They want to see whether you can understand another function's goals, advocate for your perspective without becoming rigid, and drive a workable outcome while preserving trust. At higher levels, they also look for whether you can resolve tension in a way that improves decision quality for more than just yourself.
“Describe a time you and a cross-functional partner had different views on what should happen next. How did you handle it?”
“Tell me about a situation where you had to push back on product, design, sales, or another partner team.”
“Have you ever been at odds with a non-engineering partner on a decision? What was the disagreement and how did it get resolved?”
“Walk me through a time when another function wanted one thing and you believed a different path was better.”
“What's an example of a healthy disagreement you had with a cross-functional counterpart?”
Key Insights
- Conflict with a cross-functional partner does not need to be dramatic. Strong answers often involve different goals, timelines, risk tolerance, or definitions of success rather than interpersonal friction.
- You should show that you tried to understand the other person's constraints before trying to win the argument. Interviewers notice quickly when a story is really just 'I was right and eventually they agreed.'
- Don't stop at the meeting where you disagreed. Explain what you did after the disagreement to move things forward, what tradeoffs were made, and whether the relationship or working model improved.
What interviewers probe atlevel
Top Priority
Show specific actions you took to move the disagreement forward: clarifying, proposing options, or seeking evidence, not just repeating your view.
Good examples
🟢I proposed a simpler first version that addressed the most important user concern while keeping the release on track.
🟢I put together a quick side-by-side example so we could compare the user impact and implementation cost instead of debating in the abstract.
Bad examples
🔴I explained my reasoning several times in the meeting until they finally accepted the engineering approach.
🔴We could not agree, so I asked my tech lead to decide and then we moved on.
Strong candidates create movement through options or evidence; weak candidates rely on persistence or authority.
A strong ending is not just 'I got my way'; it is a reasonable outcome and evidence that collaboration remained healthy.
Good examples
🟢We shipped a smaller version that met the immediate need, and afterward the designer and I worked together earlier in the next task to avoid the same issue.
🟢The support lead got a near-term workaround, and we also logged the broader fix into the roadmap with shared agreement on priority.
Bad examples
🔴They eventually agreed with me, we shipped it my way, and that showed the original request was not necessary.
🔴My lead sided with me, so we moved forward and the discussion was basically over.
Strong outcomes balance result and relationship; weak outcomes focus only on being proven right.
Valuable
You are not expected to be polished like a leader, but you should come across as respectful, calm, and clear.
Good examples
🟢I acknowledged their concern in the meeting and suggested we continue one-on-one so we could work through the details without creating tension.
🟢I explained the tradeoff in plain language and checked that I was addressing the concern they actually had.
Bad examples
🔴I told them their request did not make technical sense and that we should stop debating it.
🔴I corrected them in the larger meeting because I wanted everyone to know the ask was unrealistic.
Strong communication preserves dignity and shared understanding; weak communication embarrasses, dismisses, or escalates.
Pick a real work disagreement with some consequence, but keep the scope believable for someone contributing on a small project.
Good examples
🟢A designer wanted to add several edge-case states before launch, and I disagreed because we were missing test coverage on the core flow and release risk was growing.
🟢A support lead asked for a quick fix that would help one customer, and I pushed back because it could create inconsistent behavior for everyone else.
Bad examples
🔴We disagreed about the wording of an internal button label, and I pushed until they accepted my choice because I felt it was clearer.
🔴A product manager wanted a feature in the sprint and I said no because I was already busy, so my manager stepped in and settled it.
Strong stories involve a meaningful tradeoff and a level-appropriate stake; weak stories are either trivial or too escalated for the candidate's role.
Example answers atlevel
Great answers
On a recent feature, our designer wanted to include several extra error states before launch, and I was worried we were adding risk when the main flow still needed testing. Instead of just saying no, I asked if we could talk through what problem they were most concerned about. I learned they had seen users get confused in a similar flow, so their goal was reducing drop-off, not adding polish. I suggested we implement the two highest-risk states now and capture the rest for the next iteration, and I put together a quick example so we could compare effort and user impact. We launched on time with those changes, and afterward the designer started pulling me in earlier when we were scoping edge cases.
On a project to improve onboarding metrics, a data analyst asked that we include users' email addresses in event payloads so they could join datasets more easily, but I was uncomfortable putting PII into our analytics stream. I explained the privacy and compliance risks and asked what joins they actually needed so I could understand the use case rather than just saying no. They wanted quick joins, so I proposed sending a one-way hashed identifier plus account-creation timestamp so they could link records without raw emails. I built a small helper to compute the hash consistently on the backend and added a short note to the tracking docs showing how to reproduce joins. We delivered the metrics the analyst needed, kept PII out of the pipeline, and the docs helped them onboard two more experiments without requesting sensitive data.
Poor answers
I disagreed with a designer about how a form should work. I felt their version was too complicated, so I explained that engineering needed to keep things simple and we went with my approach. It worked fine and we were able to ship without extra delays. I think the important part was being direct so we did not overthink it.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late April, 2026
Lyft
Mid-level
Mid March, 2026
Meta
Principal
Early February, 2026
Meta
Staff
Tell me about a time when you had a disagreement with a cross-functional colleague.
Hello Interview Premium
Your account is free and you can post anonymously if you choose.