Hire SDETs remotely from our vetted global talent

A Software Development Engineer in Test owns the infrastructure that lets other engineers ship tested code at speed. The role exists because flaky pipelines, slow feedback loops, and brittle test suites are engineering problems, not script-writing problems. An SDET writes production-grade code in Java, Python, Go, TypeScript, or Kotlin, reviews pull requests at the same bar as the rest of the team, and builds the frameworks, fixtures, and harnesses that the entire engineering organization tests against. At Terminal, SDET hires are the engineers product teams reach for when test infrastructure is the bottleneck, not test coverage.

Test infrastructure: The environments and data that every test depends on.

• Hermetic test environments that isolate runs from each other and from shared state

• Ephemeral preview deployments wired into pull requests so reviewers see the actual change

• Test data factories and fixture generators that produce realistic state without copy-pasting JSON

• Service virtualization with WireMock, Mountebank, or custom in-memory test doubles for third-party dependencies

Test framework development: The libraries and DSLs that make tests cheap to write and cheap to maintain.

• Page Object frameworks, screenplay patterns, and fluent test DSLs that survive a UI rewrite

• Custom Cypress plugins, Playwright fixtures, and Selenium grid wrappers tuned for the team

• Shared assertion libraries, matchers, and snapshot utilities maintained as first-class code

• API test toolkits with typed clients generated from OpenAPI or GraphQL schemas

Contract and integration test systems: The infrastructure that catches service-to-service regressions before staging does.

• Consumer-driven contract testing with Pact, Spring Cloud Contract, or a custom broker

• Local integration stacks via Docker Compose, Testcontainers, and LocalStack so engineers run the real graph on their laptop

• Schema-compatibility checks on Protobuf, Avro, and GraphQL changes as a CI gate

• Cross-repo orchestration for monorepos and polyrepo estates where one service change touches a dozen consumers

CI/CD test infrastructure: What turns a 90-minute test job into a 9-minute one.

• Test parallelization, sharding, and load balancing across runners

• Retry strategy, quarantine workflows, and flake-detection systems that surface signal instead of noise

• Test analytics dashboards that track suite duration, failure rate, and flake rate over time

• Build acceleration and test selection with Bazel, Nx, Turborepo, or affected-graph computation

How an SDET differs from related roles: The line that hiring managers most often blur.

• QA Engineers own quality strategy across the team; SDETs build the tools that strategy runs on

• QA Automation Engineers author test suites against existing frameworks; SDETs build the frameworks

• Manual QA Testers run exploratory and acceptance testing; SDETs rarely touch that surface area

• Platform and DevTools engineers own developer experience broadly; SDETs own the testing slice of it deeply

The case for an SDET is almost always an infrastructure-leverage argument. When flaky pipelines, slow CI, and brittle test suites are taxing the entire engineering team, hiring one SDET who builds infrastructure other engineers compound on is the highest-leverage move on the roadmap. The case against shows up when a QA Automation Engineer or a Platform engineer is the right shape for the work.

Flake is an infrastructure problem: Once the cause is race conditions and environment instability, no amount of script-tweaking fixes it.

• Hermetic environments and deterministic fixtures that remove the shared-state class of flake entirely

• Network and clock control at the test boundary so async timing bugs surface in CI, not production

• Flake-detection systems that quarantine bad tests automatically and route signal to the owning team

• Root-cause analysis on flaky tests with the same rigor engineers apply to production incidents

Feedback loops decide engineering velocity: Slow CI is a tax on every pull request the team ships.

• Test selection that runs only the suites affected by a change, not the full estate

• Parallelization and sharding tuned to the runner pool, not left at framework defaults

• Hot-reload test runners and watch-mode tooling that compress the local dev loop to seconds

• Preview environments that boot in under a minute so reviewers exercise the change, not the description of it

Testability is a design force: The senior SDET sits on engineering review panels and improves the design, not just the coverage.

• Pushing back on architectures that bake in untestable coupling, with concrete refactor proposals

• Surfacing seams for fakes, in-memory implementations, and contract verification at design time

• Treating observability for tests (telemetry, flake correlation, MTTR for test failures) as a first-class concern

• Contributing to product code when the test concern is really a design concern

AI Fluency multiplier: Agentic AI workflows have changed how SDETs build test infrastructure, and the gains compound on the framework layer.

• An AI Enabled SDET running Cursor or Claude Code with human-in-the-loop review can refactor a test framework, regenerate page objects, and update every dependent suite in a single session

• An AI Native SDET orchestrates parallel agents for agentic test framework refactors, AI-generated contract tests from API specs, and autonomous flake investigation that opens triaged tickets

• LLM-driven test selection prioritizes the suites most likely to catch a given diff, compounding the savings on every pull request

• Terminal classifies every engineer in AI Assisted, AI Enabled, or AI Native tiers and surfaces those signals at hire time

When not to hire an SDET: Other roles fit better when the problem is not infrastructure.

• Small teams where the test suite is small enough that a QA Automation Engineer can author and own it directly

• Teams whose real bottleneck is build, deploy, or developer onboarding, where a Platform or DevTools engineer is the right hire

• Organizations without an engineering culture of writing tests, where an SDET will out-build the demand and the framework will rot

• Hire a QA Automation Engineer when the work is suite authorship; hire a Platform engineer when the work is developer experience broadly

A senior SDET's job description is broader than the job posting suggests, but the day-to-day is concrete. Here is what they actually own.

Framework and tooling delivery, end-to-end: The default unit of work.

• Design the framework or harness, write the implementation, ship the integration, support the first teams that adopt it

• Treat the framework as a product with internal users, a versioning policy, and a deprecation path

• Own the change from kickoff to adoption metrics, not just to merge

• Pair with the consuming engineering team on the API of the tool before writing it, not after

Test environment engineering: The infrastructure that every other test depends on.

• Hermetic environments built on Docker Compose, Testcontainers, or Kubernetes-in-Kubernetes patterns

• Ephemeral preview deployments triggered per pull request and torn down on merge or timeout

• Realistic seed data and fixture generators that match production shape without leaking production content

• In-memory and stub implementations of third-party services for fast, offline, deterministic runs

Contract testing programs: The work that prevents service-graph integration breakage.

• Stand up Pact, Spring Cloud Contract, or a custom broker as the contract source of truth

• Wire consumer-side and provider-side verification into CI as blocking checks

• Generate consumer contracts from typed clients so the contract drifts only when the code drifts

• Onboard consuming teams to the contract workflow without making it feel like a tax

CI/CD test pipeline ownership: The senior bar is debugging why CI is slow without guessing.

• Profile pipeline runs, identify the long-pole jobs, and reshape parallelization to match

• Build retry and quarantine logic that catches flakes without papering over real failures

• Maintain test analytics dashboards (Datadog CI Visibility, Buildkite Test Analytics, or in-house) the team actually reads

• Write the runbook for a broken pipeline so the next on-call engineer does not start from scratch

Performance test infrastructure: Load and stress testing as repeatable, owned systems.

• k6 cluster setup, custom load generators, or Locust deployments tuned to the actual workload

• Baseline reporting so a regression in latency or throughput shows up before users do

• Soak, spike, and chaos test scenarios scheduled as regular jobs, not one-off events

• Capacity planning data piped back to the engineering team in a form they can act on

Test observability and analytics: Tests are software too, and they need the same telemetry production code does.

• Test telemetry: duration, failure rate, flake rate, ownership, and trend lines per suite

• Flake correlation across services, branches, and time of day to find environmental causes

• MTTR for test failures tracked alongside MTTR for production incidents

• Cost-of-CI reporting so the engineering leadership sees the dollar number behind a slow suite

Security testing infrastructure: The harnesses that make security checks a default, not a quarterly campaign.

• SAST and DAST automation wired into CI with sensible severity gates

• Fuzz harness construction for parsers, serializers, and untrusted-input boundaries

• Dependency and container scanning with triage workflows that route findings to owning teams

• Secret scanning and credential rotation tests that catch leaks before they ship

Cross-team collaboration and review: A lot of the work happens outside the editor.

• Review pull requests from product engineers at the same bar as any senior reviewer

• Sit on architecture and design review panels and offer testability feedback that changes the design, not just the test plan

• Mentor engineers on writing tests that hold up, not tests that hit a coverage number

• Partner with engineering leadership on the metrics that prove the test infrastructure is paying for itself

The skill bar separating a senior SDET from a QA Automation Engineer is depth as an engineer first, with test expertise as the specialization. Terminal screens for both. Only the top 7% pass our screening, and the skills below are the ones that come up in technical interviews.

Core programming fluency: Production-grade code in at least one strong language, plus working competence in a second.

• Java with JUnit 5, TestNG, and the JVM ecosystem; Python with pytest, hypothesis, and async runtimes; Go for fast, dependency-light tooling; TypeScript for browser and Node test stacks; Kotlin for JVM-native teams

• Comfort with the language's runtime model: JVM threading, Python's GIL, goroutines and channels, Node's event loop

• The senior tell is reading and contributing to product code, not just test code, at the same review bar as the engineering team

• Concurrency primitives and synchronization patterns used correctly in test harnesses that have to coordinate parallel workers

Test framework engineering: Production experience designing test frameworks, not just consuming them.

• Page Object, screenplay, and fluent DSL patterns chosen deliberately, not by default

• Custom plugins and fixtures for Cypress, Playwright, Selenium, Appium, or framework-equivalent

• Shared assertion libraries, matchers, and reporters maintained as versioned internal packages

• Test isolation patterns that survive parallel execution without flake

Test infrastructure and environments: The hardest-to-fake part of the role.

• Docker, Docker Compose, and Testcontainers for hermetic, reproducible environments

• LocalStack, WireMock, Mountebank, and in-memory doubles for third-party services

• Kubernetes basics including ephemeral namespaces, Helm or Kustomize charts, and operator patterns where they fit

• Cloud provider familiarity (AWS, GCP, Azure) sufficient to stand up disposable infrastructure for tests

Contract and integration testing: Familiarity with the patterns that hold up at service-graph scale.

• Pact, Spring Cloud Contract, or custom consumer-driven contract systems wired into CI

• Schema compatibility checks on Protobuf, Avro, and GraphQL changes as blocking gates

• Integration stacks orchestrated locally and in CI without divergence between the two

• Message-bus and event-driven test patterns: queues, topics, replay logs, and idempotency verification

CI/CD and dev loop tooling: Senior SDETs own the pipeline, not just contribute to it.

• GitHub Actions, GitLab CI, Buildkite, CircleCI, or Jenkins configured deliberately, with cache and artifact strategy

• Test parallelization, sharding, and selection with Bazel, Nx, Turborepo, or affected-graph tooling

• Flake-detection, quarantine, and retry-with-signal systems that surface real failures, not noise

• Build acceleration and hot-reload test runners that compress the local dev loop

Performance and security test depth: Specialized harnesses that the engineering team rarely builds on its own.

• k6, Locust, Gatling, or JMeter cluster setups tuned to the workload, with baseline and regression reporting

• Fuzz harness construction with libFuzzer, AFL, Atheris, or Jazzer for the inputs that warrant it

• SAST and DAST automation wired into CI with severity gates that match the risk model

• Chaos and soak testing scenarios designed and scheduled as regular jobs

Observability for tests: Knowing what to measure is as important as knowing how to optimize.

• Test telemetry with Datadog CI Visibility, Buildkite Test Analytics, Honeycomb, or in-house dashboards

• Flake correlation, ownership routing, and trend reporting that engineering leadership actually reads

• MTTR for test failures tracked the same way as production incident MTTR

• Cost-of-CI accounting so the dollar number behind a slow suite is visible

AI Fluency: The capability shift that is reshaping engineering output.

• Daily use of Claude Code, Cursor, GitHub Copilot, or comparable AI coding assistants

• Comfort orchestrating agents for agentic test framework refactors, AI-generated contract tests from API specs, and autonomous flake investigation, with human-in-the-loop review

• LLM-driven test selection that prioritizes suites most likely to catch a given diff

• AI Enabled or AI Native tier per Terminal's standard. The engineer either uses AI tools to compound their output significantly, or builds agentic workflows directly

Soft skills that matter: The non-technical bar is real.

• Clear written communication. Most SDET work lands as internal-tool documentation, design docs, and pull requests other engineers will adopt

• Pragmatism on scope. Knowing when to ship the framework and when to refactor it

• Mentorship instinct. Senior SDETs raise the testing floor of the whole engineering team

• Engineering credibility. The senior tell is offering testability feedback in design review that improves the design, not just the test plan