SDET vs QA Engineer: What Startups Actually Need

Startups often post a job for a "QA Engineer" when what they actually need is an SDET, or vice versa. The titles overlap in the market, but the day-to-day work, the skill set, and the impact on your release process are meaningfully different.

The short version

A QA Engineer protects quality through testing strategy, exploratory testing, and release judgment. An SDET (Software Development Engineer in Test) builds the systems that make quality scalable: test automation frameworks, CI/CD test gates, and tooling the whole team relies on.

If you are shipping manually and want confidence before each release, start with a strong QA Engineer. If your releases are frequent and your automation is the bottleneck, you need an SDET.

What an SDET actually writes

The clearest signal in an interview is the code. Here is the kind of automation an SDET should be comfortable writing and reasoning about:

import { test, expect } from "@playwright/test"
 
test("user can book a hiring call", async ({ page }) => {
  await page.goto("/")
  await page.getByRole("link", { name: "Book a hiring call" }).click()
  await expect(page).toHaveURL(/book/)
  await expect(page.getByRole("heading", { level: 1 })).toBeVisible()
})

A QA Engineer might design the test cases and edge conditions above; an SDET builds the harness, wires it into CI, and makes it run reliably on every pull request.

How to decide

1. Map your current release process and where bugs actually escape.
2. Decide whether your bottleneck is judgment (what to test) or scale (how to test everything, every time).
3. Hire for the bottleneck first — not for the title that sounds more senior.

We will expand this into a full guide with real hiring scorecards next.