Fifteen things, weighted by how much each one costs you in the room. This is the thinking behind the readiness check.
Most interview advice lists topics to revise. That is useful for a written test and close to useless for a conversation, because a conversation does not sample your knowledge evenly. It goes where the evidence is thin.
What follows is what I actually weight when I screen an SDET candidate, in four groups. It is also the structure of the readiness check — fifteen questions that score you on these and tell you which gaps would sink you first.
Do you have a public repo with tests in it? Not a course project you followed along with. Something you built and can open right now.
This carries more weight than anything else on the list, and it is the gap I see most often. Without a repo the entire conversation stays hypothetical, and hypothetical loses to specific every time. With one, half the interview writes itself: why that structure, what broke, what you would change.
Does it run in CI? "It works locally" is where a lot of candidates stop. Running on every push is the difference between someone who writes tests and someone who owns a suite — and owning a suite is the actual job.
Have you fixed a flaky test by finding the root cause? This is my favourite opening question because you cannot prepare for it. You either have the story or you do not.
The weak answer: it was failing sometimes, so I added a wait. The strong one sounds like an investigation — reproduced it locally, checked whether it failed alone or only in parallel, found two specs sharing a test user, isolated the data, then ran it fifty times to be sure.
Same tools on the resume. Very different engineers in the room. There is a longer piece on this one.
A test fails in CI but passes locally. What do you do first? Re-running it is the answer that costs candidates most. The strong instinct is to isolate — alone versus parallel — because that single split tells you whether to look inside the test or outside it.
Locator strategy you can defend out loud. Async and promises, where roughly 80% of automation pain lives. API testing rather than UI only. Test data isolation, which is the most common hidden cause of flakiness. Whether you have made architecture decisions or only followed someone else's.
That last one is where senior roles are decided. Following a structure is fine at mid level. The step up is having chosen one and being able to say why.
One more that is becoming disproportionately valuable: have you tested anything with non-deterministic output? An AI feature, a recommendation engine, anything that does not repeat itself. Most candidates have nothing to say here, so even a small side project stands out. Where I start with that.
Can you talk about something you built and something you broke, in detail? Depth of one real story beats breadth of five claimed technologies. Being able to say "it turned out to be my own bad assumption" also signals you can be wrong out loud, which matters more on a team than most technical skills.
Does your resume describe things that exist, or things you learned? "Completed certification in automation testing" describes a receipt. "Built and maintained a Playwright suite running in CI on every push" describes a thing that exists. A resume gets about ten seconds, and that is the difference between them.
And the one nobody asks out loud: does your resume claim experience you would struggle to defend?
Interviewers go straight to the depth the CV claims, usually in the first ten minutes. If it says three years of automation, the questions assume three years of automation — why that locator strategy, how you handled parallel runs and data collisions, what broke in CI and how you found it. Inflated experience does not fail politely. It fails in a way that gets remembered.
The fix is almost never to write less. Most people undersell real experience because it happened on an internal tool nobody has heard of. Selenium on an in-house framework is genuine automation experience and it belongs on the page.
Your degree. In every interview I have sat in, it has not come up once. Certifications, which describe a course rather than an outcome. The number of tools you can name.
None of those predict whether you can walk me through something you built and something you broke — which is the only thing the whole conversation is really trying to find out.
Take the readiness check to see where you would land on these — fifteen questions, free, about three minutes. Or start with the 90-day roadmap if the gaps are already obvious.