Walk me through the lifecycle of a defect from discovery to closure.

A defect's life maps to a state machine; most bug trackers (Jira, Linear, Bugzilla) implement a variant of:

1. New / Open — the defect is logged with title, environment, repro steps, severity, and evidence. At this point it hasn't been triaged.
2. Triaged / Assigned — a reviewer (often a tech lead or PM) validates the report, sets priority, and assigns it. Either the defect becomes a work item or it's rejected with reasoning ("works as designed", "duplicate").
3. In Progress — a developer is actively fixing it: reproducing, root-causing, writing the fix plus tests.
4. Fixed / Resolved — the fix is merged. The developer's work is done but QA hasn't verified.
5. Ready for Test / In QA — the fix is on a build a tester can validate.
6. Verified / Retested — QA has run the original reproduction (retest) and exercised regression around the change.
7. Closed — permanently resolved.

Branches off the main path: Rejected (not a bug — works as designed, can't reproduce, duplicate; should always carry an explanation), Deferred / Won't Fix (acknowledged but not fixed in this release), Reopened (verification failed; the original issue persists or returned, goes back to In Progress).

Two practical interview points: closed isn't always the end (some teams keep "closed" defects for trend analysis like injection rate and mean-time-to-fix), and the hand-offs are where defects rot — "fixed but waiting for build" and "ready for test but no tester assigned" are the stages where bugs lose days. A senior engineer cares about cycle time as much as resolution.