A retailer validates and stores a customer delivery address in three places: checkout, the logistics planner, and support tooling. Each implementation is defensible on its own terms and each team resists change. About 3% of orders fail first-time delivery for address-quality reasons. Walk me through how you would approach this.
Show the full answer Hide the answer
What the interviewer is testing
Whether you reach for a structural programme or for evidence. Three implementations of one capability is a familiar sight, and duplication is not by itself a defect — plenty of duplicated logic is cheap and stable. The judgement being tested is whether you can tell an expensive duplication from a tolerable one, and whether you know that the answer here is an ownership decision before it is a technical one.
The clarifying questions that change the answer
- How often do the three disagree? Take 1,000 recent orders and run all three implementations over them. Agreement above roughly 99% means the duplication is cosmetic and should be left alone. Disagreement at 5% means you have a correctness problem that the duplication is causing.
- Which of the three currently decides whether a delivery is attempted? That one is the de facto authority, whatever the documentation says.
- What does a failed first-time delivery cost? With an assumed £6 to £9 per redelivery — use the operation's real figure — 3% of 200,000 monthly orders is 6,000 failures, roughly £40,000 to £55,000 a month, which is the budget the work has to earn against. This estimate is the single most useful thing to establish in the first meeting.
- Is address quality actually the cause, or the recorded reason code? Courier reason codes are notoriously coarse and a sample of 50 cases will tell you.
A strong answer's arc
- Measure disagreement, not duplication. The number decides whether this is a tidying exercise or a business problem.
- Assign authority per field, not per capability. Normalised postal address, geocode and deliverability verdict are three different facts with three different best owners. One team owns each fact and publishes it; the others consume and may cache but not overrule. This is achievable in a quarter, where "one address service" is a two-year programme.
- Change the read path first, the write path last. Consumers read the authoritative value alongside their own and log the differences for a few weeks. The log is both the safety net and the evidence for switching.
- Leave the checkout implementation in place if latency on the order path is the reason it exists. A synchronous dependency added to checkout needs its own SLO and fallback, and a cached authoritative dataset usually beats a live call.
- Publish one number monthly — first-time delivery success — and attach it to the owning team. Without that, the fix decays back to three implementations within a year.
Common weak answers
- "Build a canonical customer model and make everyone use it." The largest and slowest available answer, and it fails on the same rock every time: the three teams need different fields at different freshness, and the model becomes a committee.
- "Start a master data management programme." Sometimes the right conclusion, usually reached before the disagreement rate is known, and it spends a year before the delivery failure rate moves.
- "One address service for everything." Perfectly reasonable if latency, availability and ownership are worked through. Weak when proposed without a plan for the checkout path, because that is the one place where an extra network call is measured in abandoned baskets.
What a strong answer adds
The organisational half. Authority per field only holds if the owning team is funded and measured on the fact it owns, otherwise other teams' overrides return within two release cycles. Say who signs the decision, what happens on disagreement, and how you would notice it decaying: a monthly diff count between authoritative and local values, alerting when it crosses a threshold.
And name the case where you would do nothing. If agreement is 99.5% and the delivery failures turn out to be courier capacity rather than address quality, the correct architectural recommendation is to leave three implementations alone and go and work on the real cause. Consolidation that fixes nothing still costs a quarter and burns the credibility you need for the next proposal.