All jobs / Automation developer
Quality Engineering interview questions
Quality Engineering questions a Automation developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
An engineering manager says the app “is not testable”. What does that mean concretely?
The strongest answer: Two things are missing: a way to put the system into the state a test needs, and a way to see what it did — stable hooks on the UI, an endpoint or seed that creates the state, and logs or a response that say what happened
Why it works: Exactly — controllability and observability. Everything else is a detail of one of those two.
- Testability is control plus visibility.
- Can I reach the state I need?
- Can I see what the system did?
- Ask for hooks, not a rewrite.
Someone tags a failing spec as skipped so the pipeline is green. What do you require?
The strongest answer: A ticket, an owner, and a date — skip is a quarantine, not a delete with extra steps
Why it works: Exactly. Skips without owners become folklore. Green must still mean something.
- Skip = owner + ticket + date.
- Green must stay honest.
- A label is not a plan.
- Do not delete to hide.
Leadership wants “80% UI coverage.” What do you say?
The strongest answer: Coverage of what — lines, journeys, risks? I will show money-path signal and known gaps; I will not chase a percentage of clicks
Why it works: Exactly. A percentage without a risk list is theatre. Show paths and gaps.
- Ask “coverage of what?”
- Show paths and gaps.
- Do not chase a click percentage.
- Do not hide files.
How do you know if the pack is getting healthier?
The strongest answer: A visible flake rate, quarantine age, and time-to-signal — not a feeling that “CI was angry this week”
Why it works: Exactly. You cannot manage a suite you do not measure. Counts without flakes lie.
- Show flake rate and age.
- Show time-to-signal.
- Do not worship headcount of tests.
- Green can still be a lie.
A strong tester writes brittle Playwright. How do you coach?
The strongest answer: Pair on one test: locator, wait, oracle, isolation — then let them keep the credit; I do not rewrite the pack overnight as a hero
Why it works: Exactly. One good test teaches the standard. Hero rewrites create passengers.
- Pair on one test.
- Leave them the credit.
- Do not hero-rewrite.
- Do not exile them.
A squad only writes Playwright. How do you shift left without a lecture?
The strongest answer: Pick one bug the UI pack found late, write the 20-line API test that would have caught it, and put that recipe on the paved road
Why it works: Exactly. One converted bug is a lesson. Mandates and articles are theatre.
- Convert one late bug downward.
- Publish the recipe.
- No bans.
- No hostage CI.
Staging has no payments; tests stub the wallet. What must you say at go/no-go?
The strongest answer: Which money paths were proven on a sandbox that can charge, and which were only stubbed — I do not say “e2e passed” as if the wallet existed
Why it works: Exactly. Residual names the missing oracle. Stubs are fine if they are spoken.
- Name stubbed vs proven.
- Do not say “fully.”
- Speak the residual.
- Do not hide stubs.
You are reviewing a pull request that adds twelve new end-to-end tests.
What do you actually look for?
The strongest answer: Whether each test would fail if the feature broke, and fail for one clear reason; that it creates and cleans its own data, waits on conditions rather than time, asserts something a user cares about, and is named after what it protects
Why it works: Right — the first question is whether it can fail for the right reason; everything else follows from it.
- Would it fail if the feature broke?
- One reason to fail, clearly named.
- Owns its data; waits on conditions.
- The name says what it protects.
What does a senior SDET owe that a strong junior does not yet?
The strongest answer: A paved road other people can use — data, lints, CI trains, coaching — not a private suite that only they can debug
Why it works: Exactly. Senior is leverage. A hero suite is a junior skill at larger volume.
- Build the road others use.
- Coach and lint.
- Do not worship volume.
- Do not vanish into review-only.
An end-to-end test fails in CI against a deployed environment. The report shows a 500 from the checkout call, and nobody can find the matching request in the service logs.
What do you ask for, and from whom?
The strongest answer: A correlation id the test sets on every request, propagated through the services into their logs and traces, and printed in the test report — so a failure links straight to the server-side story of that exact request
Why it works: Right — and asking for it as a platform capability, not a favour per incident, is what makes it stick.
- Join the test to the server story.
- Set an id per request; propagate it.
- Print it in the test report.
- Ask for it as a platform capability.
A Sev-1 shipped through a green pipeline. How do you learn?
The strongest answer: Which oracle was missing and which cheaper layer should have held it — one road change, no blame tour
Why it works: Exactly. Missing oracle, cheaper home, one change. Blame and ocean-boiling are how you learn nothing.
- Find the missing oracle.
- Put a cheaper test on the road.
- One owned change.
- No blame tour.
A release train wants the UI gate optional “to go faster.” What do you do?
The strongest answer: Offer a thinner mandatory smoke and a named residual they sign — I do not keep a gate nobody runs or a skip with no signature
Why it works: Exactly. Optional-with-a-badge is a lie. A thin real gate plus a signed gap is honesty.
- Thin mandatory smoke.
- Signed residual.
- No decorative badges.
- Do not become a tunnel-around.
A director asks for the ROI of the automation pack. What do you refuse to invent?
The strongest answer: A fake “bugs prevented” dollar figure — I will show minutes to signal, escaped defects we can name, and what the pack does not cover
Why it works: Exactly. Honesty is residual plus named evidence. Invented savings are how you lose the next budget review.
- Show signal and named escapes.
- Name what you do not cover.
- Do not invent a savings percentage.
- Do not claim hiring outcomes.
What do you listen for when hiring a senior SDET?
The strongest answer: Isolation, oracles, and how they killed a flake — not a trivia list of Cypress commands or a promise to “automate everything”
Why it works: Exactly. Judgement over trivia. Heroics at night are a smell, not a virtue.
- Listen for isolation and oracles.
- Ask how they killed a flake.
- Skip command trivia.
- Do not hire for night heroics.
Main is always green and nobody trusts it. What do you inspect?
The strongest answer: Skips, retries, stubbed oracles, and who can bypass the gate — cheap green is the most expensive kind
Why it works: Exactly. Distrust is a clue: the gate is decorative. More tests on a lying gate make a larger lie.
- Inspect skips and retries.
- Inspect stubs and bypasses.
- Do not paint a brighter badge.
- Do not hide distrust.