What We Look For When Hiring AI-Native SDETs

The job title hasn't changed, but the job has. An SDET in 2026 doesn't write manual test cases or click through regression suites. An AI-native SDET designs automation infrastructure, writes production-grade test frameworks, builds pipeline integrations, and operates AI-assisted workflows that amplify their output by 5–10x.

When we hire, we evaluate four capabilities. First, systems thinking: can the candidate reason about how a change in one part of the system affects test reliability in another? Second, automation architecture: can they design a test infrastructure that scales with the product, not linearly with the feature count? Third, AI fluency: can they effectively prompt, constrain, and verify AI-generated test code? Fourth, production mindset: do they think about observability, environment parity, and deployment safety as part of their job?

What we don't evaluate: manual testing speed, test case documentation skills, or familiarity with specific test management tools. These are artifacts of the old model. They're not wrong. They're just not where the leverage is anymore.

The hardest part of hiring AI-native SDETs is that the talent pool is small. Most experienced QA engineers were trained in the gate-based model. Retraining is possible. We run a structured program that transitions traditional QA engineers into the AI-native operating model over 8–12 weeks. But it requires willingness to let go of the old identity.

If you're an SDET reading this and it resonates, we're hiring. If you're an engineering leader trying to figure out what your QA function should become, start with the methodology paper and the maturity assessment. The hiring profile follows from the operating model, not the other way around.