Question and when it applies
Tell me about a time you worked closely with someone whose work style was very different from yours. Explain the shared goal, the difference that actually affected the work, how you verified the problem, what each person changed, and what happened to both the delivery and the working relationship.
This behavioral question applies to engineering, product, data, design, operations, project management, and people-management roles. Its core competency is collaboration across work styles: can the candidate replace “we did not click” with observable differences in pace, communication, planning, evidence, decisions, or handoffs, then design a working interface both people can follow?
The story does not need a dramatic conflict. Two people may respect each other while one prefers written alignment before execution and the other prefers live exploration, causing repeated rework. A story mainly about persuading the other person to accept a technical proposal fits a disagreement or influence question. This question requires both people to change how they collaborate toward a shared result.
The sample later is entirely fictional. Six weeks, forty accounts, two days, three instances, one instance, four hours, and every result figure are replaceable sample data. Readers must substitute facts, authority, and evidence from their own experience rather than present the sample as personal history.
What the interviewer evaluates
First, can the candidate describe the difference in neutral behavioral terms? “They were unreliable” and “I was more professional” are character judgments. “I prepared a decision record before review; they explored options live in meetings” gives usable information. A strong answer also recognizes where each approach was effective.
Second, did the candidate investigate constraints before assigning motives? Time zones, responsibilities, information sources, risk tolerance, and prior experience can shape work habits. The candidate should ask and observe, without diagnosing personality or introducing stereotypes about culture, age, or identity.
Third, did the candidate alter personal behavior? Requiring the other person to adopt only your templates, meetings, and cadence demonstrates compliance management. Collaboration preserves useful strengths on both sides and produces specific bilateral changes.
Fourth, did the pair build an operating interface? A strong answer states when work is asynchronous or synchronous, who decides, where decisions are recorded, what a handoff includes, when silence triggers escalation, and when the agreement is reviewed. “We communicated more” cannot be tested.
Fifth, does the result cover the task and the relationship? An on-time launch proves only that the project finished. Rework, waiting, escalation, independent coordination, or later collaboration should also improve. Do not claim the other person “felt happier” without explicit feedback or observable behavior.
Finally, did reflection produce a reusable method? A mature answer does not impose this one agreement on everyone. It retains the rule: identify the consequential difference, then design the smallest interface proportional to the work's risk.
Questions to clarify before answering
- Did the shared result require interdependence? Parallel solo work provides little collaboration evidence. Choose a story with shared decisions, inputs, or handoffs.
- Which behavior differed? Separate channel, response cadence, planning depth, feedback style, risk judgment, and decision recording. Keep only differences that caused waiting, misunderstanding, or rework.
- Was this a preference, a skill gap, or unclear accountability? Preferences can use a negotiated interface; a skill gap needs support or training; unclear ownership needs an owner. Do not disguise performance problems as style differences.
- What authority did you have? Peers can agree on their working interface; a manager may also change responsibilities. Without that authority, propose an experiment and ask the accountable owner to confirm broader changes.
- How risky was the work? Reversible discovery can favor live experiments. Customer, money, safety, or hard-to-reverse decisions require stronger written evidence, approval, and checkpoints.
- What strength did each style contribute? If the story proves only that your approach was correct, it is a correction story. Identify the speed, context, detail, or relationship advantage the other person brought.
- What evidence would show improvement? Pick one delivery signal and one collaboration signal, such as milestone completion plus rework count, or blocked time plus later independent coordination.
- What can be shared safely? Remove names, health information, protected identity, customer identifiers, and internal ratings while preserving the task, behavior, choice, and result.
A 30-second answer framework
“On [project], [role] and I jointly owned [outcome]. I preferred [behavior A], while they preferred [behavior B]; at [specific decision or handoff], that produced [observable impact]. I confirmed the pattern using [facts], asked how they worked most effectively, and explained my risk need. We tested [synchronous rule], [asynchronous record], and [escalation condition]. I changed [my behavior], while they agreed to [their change]. The result was [real delivery result] and [real collaboration evidence]. I learned to translate style into behavior, then build the smallest interface proportionate to the task risk.”
Use STAR(R). Situation establishes the shared result and failed interface. Task defines your responsibility and authority. Action should dominate, covering diagnosis, conversation, bilateral changes, experiment, and review. Result includes task and collaboration evidence. Reflection explains what you now do earlier.
Practice one spine sentence: “We approached X differently, so interface Y failed; I did not ask them to become like me, but jointly built Z and tested it with Q.” If X, Y, Z, and Q remain vague, the story is not ready.
Step-by-step deep answer
Step 1: Choose a story with difference, dependence, and change
List the shared outcome, your input, their input, and the decisions you had to complete together. A useful story includes observable friction: a verbal requirement was not captured, a document received feedback too late, or a fast experiment bypassed a high-risk check.
Avoid a story whose only purpose is proving the other person was difficult. You must be able to say where their approach worked better and what you changed. If both answers are “nowhere” and “nothing,” choose another event.
Step 2: Replace labels with behavior and impact
Write, “When A occurred, I observed B, which caused C.” For example: “After two reviews, the implementation differed from the meeting decision, creating two days of rework.” That is more precise than “they were too informal” and leaves room for competing explanations.
Separate fact from inference. No decision record after the meeting is a fact; disrespect for process is an inference. Bring the fact into the conversation and remain open to time pressure, incomplete information, or a communication barrier.
Step 3: Understand both sets of needs and constraints
Ask privately: “At which stage does live discussion help you most? Which decisions deserve a record? What makes my document hard to use?” Then explain your own needs, such as traceability for a risky change or a stable version for asynchronous collaborators.
Restate their view and invite correction. The goal is a map of what each person protects across speed, clarity, and risk. Do not decide whose process wins before creating that map.
Step 4: Co-design the smallest working interface
Add mechanisms only at the failed interface. Ambiguous issues might start with a short call, while high-risk decisions receive a short record. Each handoff can name an owner, due time, and acceptance condition. Silence triggers escalation only after an agreed interval, and the pair reviews the agreement after a week or milestone.
Use both people's strengths. Live discussion preserves discovery speed; a concise record protects execution. Shorten the template if documentation becomes the bottleneck. Limit participants and exit criteria if short calls keep expanding.
Step 5: Name bilateral changes and decision authority
Attribute contributions precisely. You might replace a long document with a five-point decision note and initiate a call when ambiguity is real. The other person might mark facts, assumptions, and open decisions after customer conversations. Credit a team lead if that person approved ownership or schedule changes.
Bilateral adaptation does not mean splitting every difference halfway. Responsibilities and policy govern high-risk controls. Preferences can be tested for a lower-cost combination, but required controls do not disappear for harmony.
Step 6: Test the agreement instead of declaring alignment
Time-box the agreement and choose observations. Across the next two milestones, track waiting, rework, and unresolved decisions, then ask each person which rule helped and which added unnecessary load.
If delivery speeds up because one person absorbs all coordination, the agreement is not sustainable. If the relationship improves while key decisions still disappear, the task interface remains broken. Retain effective rules, remove ritual, and redesign when risk changes.
Step 7: Prepare boundaries, failure, and reflection
If the first conversation failed, explain the evidence of failure and how you used more specific examples or asked an accountable owner to clarify boundaries. If the difference exposed performance, harassment, or safety concerns, move to the relevant formal process rather than framing it as a style negotiation.
Make reflection change your next action: ask about communication and decision preferences at project kickoff, or discuss the interface after the first rework rather than waiting for a strained relationship. This demonstrates a method, not a generic lesson about patience.
High-quality sample answer
“The following example is entirely fictional, and every number is replaceable sample data.
A product manager and I jointly owned a migration of forty accounts to a new billing flow within six weeks. I preferred documenting boundaries and decisions before implementation. He was strongest when he could gather fresh customer context and iterate in a live discussion. After our first two reviews, we interpreted the meeting outcomes differently, and the engineering team spent two days on rework. I was accountable for migration safety without allowing process to delay customer feedback.
I verified that both rework cases followed verbal decisions with no named owner or acceptance condition. In a private retrospective, I described those examples instead of calling his style chaotic and asked what live discussion solved for him. He explained that long documents became stale as customer information changed. He also pointed out that I often invited him only when my document was nearly complete, making feedback expensive. I acknowledged that part of the problem.
We tested an agreement for two milestones. An ambiguous issue started with a fifteen-minute call. The proposer then wrote no more than five decision bullets with an owner and due time. Decisions affecting billing correctness needed both of us to confirm before execution. An ordinary blocker escalated only after four hours without a response. I replaced a complete proposal with an early one-page draft and initiated a live discussion when disagreement remained. He labeled customer-call notes as facts, assumptions, or open decisions.
Six weeks, forty accounts, fifteen minutes, five bullets, and four hours are all sample data. The fictional result was an on-schedule migration, rework declining from three cases to one across the final two milestones, and no detected priority billing defect. He later initiated the concise decision-note pattern on another project. Three, one, and the defect result must also be replaced with real evidence.
I learned to address a work-style difference at the first observable rework. Next time, I will ask about communication, decision, and handoff preferences at the start of joint work, then test the smallest agreement instead of assuming others will adapt to my process.”
To replace the sample, create four fact boxes: different behaviors, shared interface harmed, change by each person, and two kinds of result evidence. Remove unverifiable descriptions of motives. When numeric evidence is unavailable, use truthful evidence such as milestone completion, whether rework recurred, or whether the agreement was independently reused. Do not invent a percentage.
Common mistakes
- Calling the other person difficult or chaotic → a character label offers no judgment evidence and can reveal bias → describe the behavior, context, and work impact.
- Proving only that your style was more professional → no adaptation or complementarity appears → name where their style worked and what you personally changed.
- Summarizing Action as “we communicated more” → the operating change cannot be inspected → state channels, triggers, owner, record, and review.
- Turning an ordinary difference into a dramatic conflict → manufactured drama hides the competency → retain the real friction and consequence without creating a villain.
- Treating performance or misconduct as style → preference negotiation cannot fix skill, accountability, or safety issues → recognize the boundary and use support, accountability, or formal escalation.
- Reporting only an on-time delivery → one person may have absorbed all coordination → add evidence about rework, waiting, independent collaboration, or explicit feedback.
- Claiming the other person's feelings → “they were happier” is usually unverifiable → use shareable direct feedback or observable later behavior.
- Borrowing the sample figures → fabricated achievement destroys credibility → cross-check project records, reviews, tickets, and your own memory.
Follow-up questions and responses
Follow-up 1: What did you personally do?
Break the work into observe, ask, design, execute, and review, while separating team decisions. Name the facts you brought, the behavior you changed, the mechanism you maintained, and what the other person or accountable lead did. Do not convert every “we agreed” into personal credit.
Follow-up 2: What was the hardest tradeoff?
Describe the concrete choice among speed, clarity, and risk. Long documents for every discussion can delay exploration; purely verbal decisions can damage traceability. A defensible agreement may require confirmation only for high-risk decisions and use concise notes elsewhere. State when that threshold would fail.
Follow-up 3: What if the other person refused to adapt?
First test whether your request is specific, affordable, and paired with your own change. Propose a time-boxed experiment measured by the shared result. If critical accountability still cannot be met, bring facts, impact, and options to the accountable owner for an interface decision. Do not use escalation to force a personal preference.
Follow-up 4: What failed in your first attempt?
Choose a real shortcoming: the first template was too long, a short meeting lacked a decision owner, or the review measured delivery but missed coordination load. Explain how you detected it, which rule you changed, and what limitation remained. A story with no failed attempt or adjustment can sound polished beyond reality.
Follow-up 5: Would you compromise if the difference involved security or compliance?
Do not negotiate a required control as a preference. Confirm responsibility, policy, and the risk owner. You may change the format, meeting mode, or feedback timing, while required approval, separation of duties, or audit records remain. Pause the affected action and escalate if safe collaboration is impossible.
Follow-up 6: How did this change your later behavior?
Give evidence of reuse: on later work, you asked about preferences at kickoff, recorded high-risk decisions, reviewed after the first milestone, and removed unnecessary rules for that task. If no later opportunity exists, state the future trigger and check without inventing an outcome.