Every SDET job ad reads the same way. Playwright or Cypress. TypeScript. CI/CD. API testing. Bonus points for performance tooling. Candidates dutifully learn the list, build a portfolio repo with a page object model and a GitHub Actions badge, and then wonder why the offers stall at mid-level.
The uncomfortable truth is that tool knowledge has a shelf life of about eighteen months and a floor price that keeps dropping. Playwright's API is well documented, and an LLM can write a passable selector faster than you can. If your value proposition is "I know the framework," you have priced yourself against a commodity — and the commodity is getting cheaper every quarter.
What separates a good SDET from a person who writes automated tests is a set of skills that never show up in the job ad.
1. You can reason about risk, not just coverage
The weakest question in testing is "what should we test?" It invites a list. The strongest question is "what would hurt us most if it broke, and how likely is that?"
A good SDET can look at a payment reconciliation service and articulate, without being told, that a duplicate settlement is a regulatory incident while a misaligned button is a Jira ticket. They allocate effort accordingly. They can defend why 40% coverage on one module is fine and 90% on another is insufficient.
This is the difference between a test suite that is large and a test suite that is load-bearing. Most organisations have the former and believe they have the latter.
Practical move: before writing a single test for a feature, write three sentences on what failure looks like in production, who notices first, and what it costs. If you can't answer, you don't understand the system well enough to test it.
2. You understand the system, not the surface
Automation written from the outside in — clicking through the UI because that's where the requirements live — produces slow, brittle suites that assert on symptoms.
Good SDETs read the code. They know where the queue is, what happens on retry, which service owns which piece of state, where the eventual consistency window is, and why that flaky test isn't flaky at all — it's telling you about a real race condition that will page someone at 3am eventually.
You don't need to be the strongest developer on the team. You do need to be able to open a pull request in the application repo, follow the call stack, and form a hypothesis. If your only mental model of the product is what the browser renders, you will spend your career chasing selectors.
3. You design for feedback speed, not for test count
The metric that matters is not "how many tests do we have." It's "how long between a developer making a mistake and that developer finding out."
That reframing changes everything. It means you push assertions down the pyramid until it hurts. It means you fight for contract tests instead of adding a fourteenth end-to-end journey. It means you care about parallelisation, test data provisioning, and environment stability, because a suite that takes 90 minutes is a suite people learn to ignore.
It also means you measure yourself with delivery metrics — lead time, change failure rate, MTTR — rather than with pass rates. Pass rate is a vanity metric. A suite at 100% green that nobody trusts is worth less than a suite at 92% that everyone reads.
4. You treat test code as production code
This one is stated often and practised rarely. Look at most test repos and you'll find copy-pasted setup, three competing helper patterns, no abstraction over the API layer, hardcoded waits, and a utils.ts file that has become a landfill.
Good SDETs apply the same standards they'd expect from application code: small functions, clear naming, dependency injection, no sleeps, deterministic data, and a review culture where "this test is unclear" is a valid blocking comment.
The tell is maintenance cost. If every product change requires touching thirty test files, your design is wrong, and no amount of framework knowledge will save you.
5. You can build the tooling, not just consume it
The step from senior to lead is usually the moment you stop asking "which framework should I use" and start asking "what does my organisation need that doesn't exist yet."
That might be a test data service so squads stop stepping on each other's fixtures. It might be a reporter that maps failures to owning teams automatically. It might be an agent that triages overnight failures and raises the obvious pull requests before anyone opens their laptop. It might be a way to make observability data — traces, not logs — the primary source of truth for what your tests actually exercised.
The specific artefact matters less than the instinct: you see friction, you build the thing that removes it, and you make it useful to people who never asked for it.
6. You can hold a position in a room full of people who want to ship
Quality work is, structurally, the work of saying "not yet" to people with commercial pressure and better political capital than you. Doing that well is a communication skill, not a technical one.
Good SDETs never say "it's not ready." They say: here is the specific failure mode, here is the probability, here is the blast radius, here is what it costs to fix now versus in production, and here is my recommendation — and then they let the decision-maker decide, and put it in writing.
That framing turns you from the person blocking the release into the person giving the business the information it needs. It's also the single biggest determinant of whether you're invited to the architecture conversation or told about it afterwards.
7. You know the domain
An SDET in a trading platform who understands settlement cycles, an SDET in healthcare who understands the consent model, an SDET in lending who understands affordability rules — each of these finds bugs that no amount of framework fluency would surface.
Domain knowledge is what lets you spot the defect that isn't a defect in the code at all: the requirement was wrong, and you're the only person who noticed. That's the highest-leverage bug you will ever raise, and it's invisible to tooling.
8. You have a view on AI that isn't a slogan
Generative tools are now genuinely good at writing tests and genuinely bad at knowing which ones matter. The industry data on this is fairly blunt: AI increases throughput, and in organisations without strong delivery discipline it amplifies instability rather than fixing it. It makes the good faster and the messy messier. I've written before about what that costs in practice and about the tools that overpromise on it.
So the useful position is neither "AI will replace SDETs" nor "AI can't do real testing." It's this: generation is cheap now, so judgement is the scarce good. Your job is shifting from producing tests to curating them — deciding what deserves to exist, pruning what doesn't, and building the guardrails that stop a machine from generating four hundred assertions about nothing.
If you can articulate that with specifics from your own work, you will interview better than someone who has memorised the entire Playwright API.
Where to start
If you want a concrete way in:
- This week: pick your flakiest test. Don't quarantine it. Find out what it's actually telling you about the system.
- This month: read the application code for one service end to end. Write down three risks the current suite doesn't cover.
- This quarter: build one piece of tooling nobody asked for that saves your squad an hour a week.
- Ongoing: learn the business. Sit with the people who lose money when it breaks.
Frameworks are table stakes. Learn them in a fortnight, then stop optimising there. The career is in the judgement layer — and that part doesn't have documentation.
Related Reading
- QA is a Mindset, Not a Role - why quality ownership is cultural, not organisational.
- The Self-Healing Test Myth - what happens when tooling substitutes for judgement.
- AI Token Costs in CI/CD - a practical governance model for AI usage in QA pipelines.
Originally shared on LinkedIn. Have thoughts? Let's discuss.