First steps to deprecate a legacy component

WHAT THIS TESTS The interviewer wants to see whether you understand deprecation as a communication and migration problem, not just a delete operation. Senior engineers signal intent inside the code so consumers discover it where they work.

A GOOD ANSWER COVERS Start by adding a machine-readable signal: a @deprecated JSDoc or TSDoc tag on the component and its exported type, which most editors render with a strikethrough and a tooltip. Add a development-only console warning that fires once, naming the replacement and a doc link, while staying silent in production to avoid noise. Update the documentation site and Storybook to label the component deprecated and link a migration guide. Optionally ship an ESLint rule or codemod so teams get inline nudges and an automated upgrade path. Keep LegacyCard fully functional during the window and announce a target removal version.

COMMON WRONG ANSWERS Deleting the component immediately, which breaks every consumer at once. Only posting in chat, which leaves no durable trace in the code. Logging warnings in production, which floods user consoles and can hurt performance.

LIKELY FOLLOW-UPS How do you make the warning fire only once? How would you measure remaining usage before removal? When is it safe to actually delete the component, and how does that map to semantic versioning?

ONE CONCRETE EXAMPLE You add @deprecated Use Card instead. See /migration/card above the LegacyCard declaration, wrap a useEffect in the component that calls console.warn once per session in non-production builds, publish a minor version, then announce removal in the next major. Editors show the strikethrough, dashboards track adoption, and nothing breaks until the planned major release.