A strong answer

• Has a genuine reason - likes finding the edge, likes the user's side of the argument, likes being the last check
• Knows modern testing is technical and can say what the technical part looks like
• Can name what they would find satisfying about it in a year
• Honest if they are also interested in development, and can say why this first

Red flagFrames it as the way into a development job later.

A strong answer

• Describes what made them look there - a hunch with a reason behind it
• Proved it rather than reporting a suspicion
• Told someone in a way that got it fixed rather than in a way that scored a point
• Knows what the impact would have been if it had shipped

Red flagThe story ends with being right, not with the problem being fixed.

A strong answer

• Goes back to the evidence - a reproduction, a version, a screen recording
• Separates whether it is a defect from whether it is worth fixing now
• Takes the priority question to the product owner rather than winning it in a comment thread
• Keeps the relationship, because they will need it again on Thursday

Red flagEither escalates immediately or quietly closes the ticket to avoid conflict.

A strong answer

• States the impact and the likelihood in concrete terms, not as an opinion about quality
• Offers options - fix, defer, mitigate, flag it off, ship to a subset
• Puts the risk in writing so the decision is a decision, not a drift
• Accepts a business call to ship, and makes sure the fallback is real

Red flagBlocks on principle, or goes silent and lets it ship without recording the risk.

A strong answer

• Understands the harm is immediate and personal - rent, groceries, a fortnight of somebody's pay
• Prioritises correctness over throughput and says so
• Thinks about the awkward cases first: part-time, overtime, penalty rates, leave without pay, terminations
• Mentions traceability - being able to show later what was tested and when

Red flagAnswers as if it were any other web application.

A strong answer

• Boundaries before anything else: zero, negative, 168, 168.1, a decimal, a very large number
• Format and type: text, empty, whitespace, a comma as a decimal separator, leading zeros
• Asks what the business rule actually is - what should 61 hours do, warn or reject?
• Thinks past the field: rounding, what the payslip shows, and what the database stores

Red flagLists three valid values and stops.

A strong answer

• Severity is the technical impact; priority is when it gets fixed relative to everything else
• Gives a real divergence - a crash in a screen used once a year, or a typo on the login page
• Knows who owns each: testing proposes severity, the business owns priority
• Does not treat every defect they found as a blocker

Red flagUses the two words as synonyms.

A strong answer

• Checking that what used to work still works after a change
• Suites grow because tests are added and never removed, and everything gets written at the slowest layer
• Suggests risk-based selection, moving checks down to unit or API level, and pruning
• Knows a suite too slow to run is a suite nobody runs

Red flagWould fix it by buying more machines and nothing else.

A strong answer

• A title that states the symptom, so it is findable in six months
• Steps that actually reproduce it, from a stated starting state
• Expected versus actual, plus environment, version, account and data used
• Evidence attached - a recording, a log line, a network response - and how often it happens

Red flagSays 'it does not work' is enough because the developer can just ask.

A strong answer

• Many fast unit tests, fewer integration tests, a thin layer of end-to-end tests
• Ignoring it gives an ice cream cone - slow, flaky, expensive, and feedback that arrives too late to be cheap
• Knows an end-to-end test that fails does not tell you where the fault is
• Comfortable saying the shape is a heuristic and not a law

Red flagWants everything tested through the user interface because that is what the user sees.

A strong answer

• A charter, a timebox and notes - so it can be reported and repeated
• Design, execution and learning happen at once, with the next test chosen from the last result
• Findings still end as reproducible defects, not as impressions
• Knows it complements scripted testing rather than replacing it

Red flagDescribes it as testing without a plan, and sees no problem with that.

A strong answer

• First: high-value, repetitive, stable paths - login, pay run, the checks you would otherwise do every release
• Never or rarely: one-off checks, anything needing human judgement about look and feel, a screen still being redesigned weekly
• Weighs the maintenance cost, not just the writing cost
• Knows automation is regression protection, not a replacement for looking at the thing

Red flagAnswers 'automate everything' and has no view on cost.

A strong answer

• Treats a flaky test as a broken test rather than background noise
• Quarantines it so it stops training people to ignore red, then investigates
• Looks for the usual causes: timing and implicit waits, shared state, test data, ordering dependencies
• Is willing to delete a test that cannot be made reliable, and say what coverage was lost

Red flagRe-runs the pipeline until it goes green and moves on.

A strong answer

• Starts from the contract - the schema, the documented behaviour, the status codes
• Covers validation, authentication and authorisation, not just the happy path
• Checks error shapes, pagination and what happens when the same request arrives twice
• Automates it at that layer, because it is faster and less brittle than through the screen

Red flagSays they would wait for a front end to be built.

A strong answer

• That 90% of lines executed during the tests, not that the behaviour is correct
• A test with no meaningful assertion still counts toward it
• Says nothing about the cases nobody thought to write
• Useful as a floor and a trend, dangerous as a target

Red flagTreats the number as a measure of quality and relaxes.

A strong answer

• Maps the scenario space first - which awards, which shift patterns, which dates
• Builds targeted test data rather than hunting for a case that happens to exist
• Calculates the expected result independently instead of comparing the system to itself
• Regression-checks the population that should not have changed at all, which is where these bugs actually land

Red flagTests the one scenario in the ticket and calls it covered.

A strong answer

• Keyboard only - can you reach everything, in a sensible order, and see where you are
• Labels, headings and error messages that a screen reader announces usefully
• Knows automated scanners catch a minority of issues - contrast, missing attributes, obvious structure
• Knows what they cannot catch: whether the reading order makes sense, whether alt text is meaningful, whether focus goes somewhere useful after an action

Red flagRuns a scanner, gets no errors, and reports the page as accessible.

A strong answer

• Can say what they went after first and why - risk, not screen order
• Reports what was not covered as clearly as what was
• Has at least one finding with a clean reproduction rather than five vague ones
• Distinguishes a defect from a design decision they disagree with

Red flagReports everything as a bug, including things that are working as specified.

A strong answer

• Ten minutes deciding what matters most before touching anything
• Goes at the highest-risk path first, and the data that would hurt most if wrong
• Keeps notes as they go so the report writes itself
• Hands back an honest coverage statement: here is what I checked, here is what I did not

Red flagStarts at the top left of the screen and works across.

A strong answer

• Gets specifics - which report, which figure, which period, which employee, what they expected
• Asks for evidence and the exact steps, including the environment and tenant
• Tries to reproduce with their data before concluding anything
• Checks whether it is a defect or a configuration difference, and says which

Red flagCloses it as not reproducible after one attempt on their own account.

A strong answer

• Fix and contain first, then work out how it escaped
• Asks whether a test existed, whether it was disabled, and whether the scenario was ever known
• Adds a test at the cheapest layer that would have caught it, not automatically an end-to-end one
• Goes looking for the same gap elsewhere rather than closing the one hole

Red flagFocuses on who approved the release.