Roll out a breaking change to a core public API

WHAT THIS TESTS: This question probes whether you can act as a steward of a developer ecosystem rather than just a code owner. The interviewer wants to see that you understand a public API is a contract and that breaking changes create externalized costs for thousands of consumers. They are looking for a structured, phased approach that combines technical mechanisms with communication and operational tooling to minimize disruption and maintain trust.

A GOOD ANSWER COVERS: First, a versioning strategy that keeps the old contract available while the new one is adopted. Candidates should mention URI path versioning, custom request headers, or content negotiation, and explain why they prefer one for this scenario. Second, a deprecation policy with hard dates: announce the change twelve to eighteen months in advance, publish a sunset date, and define SLA commitments for bug fixes on the legacy version during the transition. Third, tooling to reduce friction, such as breaking-change detection in CI, automated migration guides, codemods or SDK generators, and canary deployments with traffic splitting to validate the new contract. Fourth, communication layers including embedded deprecation headers, changelog entries, email campaigns, in-dashboard banners, and dedicated support channels for migration questions.

COMMON WRONG ANSWERS: A major red flag is proposing an immediate hard cutover with no backward compatibility. Another is versioning every endpoint independently without a unified strategy, which fragments the developer experience. Some candidates focus entirely on technical routing and forget communication, treating the rollout as an infrastructure change rather than a product change. Others suggest maintaining every old version indefinitely, which creates unsustainable operational overhead and security debt.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle consumers who miss the deadline, forcing you to discuss extended support tiers or emergency compatibility shims. They might probe how you measure ecosystem health during migration, such as tracking adoption rate by API key or error rate spikes on the legacy version. Another follow-up is how to prevent future breaking changes through design-time governance like schema linting and consumer-driven contract tests.

ONE CONCRETE EXAMPLE: Suppose you are sunsetting a v1 REST API in favor of a v2 that uses a new authentication scheme and renames three core fields. Your strategy would be: launch v2 alongside v1 with a new base path, add deprecation warnings to all v1 responses with a link to the migration guide, release official SDKs that support both versions with clear upgrade docs, run a six-month brownout period where you temporarily disable v1 for five minutes each week to alert laggards, and finally enforce the sunset only after adoption metrics show fewer than one percent of traffic remains on v1.

Source: postman.com