JPJobPrepfull-stack interview
RoadmapsJS CompilerStar on GitHub
Career Roadmaps · SDET

Career roadmap

Software Development Engineer in Test

A developer who builds the tools, frameworks and infrastructure that make quality measurable at scale.

Time
6-9 months part-time
Entry bar
Real development ability. This is a software engineering role.
Stages
5 · 25 topics
0/25 studied0%
All roadmaps

Before you start SDET

  • Strong programming in one language
  • Data structures and algorithms basics
  • Understanding of distributed systems

Engineering fundamentals

5-7 weeks · 0/5 topics

SDET interviews include the same coding rounds as developer interviews.

  1. You will be assessed as a developer, because that is what the role is.

    • Language internals and idioms
    • Concurrency and async patterns
    • Memory and performance basics
    • Writing libraries others consume

  2. Present in most SDET loops at product companies.

    DSA Coding Questions
    • Arrays, hash maps, strings
    • Trees, graphs and traversal
    • Complexity analysis
    • Problem solving under time pressure

  3. Frameworks are long-lived software. Design decisions compound.

    • SOLID principles applied to test code
    • Design patterns in frameworks
    • API design for test authors
    • Extensibility and plugin architecture

  4. The quality expertise that distinguishes an SDET from a generalist developer.

    • Test levels and appropriate boundaries
    • Test doubles and dependency injection
    • Determinism and isolation
    • Coverage models and their limits

  5. Testing distributed systems requires understanding them.

    • HTTP, networking and protocols
    • Databases and transactions
    • Message queues and async flows
    • Containers and orchestration

BuildA well-structured library with full test coverage, published and documented.

Building test frameworks

6-7 weeks · 0/5 topics

The core deliverable: infrastructure other engineers write tests on top of.

  1. The design decisions that determine whether the framework survives two years.

    • Runner, fixtures and lifecycle hooks
    • Configuration and environment layering
    • Assertion libraries and custom matchers
    • Plugin and extension points

  2. State management is the hardest part of a shared test framework.

    • Factory patterns for test data
    • Isolation and cleanup guarantees
    • Seeding strategies at scale
    • Deterministic randomness

  3. Suite runtime is the metric teams feel daily.

    • Sharding and work distribution
    • Resource contention and isolation
    • Flake risk from parallelism
    • Dynamic test selection

  4. The framework's job is to make failures obvious without investigation.

    • Structured result formats
    • Automatic artefact capture
    • Failure clustering and deduplication
    • Historical trend storage

  5. Testing against unreliable third parties requires replacing them.

    • Mock servers and contract fidelity
    • Record and replay
    • Chaos and fault injection in tests
    • Keeping mocks honest

BuildBuild a test framework from scratch with fixtures, reporting and parallel execution.

Advanced testing techniques

5-6 weeks · 0/5 topics

Techniques that find bugs example-based tests structurally cannot.

  1. Generating inputs rather than enumerating them. A strong differentiator.

    • Properties and invariants
    • Generators and shrinking
    • Stateful property testing
    • When properties beat examples

  2. Catching integration breakage without a full integration environment.

    • Consumer-driven contracts
    • Provider verification
    • Contract versioning
    • Contracts versus end-to-end tests

  3. Testing the tests. Reveals coverage that asserts nothing.

    • Mutation operators and scores
    • Interpreting surviving mutants
    • Runtime cost management
    • Targeting critical code paths

  4. Especially valuable for parsers, protocols and anything handling untrusted input.

    • Coverage-guided fuzzing
    • Corpus management
    • Crash triage and reproduction
    • Continuous fuzzing in CI

  5. Correctness under partial failure is where real systems break.

    • Fault injection and network partitions
    • Deterministic simulation testing
    • Idempotency and retry verification
    • Consistency assertions

BuildAdd property-based tests and contract tests to a real service and document what they caught.

Quality infrastructure

4-6 weeks · 0/5 topics

Owning the platform that all teams' tests run on.

  1. Thousands of tests across many repositories needs real infrastructure.

    • Build and test caching
    • Test impact analysis and selection
    • Runner fleets and autoscaling
    • Cost per pipeline run

  2. Provisioning realistic environments on demand is a large part of the role.

    • Ephemeral environments from code
    • Data seeding at scale
    • Dependency stubbing strategy
    • Environment lifecycle and cost

  3. Automated detection and quarantine rather than manual triage.

    • Statistical flake identification
    • Automatic quarantine workflows
    • Rerun policies and their risks
    • Flake budgets per team

  4. Treating test results as a data product with dashboards and alerts.

    • Result warehousing and querying
    • Runtime and reliability dashboards
    • Correlating failures with changes
    • Alerting on suite health

  5. Some behaviour only exists in production, and can be verified safely.

    • Synthetic monitoring
    • Canary analysis and automated rollback
    • Feature flag testing
    • Production smoke tests

BuildBuild a test infrastructure service: environment provisioning, result storage and flake detection.

Interview preparation

3-5 weeks · 0/5 topics

SDET loops are developer loops plus testing design rounds.

  1. Standard algorithm and implementation questions, same bar as developers.

    • Data structure problems
    • Implementing a small utility correctly
    • Writing tests for your own solution
    • Complexity discussion

  2. Design a test framework or infrastructure component out loud.

    • API design for test authors
    • Parallelism and isolation design
    • Reporting architecture
    • Extensibility trade-offs

  3. Given a system, design the testing strategy across all levels.

    • Choosing test levels for a feature
    • Testing a distributed workflow
    • Balancing confidence against runtime
    • Testing the untestable legacy component

  4. A test fails intermittently in CI only. Diagnose it.

    • Reasoning about timing and ordering
    • Environment versus code causes
    • Reproducing intermittent failures
    • Proposing a permanent fix

  5. Published tooling is the clearest evidence for this role.

    • An open-source testing tool
    • A framework with real users
    • A CI runtime reduction case study
    • Contributions to testing libraries

BuildAn open-source testing tool or framework with documentation and adoption.

SDET tools on your CV

  • TypeScript / Java / Python
  • Playwright
  • Pact
  • Testcontainers
  • Hypothesis / fast-check
  • GitHub Actions
  • Kubernetes

What SDET employers ask to see

  • An open-source test framework or tool
  • A property-based or contract testing implementation
  • A CI pipeline runtime reduction with numbers
  • An automated flake detection system

Paid on the engineering scale rather than the QA scale. Product companies hire SDETs to build testing platforms rather than to execute tests.

Content last reviewed 2026-08-31. Guidance only — no institute or paid placement is endorsed anywhere in this book.