Verification asks 'Are we building the product RIGHT?' — checking that work products conform to specifications (reviews, static checks) WITHOUT executing code. Validation asks 'Are we building the RIGHT product?' — checking the actual software meets user needs, by executing it (dynamic testing).
VERIFICATION is static and process-oriented: reviews, walkthroughs, inspections of requirements/design/code against specifications — done early, catching defects before execution and cheaply. VALIDATION is dynamic and product-oriented: executing the software (functional, system, UAT) to confirm it meets requirements and user expectations. Both are needed: verification ensures conformance to spec; validation ensures fitness for actual use (you could build exactly to a flawed spec — verification passes but validation fails). The 'building it right vs building the right thing' phrasing is a guaranteed interview line.
Reviewing the design doc against requirements (verification) confirms it matches the spec; running the built feature in UAT (validation) confirms it actually solves the user's problem — even revealing the requirement itself was wrong.
Explain verification vs validation with the classic phrasing and why you need both.