TL;DR: Commit, build once into an immutable artifact, test in widening circles, scan, publish, then deploy that same artifact through environments with a gate at each. The part that separates answers is naming what fails each stage and what the whole thing costs in minutes.
How to approach it
Give the stages in order, and for each one say what it produces, what stops the pipeline there, and roughly how long it takes. Interviewers hear the noun list constantly, so the timings and the failure conditions are what make it sound like something you have operated. Have a real pipeline in mind and use its numbers.
A strong answer
Trigger. A push to a branch or a pull request opens. Pull requests run the full check set; merges to the default branch additionally publish. Nothing runs on a schedule except the nightly integration suite and dependency updates.
Build. Compile, resolve dependencies from an internal proxy rather than the public registry, and produce one artifact: a container image, a jar, a binary. It is built once here and never rebuilt, because an environment that rebuilds is running bytes that were never tested. Tag it by commit SHA and refer to it by digest afterwards.
Test, in widening circles. Unit tests first because they are seconds and catch most things. Then integration tests against real dependencies in containers, which is where the minutes go. Contract tests if services are versioned independently. End-to-end last, kept deliberately small, because a hundred browser tests is forty minutes of flake.
Static analysis and security. Linting, then SAST for code patterns, dependency scanning for known CVEs in what you pull in, a secret scanner so a committed key fails the build, and an image scan on the built layers. These run in parallel with tests rather than after, since none of them depends on the test result.
Publish. Push the image to the registry, record the build: commit, toolchain version, test results, scan results, digest. That record is what answers "what is in production" later.
Deploy to a lower environment, automatically, on every default-branch build. If it cannot deploy to staging without a human, it is not continuous anything.
Deploy to production, with a gate. Approval, a change record, or an automated canary that promotes itself on metrics. The same digest that staging ran, with configuration injected at runtime rather than baked in.
Verify. Smoke tests against the real environment, then watch error rate and latency for a defined window with an automatic rollback if they move. A deploy that reports success because the pipeline step exited zero has verified nothing.
The number I would put on it: under ten minutes from push to a pull request result, because past that developers stop waiting and start context switching, and the feedback loop you were buying is gone. Production deploys can be slower since they are progressive by then.
What interviewers probe next
"What is the difference between continuous delivery and continuous deployment?" Delivery means every build is provably releasable and a human decides when. Deployment means it goes automatically with no human. Most regulated environments run delivery, and saying which one you ran is more useful than reciting both definitions.
"Where would you put a database migration?" Its own step, before the deploy for an additive change and well after for a destructive one, never bundled into the same release as the code that needs it. Otherwise rollback stops working.
"How do you keep it under ten minutes as it grows?" Cache dependencies on a content hash, split tests across runners by recorded duration rather than file count, and only build and test what a change actually affects.
Common mistakes
Reciting stage names with no failure conditions or timings, which is the answer everybody gives.
Rebuilding per environment, so production runs an artifact that was never tested.
Putting security scanning at the release gate instead of on every pull request, which turns every finding into an argument on the last day.
Claiming the pipeline deploys to production when it actually stops at staging and somebody runs a script.