Roll out a breaking change to a core public API
This tests risk management while evolving a public API contract. A strong answer covers versioning, phased deprecation with SLAs, migration tooling, and proactive communication. Red flag: proposing a hard cutover without sunset or migration support.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
When sunsetting a widely used public API version, which combination of actions best demonstrates ecosystem stewardship while maintaining operational sustainability?
- a.Launch v2 alongside v1 with a deprecation timeline, migration tooling, and a brownout period, then sunset v1 once adoption drops below a defined threshold.Correct
- b.Maintain every legacy version indefinitely to guarantee zero disruption, accepting the operational cost as the price of reliability.
- c.Apply independent versioning to each endpoint and communicate changes solely through deprecation headers in API responses.
- d.Deploy v2 to a new base path, immediately decommission v1, and redirect all requests to the migration guide.
Why? this is the answer
Launching v2 alongside v1 with clear deprecation, migration tooling, and a metric-driven sunset balances ecosystem care with operational reality. Maintaining every old version indefinitely is tempting for zero disruption but creates unsustainable overhead and security debt according to the card.
Just read this? Test yourself on what you have been reading.
Read the original → postman.com
- #api versioning
- #developer relations
- #deprecation strategy
- #product strategy
- #ecosystem management
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles