SDET Interview Questions: Engineering Judgment About Testing
Strong SDET interviews go beyond writing test cases. They focus on how you reduce product risk through systems, automation, and engineering judgment.
Quick answer
Start with the outcome you need
You are preparing for a test-development or SDET role that expects both coding ability and quality strategy.
What to remember
The role is engineer first
SDET rounds include a coding interview because the job is building software that tests software. Candidates who prepare only test theory are caught by the coding round; candidates who prepare only coding are caught by test design.
The distinguishing question is usually about a suite that people stopped trusting, because that is the failure mode every real automation effort meets eventually.
Test design that reflects real risk
Expect to be asked how you would test a specific feature. Weak answers list every case they can think of. Strong answers start with what would be most damaging if it broke, and allocate effort accordingly.
Know boundary analysis and equivalence partitioning by behaviour rather than by name, and apply them to the actual feature being discussed.
Have a position on the pyramid. Not the diagram, but what your ratio actually was and why, and what you would change. A candidate who says their suite was too top-heavy and explains the cost is more credible than one describing an ideal distribution.
Flakiness is the subject that reveals experience
A flaky test is worse than no test, because it trains people to ignore failures. Say that, then say what you did about it.
Know the usual causes: timing assumptions and implicit waits, shared mutable state between tests, ordering dependencies, and real dependence on an external system. Being able to name which cause you diagnosed most often is a strong signal.
Have a policy: quarantine on a threshold, investigate within a window, delete if it stays unreliable. A team with an explicit policy is a team that kept its suite trustworthy, and interviewers recognise the shape of that answer.
Automation as a system you maintain
Expect questions about the framework: how tests get data, how environments are isolated, how you avoid a change in one page object breaking two hundred tests.
Expect questions about runtime, because a suite nobody can wait for is a suite that gets skipped. Parallelisation, selective execution based on the change, and what you did about the slowest tests.
Expect questions about where automation was the wrong answer. Knowing when exploratory testing or a production check was more effective than another automated case is a senior judgment, not an admission.
Practice checklist
- 01Prepare a coding answer, not only test theory.
- 02For one feature, order test cases by damage rather than by coverage.
- 03State your real test ratio and what you would change about it.
- 04Name the flakiness cause you diagnosed most often and its fix.
- 05Describe your flaky test policy, including the deletion condition.
- 06Prepare one case where you decided not to automate, and why.
Questions to practice aloud
How do you decide what not to automate?
How would you investigate a flaky integration test?
What makes an API test suite maintainable?
How do you measure whether automation improves quality?
Frequently asked questions
How much coding is really expected?+
Enough to build and maintain a framework: data structures, clean abstractions, and comfort with the language. The bar is usually near a mid-level developer round rather than below it.
Is tool experience important?+
Less than reasoning. Tools change and are learnable. What transfers is test design, isolation strategy, flakiness diagnosis, and knowing what is worth automating.
What if my company had no formal test strategy?+
Describe what you did within that, and what you would establish first given the chance. Recognising the gap and having a prioritised plan is itself the answer.