Designing a component deprecation process

WHAT THIS TESTS The interviewer wants a humane, staged deprecation that respects consumers. They are listening for both technical signals and communication, plus a no-surprise removal policy tied to versioning.

A GOOD ANSWER COVERS Deprecation is a process, not a delete. First, decide and announce: publish the rationale, name the replacement, and set a removal timeline. Mark it technically while keeping it functional: add JSDoc deprecated annotations so IDEs flag it, emit a one-time console warning in development, add a lint rule that flags new usage, and put a banner on the docs page. Provide a migration path: a step-by-step guide and, where possible, an automated codemod that rewrites usages. Track remaining usage across consuming repos so you know who still depends on it. Communicate repeatedly through changelogs, release notes, and direct outreach to heavy users. Remove the component only in a major version once usage has dropped to near zero, never in a minor or patch.

COMMON WRONG ANSWERS Deleting the component immediately, breaking every consumer. Marking it deprecated but giving no replacement or migration tooling. Removing it in a minor release, violating SemVer. Announcing once and assuming everyone saw it.

LIKELY FOLLOW-UPS How do you handle teams that ignore the warnings? How do you measure remaining usage? When is it safe to actually remove?

ONE CONCRETE EXAMPLE You deprecate the old Modal in favor of Dialog. v3.2 adds a deprecated tag, a dev console warning, and a lint rule; you ship a codemod and a guide, and track that twenty repos still import Modal. Over two quarters usage drops to two repos; you help them migrate, then remove Modal in v4.0 with the breaking change documented.