The Junior QA Interview

Junior QA interviews are unusually predictable: a vocabulary check, a live test-design exercise, a bug-report critique, and a scenario or two. You have spent eleven chapters preparing for exactly this — this topic just turns the book into the answer key. The driving-test analogy is apt: the examiner's route is famously predictable (parallel parking will appear), and predictability doesn't make it easy — it makes it preparable. Unprepared candidates fail predictable tests every day; you won't be one.

The Classic Questions, Mapped

The greatest hits, each with its home chapter and the shape of a strong answer — which is always definition + example + the distinction that shows depth. "QA vs QC vs testing?" (1.2) — the nesting dolls: testing is the activity, QC checks the product, QA improves the process. "The seven testing principles?" (1.3) — name a few and land Principle 1 (presence not absence) and Principle 2 (exhaustive is impossible). "Severity vs priority?" (6.3) — the corner example carries it: the homepage typo, low severity and high priority. "Test levels?" (3.1) — unit/integration/system/acceptance, and who owns each. "Regression vs re-testing?" (3.4) — re-testing confirms the fix, regression hunts collateral damage; FW-312/FW-329 as the story. Notice the pattern: a bare definition is a pass; a definition plus a memorable example plus the distinction is what gets remembered.

"How Would You Test This?"

The live exercise, and the one that separates trained candidates most sharply. They hand you a login form, a vending machine, an elevator — and the winning structure is Chapter 4 out loud. Step one, and the step beginners skip: clarify the requirements first ("what are the rules? what's a valid password length? what should happen on the third wrong attempt?") — Chapter 2's move, and it signals you test against a spec, not a guess. Then walk the techniques aloud: partitions (valid, invalid, empty, wrong-type), boundaries (the edges of every rule), state transitions if it has a lifecycle, and a non-functional sweep (Chapter 3.2: what about slow networks, accessibility, security?). You're not expected to be exhaustive — you're expected to be systematic, thinking in visible categories instead of scattering random cases. The interviewer is watching for the structure, and now you have it cold.

The Critique Round

They show you a bad bug report — title "login sometimes broken," no steps, no environment — and ask what's wrong. This is Chapter 6's anatomy as a scoring rubric: no reproduction steps, no environment or build, a vague "sometimes" that should state a frequency, no expected-vs-actual, no evidence. Naming the missing fields is the answer. Same drill for a vague test case ("apply promo, check it works"): Chapter 5's diagnosis — the expected result isn't verdict-grade, two people could disagree on pass/fail. The critique round rewards knowing what good looks like well enough to name every way something falls short of it.

Scenario Questions

The pressure round, and each has a principled answer you now own. "Release is tomorrow and you found a major bug — what do you do?" (7.4) — inform, don't decide: present the picture (impact, severity, the risk of shipping), and let the team make the call; you're the weather briefing, not the pilot. "A developer says it's not a bug." (6.1) — route to the source of truth, not the person: "let's check what the story says" — escalate the requirement question, never the ego. "You don't have time to test everything." (7.1) — risk-based, out loud: rank by impact × likelihood, cover the top tiers fully, name what you're cutting and the risk it adds. Notice all three answers share a spine: calm, evidence-based, and clear about what you own versus what the team owns. That spine is what "senior thinking in a junior" looks like.

The Questions You Ask Them

Interviews run both ways, and a junior who interviews the team stands out. Ask what reveals a healthy QA culture: "Does QA join refinement, or come in at the end?" (Chapter 2 — the answer tells you if testing is respected). "Who owns the release decision?" (Chapter 7 — hoping to hear "the team," not "QA gets blamed"). "What's the automation story — and is it trusted?" (Chapter 9 — a red-but-ignored pipeline is a red flag about the whole team). The wrong answers are real warnings: QA-as-gatekeeper, testing-as-afterthought, an ignored pipeline. You're choosing an employer too, and the questions that show you know what good looks like also protect you from a bad first job.

The Mock Interview

The book's final worked example: a compressed mock transcript, annotated with the chapter each answer draws from.

Q: What's the difference between severity and priority?
A: Severity is technical impact, priority is business urgency. They
   split — a typo in the homepage headline is low severity but high
   priority, because it embarrasses the brand.            [Ch 6.3]

Q: How would you test a login form?
A: First I'd clarify the rules — password length, lockout after N
   failed attempts. Then partitions: valid, too-short, empty, wrong
   type. Boundaries at the length limits. State: locked-out after
   failures. And a non-functional pass — slow network, a screen
   reader, and I'd check the API accepts what the UI rejects.  [Ch 2, 4, 8]

Q: We release tomorrow and you find a major bug. What do you do?
A: I present the picture — what breaks, severity, the risk of
   shipping — and let the team decide. QA informs the call; it
   doesn't own it.                                          [Ch 7.4]

Q: Have you used k6?
A: I haven't hands-on — it's a load generator for performance
   testing. I've read how it simulates virtual users, and I pick
   up new tools in the same category quickly.        [honest unknown, Ch 9/10]

Study the last answer. "I don't know X, but here's what it is and how I'd get up to speed" — the honest-unknown move — routinely outscores a bluff, because the bluff collapses under the follow-up and the honest version demonstrates category-thinking and coachability in one breath. No junior is expected to know everything; every junior is expected to handle not-knowing like a professional. Rehearse that move as deliberately as the definitions — it's the answer that turns a gap into a point.