QA Automation interviews test framework knowledge, automation patterns, and — most of all — whether you can write tests that stay green for reasons other than luck. Below are common questions with model answers. Senior: architecture, trade-offs, mentoring, and decision-making.
In terms they already use: cost per release, time from commit to confidence, defects reaching customers. A suite that costs two engineers a month and saves ten manual hours a release pays back on a weekly cadence and not on a quarterly one — the arithmetic differs by team and should be shown, not asserted. The honest part of the answer is naming what will not be automated and why.
Measure before touching anything: which tests fail most, which take longest, which have never caught a real defect. Usually a small number account for most of the pain. Quarantine the flaky ones so the build goes green and the team starts trusting it again, then fix or delete them. Deleting is a real option — a test nobody trusts has negative value because it costs attention and gives none.
It helps when non-engineers genuinely read and write the scenarios, which is rare and requires someone to own the language. It makes things worse when the team writes Gherkin for itself: you get an English layer over code that nobody outside reads, plus a step-definition indirection that turns a two-line change into a hunt. If the product owner never opens the feature files, drop them.
Weight the things that are expensive to change: language the team already writes, how the tool handles waiting, whether it can run in CI without a display, and how healthy the project is — release cadence, open issue age. Speed benchmarks matter least because the suite's runtime is dominated by your application, not the driver. Ask what happens when the tool is abandoned.
A failure that says what broke rather than that an assertion returned false: the step, the screenshot, the network log, the diff between expected and actual. Grouping by suspected cause rather than by file matters more than styling. The real measure is whether an engineer can decide in thirty seconds if the failure is theirs — anything longer and the report gets skipped.
Escaped defects first — bugs that reached production in an area covered by tests, since that is the thing the suite exists to prevent. Then flakiness rate and the time from commit to a trustworthy signal. Coverage percentage is the metric to distrust: it is easy to raise without testing anything meaningful, and a team told to raise it will.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior QA Automation interview →