All jobs / Project / delivery manager

Quality interview questions

Quality questions a Project / delivery manager can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. A ticket is “dev done” but not in the build the user can touch. Is it done?

    The strongest answer: No — done means the slice meets the team’s definition and is in a build someone can use, not that a branch exists

    Why it works: Exactly. Done is shippable against a shared bar. A branch is work in progress.

    • Done = the shared bar, in a usable build.
    • A branch is not done.
    • Review is a step, not the bar.
    • Do not move cards to decorate a chart.

  2. What is the difference between the Definition of Done and a story’s acceptance criteria?

    The strongest answer: The Definition of Done is the same for every item — tested, reviewed, deployed, whatever the team agreed; acceptance criteria belong to one item and say what it must do; a story needs both

    Why it works: Exactly — one is the team’s quality bar, the other the item’s behaviour; confusing them is how “it passes AC” becomes “done” without tests.

    • DoD is universal, AC is per item.
    • DoD: the team’s quality bar.
    • AC: what this story must do.
    • A story needs both.

  3. One sprint before go-live, the bug list has fifty open defects.

    How do you run defect triage?

    The strongest answer: With product, QA and the tech lead I rate each by severity and priority, decide what blocks release, and mark the rest fix-later or won’t-fix explicitly — the known issues that ship are published

    Why it works: Right — triage is a decision per defect with the people who understand impact, and the honest part is publishing what ships broken.

    • Severity, priority, decision.
    • Triage with product, QA, tech lead.
    • Name what blocks release.
    • Publish known issues that ship.

  4. “Done” now means “merged” and tests are “if we have time.” What do you do?

    The strongest answer: I put the erosion on the board and I ask which part of done we are choosing to drop in the open — I do not let the bar fade in silence

    Why it works: Exactly. A fading bar is a decision. Make it explicit or restore it.

    • Make the fade visible.
    • Choose in the open.
    • Do not add fields instead of a talk.
    • Do not police by humiliation.

  5. Cards jump to Done on Friday afternoon and return to In Progress on Monday. What do you do?

    The strongest answer: I treat it as a board-honesty problem: we stop the Friday flush and we say what done actually requires — I do not celebrate the Friday chart

    Why it works: Exactly. A Friday flush is a lie. Fix the bar and the incentive, not the weekday.

    • Stop the Friday flush.
    • Restate what done requires.
    • Do not celebrate the chart.
    • Do not move the flush to Thursday.

  6. Testers receive finished stories in the last two days of every sprint, and something always spills.

    What do you change?

    The strongest answer: I move quality left: testers join refinement and write tests with the acceptance criteria, stories are sliced small enough to test the day they are built, and testing is everyone’s work, not a final stage

    Why it works: Exactly — the late-testing pattern is a slicing and collaboration problem; a test phase at the end just moves the queue.

    • Test alongside, not after.
    • Testers in refinement.
    • Slice to testable-in-a-day.
    • Quality is the whole team’s job.

  7. The business sponsor wants a four-week user acceptance testing phase after development “to make sure it works.”

    What is your view?

    The strongest answer: Acceptance should be continuous — business users in every review, testing slices as they land — so the final UAT is a short confirmation; if a formal sign-off is required, keep it thin and rehearsed

    Why it works: Right — a long UAT at the end is a sign the users were absent for months; bring them in early and the phase shrinks on its own.

    • Accept continuously, confirm briefly.
    • Business users in every review.
    • Test slices as they land.
    • Final UAT: short and rehearsed.

  8. You inherit a programme with eight hundred open defects, some three years old, and a quarterly “bug bash” nobody believes in.

    What policy do you set?

    The strongest answer: Every new defect is triaged within days and either scheduled or closed with a reason; the old pile gets the same rule in a time-box, and the age of open defects becomes a visible metric

    Why it works: Exactly — a defect policy is a flow rule: decide fast, keep the queue honest, watch the age; a one-off purge refills within a year.

    • Decide fast, watch the age.
    • Triage every new defect quickly.
    • Schedule or close with a reason.
    • Make defect age visible.