Senior SDET System Design Interview Complete Guide (2026)

TL;DR

A strong senior SDET system design answer turns a vague testing problem into requirements, estimates, APIs, data models, a control plane, an execution plane, and explicit failure handling. Start with a thin end-to-end design, quantify it, then defend tradeoffs around scheduling, isolation, storage, flake analysis, security, and operability.

Key Takeaways

• Clarify users, workloads, constraints, and success metrics before drawing components.
• Separate the control plane that schedules work from the data plane that executes tests.
• Estimate concurrency, event volume, storage, and retention with simple defensible math.
• Design idempotency, leases, retries, and observability into the first complete architecture.
• Treat artifacts, secrets, test data, and untrusted test code as explicit security boundaries.
• Present a thin end-to-end design first, then deepen the riskiest component.
• Verify every claim with failure scenarios, measurable service objectives, and tradeoffs.

A senior sdet system design interview guide should teach more than boxes and arrows. You must convert an ambiguous quality problem into a scalable service, expose assumptions, quantify load, and explain how the platform behaves when runners crash, events arrive twice, or a release creates ten thousand jobs at once.

This guide gives you a repeatable interview method and a small runnable reference system. You will design a cross-platform execution control plane in TypeScript, then connect its decisions to result storage, flake detection, device scheduling, security, and operations. The code is intentionally small enough to run locally, while the discussion shows how to evolve it for production.

TL;DR

Do not begin with Kafka, Kubernetes, or a database choice. Begin with who submits tests, what must run, how quickly feedback is needed, and what correctness means.

What You Will Build

By the end, you will have a small test execution control plane that can:

• accept an idempotent test-run request through an HTTP API
• split a run into independently schedulable test tasks
• lease compatible tasks to Linux or Windows workers
• renew leases and recover work after a worker disappears
• record immutable task results and derive run status
• expose health and operational counters for verification

You will also have an interview narrative for scaling this design from one process to a regional service. The reference implementation is not a pretend production platform. It is an executable model that makes the central contracts and failure rules concrete.

Prerequisites

Use Node.js 22 LTS or newer and npm 10 or newer. The sample uses TypeScript, Express 5, Zod 4, and Vitest. Create an empty project:

mkdir sdet-design-lab && cd sdet-design-lab
npm init -y
npm install express zod
npm install -D typescript tsx vitest @types/express @types/node
npx tsc --init --target ES2022 --module NodeNext --moduleResolution NodeNext --strict
mkdir -p src test

Add these scripts to package.json:

{
  "scripts": {
    "dev": "tsx watch src/server.ts",
    "start": "tsx src/server.ts",
    "test": "vitest run",
    "typecheck": "tsc --noEmit"
  },
  "type": "module"
}

You need basic REST, SQL, CI, and test-runner knowledge. You do not need advanced distributed systems theory. For broader preparation, review Selenium interview questions for eight years of experience and API testing scenario-based interview questions.

Step 1: Frame the senior sdet system design interview guide problem

Start the interview by writing a compact contract. Assume developers and CI systems submit suites containing test cases. Workers run each case on a requested platform, and users inspect progress, logs, and final results. Ask whether browsers, mobile devices, retries, priorities, cancellation, and multi-region execution are required.

Separate functional requirements from quality attributes:

State two invariants: every accepted task reaches a terminal state or remains visibly recoverable, and one task attempt cannot overwrite another attempt's final result. Tests may execute more than once because networks fail. The system therefore promises at-least-once execution with idempotent completion, not magical exactly-once execution.

Estimate an illustrative workload. If 200 teams submit 40 runs per workday, each run contains 300 tests, and traffic peaks at five times average, the platform must plan for 2.4 million task executions per day plus retries. If a task emits 30 result events, that is 72 million events per day before logs. Say that these are assumptions and ask the interviewer to adjust them.

Verify: summarize the agreed scope in sixty seconds. You should be able to name the primary user, peak concurrency, largest payload, latency objective, retention period, and two invariants without mentioning a vendor.

Step 2: Define APIs and lifecycle states

Define contracts before implementation. A run moves from queued to running, then passed or failed. A task moves through queued, leased, and a terminal state. Lease expiry moves nonterminal work back to queued; it does not pretend the old worker stopped instantly.

Create src/model.ts:

export type Platform = "linux" | "windows";
export type TaskStatus = "queued" | "leased" | "passed" | "failed";

export type Task = {
  id: string;
  runId: string;
  testName: string;
  platform: Platform;
  status: TaskStatus;
  attempt: number;
  leaseOwner?: string;
  leaseUntil?: number;
  durationMs?: number;
  error?: string;
};

export type Run = {
  id: string;
  tenantId: string;
  idempotencyKey: string;
  createdAt: number;
  taskIds: string[];
};

The public API needs POST /runs, GET /runs/:id, POST /workers/lease, POST /tasks/:id/renew, and POST /tasks/:id/complete. Submission includes an Idempotency-Key; completion includes worker identity and attempt number. In production, authentication establishes tenant and worker identity rather than trusting request fields.

Use coarse run status as a projection. It is failed if any task failed, passed if all tasks passed, running if any task is leased, otherwise queued. This avoids two sources of truth in the lab. At scale, maintain a transactionally updated counter projection for fast reads.

Verify: walk through duplicate submission and late completion. Duplicate submission returns the original run. A completion from attempt 1 cannot finalize a task currently leased as attempt 2. Those answers prove the API carries enough identity for safe retries.

Step 3: Implement idempotent submission

Create src/store.ts with an in-memory repository. It models database uniqueness and atomic updates, not durable storage:

import { randomUUID } from "node:crypto";
import type { Platform, Run, Task } from "./model.js";

type TestInput = { name: string; platform: Platform };

export class Store {
  runs = new Map<string, Run>();
  tasks = new Map<string, Task>();
  private keys = new Map<string, string>();

  createRun(tenantId: string, key: string, tests: TestInput[]): Run {
    const compound = `${tenantId}:${key}`;
    const existing = this.keys.get(compound);
    if (existing) return this.runs.get(existing)!;

    const run: Run = {
      id: randomUUID(), tenantId, idempotencyKey: key,
      createdAt: Date.now(), taskIds: []
    };
    for (const test of tests) {
      const task: Task = {
        id: randomUUID(), runId: run.id, testName: test.name,
        platform: test.platform, status: "queued", attempt: 0
      };
      this.tasks.set(task.id, task);
      run.taskIds.push(task.id);
    }
    this.runs.set(run.id, run);
    this.keys.set(compound, run.id);
    return run;
  }

  getRun(id: string) {
    const run = this.runs.get(id);
    if (!run) return undefined;
    const tasks = run.taskIds.map(taskId => this.tasks.get(taskId)!);
    const status = tasks.some(t => t.status === "failed") ? "failed"
      : tasks.every(t => t.status === "passed") ? "passed"
      : tasks.some(t => t.status === "leased") ? "running" : "queued";
    return { ...run, status, tasks };
  }
}

In PostgreSQL, enforce UNIQUE (tenant_id, idempotency_key) and insert the run plus tasks in one transaction. If two API replicas race, the database constraint decides the winner. Never implement idempotency as a process-local check followed by an unrelated insert. Store a hash of the request too, so reusing a key with a different suite returns 409 Conflict.

For very large suites, upload a versioned manifest to object storage and create tasks asynchronously. The accepted run remains visible while expansion progresses. Bound manifest size, test count, and test-name length to prevent abuse.

Verify: call createRun("team-a", "build-42", tests) twice. Both returned objects must have the same run ID, and store.tasks.size must equal the number of tests, not twice that number.

Step 4: Add capability-aware leasing and recovery

Append these methods inside Store:

lease(workerId: string, platforms: Platform[], now = Date.now()) {
  for (const task of this.tasks.values()) {
    const expired = task.status === "leased" && (task.leaseUntil ?? 0) <= now;
    if (expired) {
      task.status = "queued";
      task.leaseOwner = undefined;
      task.leaseUntil = undefined;
    }
    if (task.status === "queued" && platforms.includes(task.platform)) {
      task.status = "leased";
      task.attempt += 1;
      task.leaseOwner = workerId;
      task.leaseUntil = now + 30_000;
      return { ...task };
    }
  }
  return undefined;
}

renew(taskId: string, workerId: string, attempt: number, now = Date.now()) {
  const task = this.tasks.get(taskId);
  if (!task || task.status !== "leased" || task.leaseOwner !== workerId ||
      task.attempt !== attempt || (task.leaseUntil ?? 0) <= now) return false;
  task.leaseUntil = now + 30_000;
  return true;
}

complete(taskId: string, workerId: string, attempt: number,
         outcome: "passed" | "failed", durationMs: number, error?: string) {
  const task = this.tasks.get(taskId);
  if (!task || task.status !== "leased" || task.leaseOwner !== workerId ||
      task.attempt !== attempt) return false;
  task.status = outcome;
  task.durationMs = durationMs;
  task.error = error;
  task.leaseUntil = undefined;
  return true;
}

A pull model gives workers backpressure: each worker asks only when it has capacity. Capabilities prevent a Linux worker from receiving Windows work. Production matching can include browser version, architecture, labels, device model, tenant policy, and locality. Avoid scanning every queued row. Use indexed queue partitions, such as platform plus priority, and claim rows with a short transaction using FOR UPDATE SKIP LOCKED.

Leases solve coordinator uncertainty. The worker heartbeats before expiry. If it dies, another worker gets a higher attempt. The original may still finish, but its stale attempt is rejected. Test side effects still need unique data or cleanup because execution can repeat.

Verify: lease a task at time 0, then lease again at 30_001. The second lease must have attempt 2. Completion carrying attempt 1 must return false; completion carrying attempt 2 from the current owner must return true.

Step 5: Expose the runnable HTTP service

Create src/server.ts:

import express from "express";
import { z } from "zod";
import { Store } from "./store.js";

const app = express();
app.use(express.json({ limit: "256kb" }));
const store = new Store();
const platform = z.enum(["linux", "windows"]);

app.post("/runs", (req, res) => {
  const input = z.object({ tenantId: z.string().min(1), tests: z.array(
    z.object({ name: z.string().min(1).max(200), platform })
  ).min(1).max(10_000) }).safeParse(req.body);
  const key = req.header("Idempotency-Key");
  if (!input.success || !key) return res.status(400).json({ error: "invalid request" });
  return res.status(202).json(store.createRun(input.data.tenantId, key, input.data.tests));
});

app.get("/runs/:id", (req, res) => {
  const run = store.getRun(req.params.id);
  return run ? res.json(run) : res.status(404).json({ error: "not found" });
});

app.post("/workers/lease", (req, res) => {
  const input = z.object({ workerId: z.string(), platforms: z.array(platform).min(1)
  }).safeParse(req.body);
  if (!input.success) return res.status(400).json({ error: "invalid request" });
  const task = store.lease(input.data.workerId, input.data.platforms);
  return task ? res.json(task) : res.status(204).send();
});

app.post("/tasks/:id/renew", (req, res) => {
  const input = z.object({ workerId: z.string(), attempt: z.number().int().positive()
  }).safeParse(req.body);
  if (!input.success) return res.status(400).json({ error: "invalid request" });
  return store.renew(req.params.id, input.data.workerId, input.data.attempt)
    ? res.status(204).send() : res.status(409).json({ error: "stale lease" });
});

app.post("/tasks/:id/complete", (req, res) => {
  const input = z.object({ workerId: z.string(), attempt: z.number().int().positive(),
    outcome: z.enum(["passed", "failed"]), durationMs: z.number().nonnegative(),
    error: z.string().optional() }).safeParse(req.body);
  if (!input.success) return res.status(400).json({ error: "invalid request" });
  const { workerId, attempt, outcome, durationMs, error } = input.data;
  return store.complete(req.params.id, workerId, attempt, outcome, durationMs, error)
    ? res.status(204).send() : res.status(409).json({ error: "stale attempt" });
});

app.get("/healthz", (_req, res) => res.json({ status: "ok" }));
app.listen(3000, () => console.log("control plane listening on :3000"));

Run npm run typecheck, then npm start. Submit a run with curl, lease each task, complete it, and query the returned run ID. HTTP 202 means accepted, not necessarily expanded or running. Use 409 for stale ownership because silently accepting a rejected result makes debugging dangerous.

Production APIs should use OIDC for users, short-lived workload identity for workers, tenant authorization on every read, rate limits, request IDs, audit logs, and pagination. Logs and artifacts should use pre-signed object-store uploads rather than passing gigabytes through the coordinator.

Verify: curl http://localhost:3000/healthz must return {"status":"ok"}. Repeating a submission with the same tenant and Idempotency-Key must return the same run ID.

Step 6: Design durable storage and event flow

Move from the lab to a service by separating four storage shapes. PostgreSQL stores runs, tasks, attempts, leases, and idempotency records. Object storage holds logs, screenshots, videos, traces, and large manifests. A stream transports lifecycle events to consumers. An analytical store supports trends and flake queries without loading the transactional database.

A useful relational core is:

CREATE TABLE task_attempts (
  task_id UUID NOT NULL,
  attempt INT NOT NULL,
  worker_id TEXT NOT NULL,
  status TEXT NOT NULL,
  lease_until TIMESTAMPTZ,
  duration_ms BIGINT,
  result_uri TEXT,
  PRIMARY KEY (task_id, attempt)
);
CREATE INDEX runnable_attempts ON task_attempts (status, lease_until);

Publish events through a transactional outbox. The same database transaction that finalizes an attempt inserts an outbox row. A relay publishes it, and consumers deduplicate by event ID. This avoids the dual-write gap where the database commits but the event publish fails. Order events by task or run key when consumers require local order, but do not demand global ordering.

Lifecycle events should contain identifiers and small searchable fields, not full logs. Version the schema. Preserve raw immutable facts, then build replaceable projections such as run summaries, dashboards, and flake scores. Apply retention tiers: hot metadata for recent debugging, compressed artifacts for a defined period, and aggregate trends longer if policy allows.

Verify: describe the crash after database commit but before publish. The outbox relay retries, consumers deduplicate, and the result remains correct. Also explain how deleting an object-storage artifact affects metadata: the record can remain with an explicit expired state rather than a broken mystery link.

Step 7: Scale scheduling, isolation, and test intelligence

Partition queues first by hard compatibility, then apply policy within a partition. Hard constraints include operating system, device, browser, region, and security class. Soft policy includes priority, fairness, cost, cache affinity, and predicted duration. Weighted fair queuing prevents one tenant's release storm from starving others. Aging prevents low-priority work from waiting forever.

Use duration history to balance shards. Splitting by test count creates a long tail when one shard contains several slow tests. A longest-processing-time heuristic is often a practical starting point, but isolate tests that cannot run concurrently. Feed actual durations back after each run and keep a fallback for unknown tests.

Run untrusted test code in short-lived, restricted workers. Use containers for ordinary Linux workloads and stronger virtual-machine isolation where risk requires it. Mount the workspace read-only where possible, issue scoped secrets just in time, block cloud metadata endpoints, restrict egress, cap CPU and memory, and destroy the environment after the attempt. Do not place credentials in command arguments or result logs.

Flake detection is a consumer of immutable attempt facts. Start with transparent evidence: a test has both pass and fail outcomes for comparable code and environment fingerprints. Track sample size and recency, separate infrastructure failures, and show evidence rather than a mysterious score. Quarantine is a workflow decision, not a way to turn a red release green. For implementation depth, read how to design reliable test data.

Verify: challenge the scheduler with one thousand long jobs from tenant A and ten urgent jobs from tenant B. Explain the fairness and priority result. Then assume a malicious test reads environment variables and calls the internet; identify which isolation controls prevent useful exfiltration.

Step 8: Make the design observable and present it clearly

Define service-level indicators around user outcomes: submission availability, queue delay by priority and platform, task completion latency, lease expiry rate, infrastructure failure rate, result-finalization conflicts, and artifact upload success. Queue depth alone is not enough because ten hour-long tasks differ from ten one-second tasks. Track estimated queued work in seconds and worker utilization by capability.

Propagate run_id, task_id, attempt, tenant_id, and worker_id through structured logs, metrics labels with controlled cardinality, and traces. Do not put raw test names into metric labels if they are unbounded. Provide a run timeline that explains submission, scheduling, worker assignment, heartbeats, retries, completion, and artifact publication.

Set alerts on symptoms users feel and pair them with diagnostic dashboards. A queue-delay SLO burn alert is more actionable than a CPU alert alone. Capacity planning should compare arrival rate, service rate, platform pools, and startup time. Autoscaling must consider pending work and predicted duration, while keeping quotas to stop runaway suites.

In the interview, present in layers: requirements, estimates, one end-to-end request, component diagram, data model, failure semantics, then one deep dive. State tradeoffs explicitly. For example, pull leasing improves worker backpressure but requires polling or long polling; PostgreSQL simplifies consistency at moderate scale but queue partitions may later move to a dedicated broker.

Verify: perform a five-minute design review without notes. Trace one successful task and one worker crash. Name the metric, log fields, and trace span you would use to diagnose a queue-delay breach. Then ask a teammate to interrupt with a database outage or duplicate completion. Your explanation should preserve accepted work, expose degraded behavior, and identify the recovery path without inventing a new architecture during the answer. Repeat until the recovery story remains concise and internally consistent.

The Complete Series

Use these focused tutorials to practice each likely senior SDET deep dive:

• Design a cross-platform test execution service for control-plane APIs, workers, capabilities, leases, and isolation.
• Design a test result storage system for schemas, artifacts, event ingestion, retention, and analytical queries.
• Design a flaky test detection system for signal quality, classification, scoring, evidence, and quarantine workflows.
• Design a device farm scheduler for exclusive device leases, matching, fairness, health, and recovery.

Treat each article as a mock interview. Give yourself forty-five minutes, record the answer, then score whether you clarified requirements, estimated scale, preserved invariants, handled failure, and discussed operations.

Troubleshooting

Problem: You start drawing infrastructure immediately -> Pause and write users, functional requirements, constraints, SLOs, and out-of-scope items. Ask two high-value questions before selecting technology.

Problem: The interviewer says your design loses tasks -> Trace acceptance through durable persistence. Add a transaction, idempotency constraint, lease recovery, and outbox. Identify every point where acknowledgment can occur too early.

Problem: You claim exactly-once test execution -> Replace the claim with at-least-once execution and attempt-fenced finalization. Explain that external side effects make true exactly-once execution unrealistic.

Problem: Your scheduler performs a full table scan -> Partition by hard capability, index runnable state, claim bounded batches atomically, and use queue depth plus estimated work for scaling.

Problem: Retries hide product failures -> Separate infrastructure retries from product-result reruns. Preserve every attempt, cap retries, expose the final policy, and never overwrite the first failure evidence.

Problem: You run out of interview time -> Present a thin complete design first. Deepen only the riskiest area after the interviewer agrees the end-to-end flow is sound.

Interview Questions and Answers

Q: How would you begin a test platform system design interview?

I identify users and critical workflows, clarify platforms and scale, agree on latency and availability objectives, and state what is out of scope. Then I write correctness invariants and estimate peak work before drawing the architecture.

Q: Why use leases instead of assigning a task permanently?

A coordinator cannot know whether a silent worker is dead or partitioned. A renewable lease gives ownership a deadline, allows recovery, and combines with an attempt number to reject stale results.

Q: Can the system guarantee exactly-once test execution?

Usually no. A worker may perform side effects and lose connectivity before reporting completion. I design at-least-once execution, fence result finalization by attempt, and require tests or setup APIs to tolerate duplicate execution.

Q: How do you stop duplicate run submissions?

I require an idempotency key scoped to the tenant, persist it with a request hash, and enforce uniqueness in the same transaction that creates the run. A repeated matching request receives the original result.

Q: How do you store large logs and videos?

Workers upload them directly to object storage using short-lived scoped URLs. Transactional metadata stores the artifact URI, checksum, content type, size, retention class, and availability state.

Q: How do you detect flaky tests?

I consume immutable attempt outcomes, compare results within compatible code and environment fingerprints, exclude infrastructure failures, and calculate evidence with sample size and recency. I show the supporting runs and keep quarantine policy separate from detection.

Q: How do you schedule heterogeneous devices?

I filter by hard capabilities, lease a healthy compatible device exclusively, then rank candidates by fairness, priority, wait time, and locality. Heartbeats, cleaning, and health checks determine whether a returned device reenters the pool.

Q: How would you scale the database?

I first index access paths and separate artifacts and analytics. Then I partition high-volume attempt and event tables by time or tenant, use read projections, archive old data, and shard only after measured limits justify the operational cost.

Q: What security risks are unique to test execution platforms?

They execute repository code while holding credentials and producing artifacts. I isolate workers, use least-privilege short-lived identity, restrict network and metadata access, redact secrets, scan artifacts, audit access, and destroy workers after use.

Q: What metrics prove the platform works?

I measure accepted-submission durability, queue delay percentiles by capability and priority, completion latency, lease expirations, infrastructure failures, stale-result conflicts, artifact success, and cost per unit of execution.

Common Mistakes

• Naming tools before requirements and estimates are agreed.
• Treating test count as the only scale dimension while ignoring duration and artifact volume.
• Mixing orchestration state, logs, and analytical queries in one unbounded database.
• Retrying every failure and accidentally hiding product defects.
• Letting stale workers finalize newer attempts.
• Ignoring tenant fairness, quotas, cancellation, and priority inversion.
• Running repository code with broad persistent credentials.
• Presenting a diagram without walking a request and a failure through it.
• Giving precise capacity numbers without exposing assumptions.
• Designing flake detection without environment fingerprints or infrastructure classification.

Where To Go Next

Choose the weakest part of your answer and practice it as a standalone forty-five-minute interview. Start with the cross-platform execution service design if orchestration feels vague. Choose the test result storage design if data modeling and retention need work. Use the flaky test detection design for analytics, or the device farm scheduler design for resource matching.

Build the lab, then replace one in-memory behavior at a time: add PostgreSQL uniqueness, transactional leasing, an outbox relay, object-storage artifact uploads, and a worker simulator. Each replacement gives you a concrete tradeoff story instead of a memorized diagram.

Conclusion

The senior sdet system design interview guide method is simple to remember: clarify, quantify, design a thin flow, preserve invariants, explore failure, and make the system operable. Strong answers connect testing expertise to distributed systems realities without pretending that retries or exactly-once labels remove uncertainty.

Practice tracing one task from idempotent submission through capability matching, leased execution, fenced completion, durable results, analytics, and retention. If you can defend that flow under a worker crash, duplicate event, traffic spike, and hostile test, you are demonstrating the judgment expected from a senior SDET.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Design Device Farm Scheduler Interview: An SDET System Design Guide
• Design a Flaky Test Detection System Interview
• System testing: A Complete Guide for QA (2026)
• TypeScript Test Framework Design Complete Guide (2026)
• A/B test validation: A Complete Guide for QA (2026)
• AI Agent Testing Complete Guide (2026)