SDET (Software Development Engineer in Test)

Also known as: Software Development Engineer in Test, Software Engineer in Test, Test Automation Engineer, Test Infrastructure Engineer, Quality Engineer.

What does an SDET do?

An SDET (Software Development Engineer in Test) is a developer whose product is the testing system: test automation frameworks, CI/CD test runs and test environments. They write production-grade code, only that code checks the product instead of being the product:

• design the test automation architecture and write the framework the whole team uses;
• build tests into CI/CD and keep test runs fast and stable;
• deal with flaky tests and remove their causes instead of rerunning the pipeline;
• build test environments, mocks and test data generation;
• review developers' code for testability and propose changes to the architecture.

When does a company need an SDET?

A company needs an SDET when testing has become a bottleneck for releases: test runs take hours, tests fail for no reason and developers have stopped trusting them. Usually this is a product company with several teams and frequent releases, where manual regression and scattered automated tests can no longer cope. Another trigger is moving to a model where developers write their own tests and need convenient tools for it. The role won't work if the product is small and changes rarely, and the main problem is poorly thought-out scenarios and missed risks: then you need a QA Engineer.

SDET vs QA Automation Engineer: what's the difference?

An SDET differs from a QA Automation Engineer in designing the testing system itself, while a QA Automation Engineer usually writes automated tests inside an existing framework. An SDET works with developers as an equal: reviews their code, changes the system to make it easy to test and owns the speed and stability of test runs. What sets them apart from a QA Engineer is starting from code and infrastructure rather than from user scenarios.

Why is it hard to hire an SDET?

An SDET is hard to hire because you need a fully capable developer who has chosen testing as their specialisation.

• The title is used in different ways: many SDET job posts are really plain test automation, so candidates at the right level don't trust such posts.
• Strong developers rarely move into test infrastructure, and most people from test automation don't reach developer level.
• An SDET has to write in your developers' language, which narrows the pool considerably.
• The results are hard to see in a CV: "built a framework" doesn't say how much faster and more stable releases became.

What to decide before hiring an SDET?

• What exists now: no automation, a flaky test suite, or a framework that needs to scale? Building from scratch and fixing someone else's work are different jobs and different candidates.
• Which testing levels matter most: unit, API, UI, contract, load, ML evaluation? The answer decides whose experience is more valuable: backend, frontend or ML.
• How long does a CI test run take now, and how often does it fail for no reason? This is the baseline the SDET's work will later be judged against.
• Which language and stack do your developers use? An SDET in a different language can't review their code or build tests into their workflow.

Where to find an SDET?

SDETs most often come from product companies with a mature engineering culture: large B2B and B2C products, fintech, developer tools, cloud platforms. Some are Backend Developers who moved into test infrastructure, others grew from test automation to developer level. A strong signal in a profile is a framework or tool the person built that other teams use, as well as open-source contributions to testing tools. NEWHR finds these candidates by the results of their work, not by applications to job posts.

How to assess an SDET in an interview?

An SDET is assessed with a walkthrough of test infrastructure the candidate built, a coding interview at the level of your developers and a design task. In the task the candidate decides how to test a specific service of yours: which levels, which data, how to build it into CI. On the company side an Engineering Manager or QA Lead takes part, along with a developer from a team that will use the result.

Strong signals:

• says how long the pipeline took before and after their work and how the rate of false failures changed;
• proposes changes to the product code to make it easier to test;
• explains which tests should be deleted, not only which to add.

Red flags:

• is noticeably weaker in the coding interview than the developers they will work with;
• handles flaky tests with reruns and longer timeouts;
• measures their work by the number of automated tests rather than the speed and reliability of releases.

How long does it take to hire an SDET?

We present the first candidates for the SDET role within 5–7 days of the brief.

Related roles

• QA Engineer — starts from the product and the user: test design, risks, exploratory testing.
• DevOps Engineer — owns CI/CD and infrastructure as a whole, not the testing system.
• Platform Engineer — builds the internal developer platform, not the testing system.
• Evals Engineer — builds a quality evaluation system for AI models, close in logic to test infrastructure.