QA Interview Preparation
NZ QA interviews follow predictable patterns. The same 10 questions come up in 80% of roles. Knowing the right answer isn’t enough — knowing the right structure and the right level of detail for a NZ hiring context is what gets you the offer.
1 The Hook
A junior candidate gets three second-round interviews. She fails all three. Post-interview feedback from each: “good technical knowledge but couldn’t demonstrate real-world problem solving.”
In each interview, when asked “how do you test a login page?” she answered with a comprehensive 20-point checklist from memory. Boundary values, invalid characters, SQL injection, session management, CSRF, concurrent logins, password policy, forgotten password flow — everything. Technically correct. Impressively thorough.
What the interviewer wanted: 2–3 key risk areas, a specific example from her experience, and a question back to the interviewer about their specific context. She was technically correct but interviewer-context-deaf. The checklist showed she’d studied. The lack of conversation showed she hadn’t worked on a real team.
2 The Rule
NZ QA interviews are collaborative conversations, not examinations. Demonstrate thinking, show curiosity about their context, and anchor every answer to a real example.
3 The Analogy
A QA interview is like an exploratory testing session on a new application.
You’re testing the role and the team as much as they’re testing you. Bring your charter (preparation). Run your sessions (answers). Debrief at the end (questions for them). A tester who starts exploratory testing by immediately logging every edge case they know without understanding the application first isn’t a good tester. And a candidate who answers every question with a comprehensive list without engaging with the interviewer’s specific context isn’t showing that they’re a good tester.
Ask back. Every good answer to a QA interview question can end with: “In your context, how do you currently approach this?” It shows you’re curious, you’re collaborative, and you understand that context shapes testing decisions.
4 The 10 Questions — and What Good Looks Like
These come up in at least 80% of NZ QA interviews at all levels. The examples are grounded in realistic NZ contexts: Wellington government services, Auckland SaaS, NZ-specific payment flows.
“Walk me through how you’d test a login page.”
❌ Weak: lists 20 test cases. Shows study, not thinking.
✅ Strong: “I’d start with the risk areas — auth failure handling, session management, and brute-force protection. For a NZ government service with RealMe integration I’d add federation error handling. Then I’d ask: what’s your current coverage? Are there known issues I should focus on? Here’s how I’d approach the top three scenarios…”
Named 3 risk areas. Named NZ-specific context (RealMe). Asked a follow-up. Then demonstrated depth on request. That’s the structure.
“Tell me about a bug you found that had significant impact.”
Use the STAR structure: Situation → what you found → how you found it → impact → what changed.
✅ NZ example: “On a payments platform in Wellington, I found that concurrent login attempts from the same device could briefly show another user’s account balance. I found it during exploratory testing of the session management. Filed as P1. Fixed within 24 hours before release. The dev team hadn’t considered the race condition in the session creation logic.”
“How do you handle testing with incomplete requirements?”
✅ Strong: “I treat it as a risk. I document what’s unclear, raise it in the Three Amigos or sprint planning, and test against what’s agreed while flagging what’s unknown. I’d rather surface a concern before dev starts than find a defect after UAT. Ambiguity in requirements is a test risk, and I document it as one.”
“How do you prioritise testing when you don’t have time to test everything?”
✅ Strong: “Risk-based prioritisation. I rank scenarios by likelihood of failure and business impact. For a release, I always cover the critical path and anything that handles money or personal data first. I use what I know about recent changes, known defect-prone areas, and business priority to triage what gets coverage and what gets noted as a risk.”
“How do you work with developers when you disagree on a bug?”
✅ Strong: “I start by making sure we’re looking at the same evidence. I’ll show my reproduction steps and expected vs actual. If the disagreement is about whether it’s a defect or by design, I ask to look at the requirements together. If we still disagree, I escalate to the product owner — they make the call, not me or the developer. I document the outcome either way.”
“A bug you raised is marked ‘won’t fix’. What do you do?”
✅ Strong: “I make sure I understand the reason — is it low risk, out of scope, a business decision? If I agree with the rationale I document the decision and move on. If I think the risk is being underestimated, I say so once with evidence and let the right person decide. Then I document that the defect is known and unresolved in the test report, so it’s visible at release.”
“How do you learn a new technology quickly?”
✅ Strong: “I start with the official documentation and a small working example I build myself. Once I can run something end to end, I read the error messages from what breaks. I also look for examples in whatever the team already has — I don’t assume my starting point is zero if there’s existing code to learn from. [If applicable: here’s how I picked up Playwright in the last 3 months…]”
“What’s your greatest weakness as a tester?”
✅ Strong: Name a real one with a real mitigation. “I can spend too long on edge cases when the priority should be the critical path — I have to actively use a time-box to make sure I’m covering what matters before I go deeper. I’ve found working from a risk-ranked list helps me stay disciplined about coverage sequencing.”
“Where do you see QA in 5 years?”
✅ Strong: Have a view. “The manual/automation boundary is blurring — most senior testers I know blend both. I think QA moves closer to engineering, with testers embedded earlier in design rather than at the end. I’m working toward that personally, building automation skills so I can contribute across the full delivery pipeline.”
“Do you have any questions for us?”
✅ Strong questions: “What does your test environment setup look like?” / “What’s the biggest testing challenge the team is working through right now?” / “How is QA involved in sprint planning?” / “What does the on-call rotation look like for QA?”
❌ Weak questions: “What time do people usually leave?” / “How many sick days do I get?” — save those for HR, not the hiring manager.
5 When to Use It
Before every interview: review the 10 questions, prepare specific examples, research the company and what they build. The night before: run through your top 3 examples out loud — not in your head, out loud. On the day: prepare 5 questions for them. Questions that show you’ve thought about their context, not just your own.
6 Common Mistakes
🚫 “I used to think: comprehensive answers show deep knowledge.”
Actually: long answers lose hiring managers. Structure your answer in 90 seconds maximum — situation, action, result. Invite a follow-up rather than giving everything upfront. A candidate who answers in 2 minutes and then asks “would you like more detail?” shows more maturity than one who lectures for 4 minutes straight.
🚫 “I used to think: if I don’t know the answer, I should bluff.”
Actually: “I haven’t worked with that specifically, but here’s how I’d approach learning it” is always better than a wrong confident answer. NZ hiring managers value honesty. A candidate who bluffs and gets caught loses trust instantly. A candidate who says “I don’t know that tool yet, but here’s what I did when I learned Playwright from scratch” demonstrates the thing that actually matters: the ability to learn.
🚫 “I used to think: asking questions at the end is a formality.”
Actually: your questions reveal your priorities and your level of curiosity. “What does the on-call rotation look like for QA?” shows maturity. “What’s the biggest testing challenge the team is working through right now?” shows genuine engagement. “What time do people usually leave?” signals you’re thinking about getting out, not getting in. Prepare 5 questions; you’ll usually get to ask 2 or 3.
7 Now You Try
Prepare a 90-second answer to this NZ QA interview question using the STAR method.
Use STAR (Situation, Task, Action, Result) and make it specific to a realistic NZ SaaS or government context.
Show model answer
Situation: "We were two days from release on a Wellington SaaS product. I raised a defect where the password reset email link expired after 15 minutes — the requirement said 24 hours." Task: "The developer argued it was intentional for security reasons, but the requirement was clear and customer support had flagged it as a repeat complaint." Action: "I pulled up the requirement document and the support ticket data. I acknowledged the security rationale but showed it contradicted the spec. I asked the product owner to make the call rather than having me and the developer decide. The product owner sided with the requirement." Result: "It was fixed before release. I documented the decision in the test report. The developer and I had no hard feelings — I'd framed it as a clarification, not a confrontation." What makes this strong: — Specific (Wellington SaaS, password reset, 15 vs 24 hours) — Shows evidence-based reasoning (requirement doc + support data) — Defers appropriately (product owner decides, not the tester) — Shows relationship management (no hard feelings) — Under 90 seconds when spoken at a normal pace
8 Self-Check
Click each question to reveal the answer.
Q1: What’s wrong with answering “how do you test a login page?” with a 20-point checklist?
It shows study, not thinking. A hiring manager wants to see how you reason about risk, how you prioritise, and whether you engage with their specific context. A 20-point checklist demonstrates memorisation. The better answer: name 2–3 risk areas, give a specific example, and ask about their context. Demonstrate thinking, invite a conversation.
Q2: A developer tells you a bug you raised is “by design.” What do you do?
First: verify the claim against the requirements. If the spec supports the developer’s position, acknowledge it, update the defect, and document the decision. If the spec contradicts the developer’s position, show the evidence calmly and ask the product owner to make the call. Either way, document the outcome in the test report so it’s visible at release. You’re not the decision-maker — the product owner is. Your job is to make sure the decision is informed and recorded.
Q3: Name three questions you should ask at the end of every QA interview.
Any three of: “What does your test environment setup look like?” / “What’s the biggest testing challenge the team is working through right now?” / “How is QA involved in sprint planning?” / “What does the on-call rotation look like for QA?” / “How do you measure the effectiveness of your testing?” / “What does good look like for someone in this role after 6 months?” Questions that show you’ve thought about their specific context, not just your own.
9 ISTQB Note
Interview preparation is not a direct ISTQB domain. However: CTFL terminology is expected fluency in NZ QA interviews at all levels above grad. Using “defect” not “bug” (formally), understanding the difference between an “incident” and a “defect,” knowing what “test basis” and “exit criteria” mean, and being able to describe a “test level” versus a “test type” without hesitation signals you know the field, not just the practice. If you use casual or imprecise terminology in interviews, it can read as junior even if your experience is not.