Walk me through how a single change travels from an idea to production in an org you would design from scratch.

I describe it as a chain, because the interview is really asking whether I own the whole lifecycle or only the deployment.

1. The change enters a single prioritised backlog with an owner and acceptance criteria, so there is one place work is ranked.
2. A developer takes a short-lived branch from the mainline and builds in an isolated environment — a scratch org or a Developer sandbox, depending on how much of the org's metadata is genuinely in source.
3. They commit, open a pull request, and automation runs static analysis and the Apex test suite against the branch. A human reviews the diff.
4. On merge, the mainline deploys automatically into an integration environment where the streams meet, and the functional and integration suites run.
5. The release branch is cut on the published cut-off date, and it goes to a production-like staging environment for user acceptance testing and a full deployment rehearsal including the manual pre- and post-deployment steps.
6. The release is validated against production ahead of the window, then quick-deployed inside it. Post-deployment steps run from the runbook.
7. After go-live there is a defined heightened-monitoring period, and any emergency fix follows the hotfix path with a mandatory back-merge.

The two things I emphasise are that the repository is the source of truth at every step, and that the runbook of manual steps is version-controlled and rehearsed rather than remembered.