BQ-019 · Conflict, influence, and collaboration
Tell me about a technical disagreement with a colleague.
Illustrative fictional example · Editorial draft, version 1. Use the structure and reasoning to prepare your own experience. Do not present this sample as your personal history.
What the interviewer may evaluate
These are general coaching criteria; interviewers and roles differ.
- Do you represent the opposing position fairly?
- Do you use evidence and a clear decision process rather than authority or persistence alone?
- Can you commit to a decision and update your own opinion?
Before you start
- Identify a genuine disagreement
- Separate your view from the shared goal
Choose an experience that answers the prompt
Suitable examples
- A design disagreement with real constraints and more than one defensible option.
- A case where evidence changed either your position or the final proposal.
Examples to avoid
- A story where the other person is simply incompetent.
- A routine clarification presented as a major conflict.
Gather your evidence
- The shared goal and both alternatives.
- Who had decision authority and what evidence was collected.
- What you would have done if your preferred option lost.
Build the answer
- Situation and task. State the shared goal, disagreement, and your responsibility briefly.
- Actions. Explain the other person’s valid concern, your evidence-gathering step, and the decision process.
- Result. Separate measured findings from the team decision and later production outcomes.
- Reflection. Explain how the process improved the decision and what could change your view.
Full sample answer and paragraph explanations
Read aloud to check pacing. Expand the annotations to see why each paragraph matters and which detail belongs in a follow-up.
Reveal the full illustrative answer
Situation and task
I was implementing a background import service when a colleague proposed starting every school-level job immediately to minimize completion time. I preferred queuing work with bounded workers because the database had a limited connection budget. I owned the worker implementation; the service lead owned the final architecture decision. Our shared goal was reliable completion without disrupting interactive requests.
Why this paragraph works
Evidence: Both options, shared goal, and decision owner.
Why it matters: Makes the conflict concrete without turning it into a contest of status.
Prepare for a follow-up: Explain the connection budget and why the service lead owned the decision.
Understand the other view
I asked my colleague to explain the latency concern before proposing a test. They were right that a queue could add waiting time and that an overly conservative worker limit would leave capacity unused. I wrote down both concerns and suggested comparing the approaches using the same synthetic burst workload. We agreed to observe job completion, connection contention, and foreground request behavior rather than judge the result only by how quickly jobs started.
Why this paragraph works
Evidence: Valid concern about waiting time and agreed comparison criteria.
Why it matters: Demonstrates listening and a test that could disprove the candidate’s view.
Prepare for a follow-up: Prepare the workload assumptions and why the chosen metrics mattered.
Evidence and decision
I built the bounded-worker variant, and my colleague helped define the burst and inspect the immediate-start version. Under the tested load, unrestricted starts caused connection contention. Bounded execution delayed some starts but kept resource use inside the operating budget. I proposed a configurable worker limit, queue-age monitoring, and a review once we had real workload data. My colleague improved the retry policy, and we documented both the reasons for the limit and the evidence that would justify changing it.
Why this paragraph works
Evidence: A bounded experiment, observed contention, and a revisable policy.
Why it matters: Connects evidence to the recommendation and credits the colleague’s contribution.
Prepare for a follow-up: Explain how the worker limit was chosen and when the test was insufficient.
Result and reflection
The service lead selected the bounded approach for the release. The outcome I could defend at that point was the test result and the agreed operating policy; I would not claim a production latency improvement without production measurements. I learned that acknowledging the other person’s concern made the design more useful. If immediate execution had met the resource constraints safely, I would have supported it. The goal was a better decision, not proving that my first proposal was right.
Why this paragraph works
Evidence: Actual decision plus limits on claimed impact.
Why it matters: Shows commitment, attribution, and willingness to change rather than declaring victory.
Prepare for a follow-up: Explain monitoring results later, if known, and how the operating policy evolved.
Reveal the concise version — roughly 60–90 seconds
On a background import service, a colleague wanted to start all jobs immediately for faster completion. I preferred bounded workers because the database had a limited connection budget. I owned implementation, while the service lead owned the final decision. I first clarified my colleague’s valid concern: a queue could add avoidable waiting time. We agreed on a burst test comparing completion behavior and foreground request health, not just job start time. Under that workload, unrestricted starts caused connection contention. We chose a configurable worker limit with queue-age monitoring and a later review using real workload data. My colleague helped improve the retry policy. I can defend the test result and decision; production improvement would need separate measurement. I learned to test both positions fairly and state what evidence would change my own recommendation.
Improve a weak answer
Weak excerpt
My colleague wanted an unscalable design. I explained why it was wrong until the team agreed with me.
Improved excerpt
We disagreed about starting all jobs immediately versus limiting concurrency. I acknowledged the queue-latency concern and proposed a comparison measuring both completion time and database contention. The evidence supported a configurable limit, and my colleague helped improve the retry policy.
The rewrite treats both positions fairly, makes uncertainty testable, and shows a joint decision. It still needs the actual workload and result evidence when probed.
Prepare for probing questions
Attempt each response before opening the guidance. Replace fictional details with your own evidence.
What evidence would have changed your recommendation?
If immediate starts had kept foreground requests within the agreed service budget under representative bursts, I would have supported it or proposed a lighter limit. The criterion must be stated before the test; otherwise it is easy to reinterpret every outcome in favor of your initial view.
How did you decide what burst to test?
I would start from expected arrival patterns, downstream connection capacity, and known interactive traffic. In the sample, the workload was synthetic, so its limitations remained explicit. Describe your real assumptions and do not imply the experiment proves safety for every workload.
What if your colleague still disagreed after the test?
I would ask which assumption or measurement they disputed, document the remaining uncertainty, and ask the service lead to decide based on the shared criteria. After the decision I would help implement it and retain monitoring that could reveal a mistaken assumption.
Who selected the worker limit?
In this example, I proposed a configurable limit based on the resource budget and test, and the lead approved it. I would explain the actual calculation or experiment if asked. Do not invent a universal safe concurrency number; each downstream system has different capacity.
What did your colleague contribute?
They highlighted the waiting-time risk, helped define a meaningful burst, inspected the immediate-start behavior, and improved retries. Explain those contributions explicitly. Crediting the other person makes your own reasoning clearer rather than weakening your story.
What if the selected approach later performed poorly?
I would examine queue age, completion behavior, and downstream health together, then revisit the limit or architecture. Committing to a decision means supporting its execution and monitoring, not refusing to update it when evidence changes.
Adjust the evidence to your level
Early-career
A code-review or project disagreement can work if you fairly explain both positions and how it was resolved.
Mid-level
Show ownership of the comparison and implementation, with clear escalation and decision rights.
Senior
Show stakeholder alignment, operational criteria, and a process that helps the team resolve later disagreements.
Staff
Show alignment across teams with different constraints and an adoption mechanism beyond one local design choice.
Common mistakes
- Calling the other engineer wrong without explaining their constraints.
- Presenting a benchmark as proof of unlimited production scalability.
- Claiming influence when a manager simply mandated the choice.
- Omitting what you did after your preferred option was rejected.
Build your own answer
This worksheet stays in this page’s memory. It is not saved to your account or this device. Copy or download it before leaving or refreshing. Remove confidential details and use only experiences you can defend.
Self-review against observable evidence
This is a coaching checklist, not a company hiring score. Choose one rating per dimension.
Review each dimension to choose one concrete improvement for your next attempt.
Next exercise
Rewrite the disagreement from the other person’s perspective in three sentences, then rehearse your answer.
If you cannot make their position sound reasonable, gather more context or choose another story. Finish by naming the evidence that could have changed your own view.