Interviews
Test automation is not the senior SDET answer
The tool is not the decision. Senior test engineering begins with what failure costs, what evidence is trustworthy and who owns the response.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
3 min read
Name a framework and the interviewer learns that you have used a framework. They still do not know whether you can design a test system.
Senior SDET questions are usually decisions disguised as tool questions. What deserves automation? Which signal can block a release? What makes a flaky test expensive? When does broader coverage reduce confidence instead of increasing it?
Start with the cost of being wrong
A payment duplication, a delayed notification and a misplaced pixel do not deserve the same strategy. The expected harm determines the evidence, environment and speed required from the test.
State the failure and its cost before choosing the layer. Otherwise the answer is just a preference for unit, integration or end-to-end tests.
A test is also an operational dependency
Every automated check consumes execution time, data, environments and attention. A test that nobody trusts does not merely fail to help. It teaches the team to ignore red builds.
The senior answer includes ownership: who investigates, how quickly, with which artefacts and when the check loses its right to block release.
Flakiness is an unresolved system behaviour
Retrying can reduce noise while you investigate. It is not the investigation. The useful questions are whether the failure follows timing, shared state, environment instability, race conditions or a product behaviour the test exposed accidentally.
Describe how you would classify the failure and what evidence would close each branch. That shows a system, not a cleanup habit.
One failure, worked through
Take a checkout where the customer submits one order, the server accepts it and the response is lost. The failure that costs most is one intention producing two accepted orders, or the app showing success it has not established. Each claim needs its own evidence:
| Claim | Evidence that fits | What it leaves open |
|---|---|---|
| The client keeps one operation identity while reconciling | State-machine tests with a fake transport and storage | That the server deduplicates |
| The server recognises a repeated submission | Integration test with a controlled request identity | Every production failure |
| Recovery survives an app restart | A persistence test and a controlled relaunch | Background execution on every device |
Define the oracle first. A green button is not one. The assertion needs the client state and the server's order record: submit a known operation id, make the service accept it while withholding the response, assert the client shows an unresolved outcome, trigger reconciliation, and assert one order exists. Toggling connectivity at random never tells you which side of acceptance the failure landed on. Then name who responds when it fails and which artefacts they need. The same habit applied to requirements is in mobile security requirements.
Rehearse the tradeoff, not the definition
Take a scenario and answer in this order: risk, observable behaviour, cheapest trustworthy layer, operational owner and the condition that changes the choice.
Senior SDET Interview Handbook is the handbook behind this answer.
