Purpose and key sections of CONTRIBUTING.md

WHAT THIS TESTS The interviewer wants to know whether you see documentation as an adoption lever. A good CONTRIBUTING file converts willing engineers into successful contributors and reduces the core team's support load.

A GOOD ANSWER COVERS The purpose: CONTRIBUTING.md is the canonical on-ramp that explains how to propose, build, test, and submit changes so contributions meet the bar without one-on-one hand-holding, while signaling the project welcomes outside help. The three most valuable sections. First, getting started and development workflow: how to clone, install, run Storybook and the test suite, and the branching convention, so anyone can get a working environment fast. Second, the contribution process and standards: how to file a proposal or RFC for new components versus a simple fix, coding conventions, naming, token usage, accessibility requirements, and the required tests and documentation. Third, review and release expectations: who reviews via CODEOWNERS, what CI gates must pass, the definition of done, and how versioning and release happen. Together these set expectations before a PR is opened.

COMMON WRONG ANSWERS Treating it as legal or licensing boilerplate. Listing vague aspirations like be respectful with no actionable steps. Omitting setup instructions, so contributors stall on environment problems. Forgetting accessibility and testing standards.

LIKELY FOLLOW-UPS How does this differ from the code of conduct? How do you keep it current? What belongs in a PR template versus CONTRIBUTING?

ONE CONCRETE EXAMPLE A new contributor reads CONTRIBUTING, runs the documented yarn install and yarn storybook, sees that new components need an RFC and that PRs must pass axe and visual tests with a CODEOWNERS approval, and opens a clean, expectation-matching PR on their first try.