Essential docs for onboarding a new team

WHAT THIS TESTS The interviewer wants documentation that makes the system self-serve, reducing the support burden and speeding adoption. They are listening for specific document types and concrete contents, not a vague say it should be documented.

A GOOD ANSWER COVERS A getting-started guide: installation, setup, theming and provider configuration, and a first-component walkthrough so a team ships something in minutes. Per-component reference pages: the API with all props and types, variants, states, live interactive examples, and copy-paste code snippets. Usage guidance: do and don't examples, when to use this component versus an alternative, and accessibility notes covering keyboard and screen-reader behavior. Design foundations: design tokens, color, typography, spacing, elevation, and grid, with the rationale behind them. Contribution and support docs: how to report bugs, request components, and contribute. Finally, a changelog and migration guides so teams understand what changed between versions and how to upgrade. Hosting it all in a living site like Storybook or a docs portal keeps examples runnable and in sync with code.

COMMON WRONG ANSWERS Shipping only auto-generated prop tables with no usage context, examples, or rationale. Static screenshots that drift from the real components. No accessibility guidance. No changelog, so teams cannot tell what changed.

LIKELY FOLLOW-UPS How do you keep docs in sync with code? What is the single most important doc for adoption? How do you document tokens?

ONE CONCRETE EXAMPLE A new team opens the Storybook portal, follows the getting-started page to install and wrap their app in the ThemeProvider, browses the Button page with live variants and code snippets, reads the do-and-don't usage notes and keyboard behavior, and checks the changelog before upgrading, all without messaging the core team.