Automated enforcement of deprecated component removal

WHAT THIS TESTS The interviewer wants a governance pipeline that scales beyond polite warnings. The hard part is preventing new usage while smoothly retiring existing usage, all without grinding consumer teams to a halt.

A GOOD ANSWER COVERS Layer the enforcement. First, an ESLint rule (or a similar linter for non-JS stacks) detects imports of the deprecated component; configure it as a warning initially, then escalate to an error so CI blocks new pull requests that add usage. Second, ship a codemod, for example a jscodeshift transform, that rewrites existing call sites to the replacement automatically, handling prop renames. Third, feed a central usage dashboard from the static scans so you know who still depends on it. Fourth, gate the actual deletion: only flip the lint rule to a hard org-wide error and remove the component once dashboards show usage near zero, with a published timeline and an escape hatch for genuine blockers.

COMMON WRONG ANSWERS Making the CI gate a blocking error immediately, which breaks unrelated builds and breeds resentment. Providing no automated migration, forcing every team to hand-edit. Enforcing only locally so the rule is easily bypassed.

LIKELY FOLLOW-UPS How do you handle a team that legitimately cannot migrate in time? How do you prevent developers from disabling the rule? How do codemods handle ambiguous prop mappings?

ONE CONCRETE EXAMPLE You publish an ESLint plugin rule no-legacy-card set to warn, plus a codemod npx ds-codemod legacy-card-to-card. CI runs the linter and fails only on newly added usages while existing ones stay as warnings. The adoption dashboard tracks the burndown; when it hits zero, you promote the rule to error everywhere and delete LegacyCard in the next major release.