Prompt and context
Tell me about a time you and a dependent team disagreed about an API contract. They believed your proposal would add maintenance cost, while you feared leaving the contract unchanged would hurt reliability. How did you clarify facts, decide, and deliver?
This question tests cross-team collaboration, technical trade-offs, and influence. Atlassian’s engineering interview guide explicitly looks for problem solving, learning agility, collaboration, and communication. A strong answer shows real constraints, verifiable evidence, a shared decision, and an outcome rather than describing the other team as an obstacle.
What the interviewer is testing
The interviewer wants to know whether you can turn disagreement into a shared goal, separate facts from preferences, explain compatibility, reliability, cost, and schedule trade-offs, record decisions and ownership, and change course when evidence changes. They also watch whether you protect the dependent team’s delivery pace.
Clarifying questions
Confirm the API consumers, version, SLO, data sensitivity, release window, and unacceptable failures. Identify whether the disagreement concerns field semantics, error contracts, compatibility duration, or operational ownership. Prepare logs, traffic, failure samples, migration effort, and rollback conditions that both teams can verify.
30-second answer
“I first reframed the disagreement as a shared goal: meet reliability and maintenance constraints inside the release window. I separated known facts, assumptions, and unknowns and invited the dependent team to validate them. We compared compatibility, observability, migration, and rollback costs, then used a small reversible test to reduce uncertainty. Finally we recorded the decision, owner, deadline, and rollback signals. After delivery, we checked the outcome and turned the lesson into a reusable template.”
Deep-dive answer
Step 1: Align on user and service goals
Do not start with which field design is correct. Write down user impact, reliability targets, release timing, and maintenance boundaries so both teams optimize the same outcome. If goals conflict, identify who owns the product or architecture trade-off.
Step 2: Separate facts, assumptions, and preferences
List actual call volume, failure rate, compatible clients, migration effort, and support window. Label claims without data as assumptions and schedule a reversible check. Do not use seniority, team size, or volume of speech as evidence.
Step 3: Compare contract options
Compare the current contract, the smallest compatible change, and the long-term design. For each, record field semantics, error codes, versioning, observability, performance, maintenance, and rollback. Have the dependent team fill in its costs so the discussion is not “you are asking me to change.”
Step 4: Design a reversible experiment
Start with optional fields, dual writes, shadow traffic, or consumer contract tests and observe real results. Give the experiment a time box, success measures, and stop conditions; do not let a compatibility layer live forever.
Step 5: Decide and record
Write the context, options, rationale, risks, owners, deadline, and rollback triggers in an ADR or project record. People may retain dissent, but they should know when the decision will be revisited.
Step 6: Protect the dependent team’s delivery
Provide migration examples, test fixtures, a compatibility window, and joint integration time. If your change adds work, state what support you own; do not silently push unfinished migration responsibility to consumers.
Step 7: Manage rollout risk with metrics
Define error rate, latency, unknown-field rate, rollback time, and consumer success before release. Expand traffic in stages and pause or roll back when thresholds are crossed instead of waiting for blame.
Step 8: Learn and change the system
Check whether results matched assumptions and record which evidence changed the decision. Add contract templates, review checklists, compatibility tests, or a responsibility matrix to the process so the next disagreement appears earlier.
Model answer
During an order-status API migration, the consumer team feared that a new error hierarchy would increase client maintenance, while I feared that vague errors would amplify retries during a failure. We aligned on keeping the release window while distinguishing retryable from non-retryable states. We reviewed 30 days of error samples, client versions, and retry volume and found that two states caused most of the risk. We added backward-compatible fields first and used contract tests and shadow traffic. I owned the example SDK, migration guide, and dashboard; the other team owned two high-volume clients. The ADR recorded owners, two pause signals, and rollback. We ramped gradually, saw fewer duplicate requests, and found no old-client parsing failures. The retrospective added the error-contract template to review. The decision came from shared metrics and reversible steps, not from forcing my preference.
Common mistakes
Calling the other team technically weak
The dependent team usually knows consumer constraints. Dismissing it hides migration cost and does not demonstrate trust-building.
Describing only the final design
The interviewer needs to see how you compared trade-offs. Explain at least two options, the evidence, and why one was rejected.
Giving no measurable result or ownership
“Everyone agreed” is not an outcome. State metrics, time range, your work, and remaining risk.
Follow-up questions and answers
What if the other team still disagrees?
Check whether new facts changed the dispute, then ask the architecture or product owner named by the decision process to choose. Record dissent, risk, and a review date while delivering the smallest reversible step.
What if only two days remain before release?
Reduce scope, protect irreversible risk and critical consumers, and use compatible fields, a flag, or shadow verification. State what is deferred; do not substitute a verbal promise for rollback.
How do you show the design was not over-engineered?
Name the capabilities you removed, compare actual traffic and failure cost, time-box the compatibility layer, and plan its removal. Let evidence set complexity.
What if the data disproves your judgment?
Admit the assumption was wrong, update the ADR and thresholds, choose the safer path, and show how you shared the new evidence with affected teams.
How do you prevent the same disagreement recurring?
Turn contract, version, error, compatibility-window, and ownership decisions into a template. Add consumer contract tests and a release checklist with a short pre-code review.
How does this demonstrate influence rather than control?
Emphasize that you created a shared goal, evidence, and reversible decision while owning supporting work. The team chose the outcome; you did not overpower the other team.