TypeScript for SDET Interviews 2026 — Interfaces vs Types Deep Dive, Generics in Test Utilities and Page Object Patterns, Async/Await and Promise Patterns for Test Orchestration, Union Types and Discriminated Unions for Test Config, TypeScript-Specific Playwright Fixtures and Custom Matchers with Full Type Safety, Migrating JavaScript Test Suites to TypeScript Incrementally, TypeScript vs Java for Test Automation — When to Use Each, and How to Answer TypeScript Questions That Test Language Depth in Senior SDET Panels

You write Playwright tests. You import from @playwright/test, write async functions, catch errors, and your tests run. You've been writing TypeScript for two years — maybe three. Then the interview panel leans forward and asks: "When would you use a type alias over an interface in a test framework? Walk me through how you'd design a generic page object factory with full type safety. What does { [K in keyof T]: T[K] extends Promise ? U : never } do, and where would you use it in a test utility?" And suddenly you realise: you've been using TypeScript, but you haven't been designing with it. You've been annotating types, but you haven't been leveraging the type system to make your tests safer at compile time. You've been writing any when the types got complicated — and in 2026, that gap costs candidates the offer at the senior level. TypeScript is now the dominant language for test automation — it powers Playwright, Cypress, WebdriverIO, Jest, and Vitest. It's the language every greenfield test suite starts in. And interview panels have evolved accordingly: they're no longer asking "do you know TypeScript?" They're asking TypeScript architecture questions. They want to see that you can design a type-safe test framework — not just write tests that happen to compile.

This guide covers every TypeScript-for-SDET question senior panels are asking in 2026 — from the interfaces-vs-types debate that tests your language design intuition, to the generics patterns that demonstrate architectural thinking, to the Playwright-specific TypeScript patterns that separate framework authors from framework users. Every section maps to real interview questions Mitchell's panels have asked. And every code example is production-grade TypeScript — the kind you might be asked to whiteboard, critique, or extend during a pairing exercise. If you're interviewing for a senior or lead SDET role, TypeScript questions are no longer optional — and they're no longer about syntax. They're about architecture. The SDET Interview Coach iOS app includes a dedicated TypeScript for SDETs topic — with mock interview questions scored across type system depth, framework design, and practical patterns. Download it and practise the exact TypeScript questions panels ask before you walk into the room.

Interfaces vs Type Aliases — The Question Every Panel Asks (And What They're Actually Testing)

"When would you use an interface over a type alias?" This question appears in more TypeScript-for-SDET interviews than any other — and it's deceptively deep. Panels aren't testing whether you can recite the differences from the TypeScript handbook. They're testing whether you understand the design philosophy of the type system — and whether you can apply it to test framework architecture. Here's the comparison that demonstrates language design intuition, not just syntax knowledge.

The interview answer that scores highest: "I use interfaces for contracts — the shapes I expect other code to implement or that I anticipate extending. In a test framework, the browser provider interface, the reporter interface, the fixture types — these are interfaces because they're contracts that evolve through extension. I use type aliases for everything else — union types for configuration enums, mapped types for deriving new types from existing ones, conditional types for type-level utilities, and intersection types for composing complex objects. The decision rule is: if the type represents a contract that may be extended or implemented by third-party code, use an interface. If the type is a computation — derived, composed, or conditional — use a type alias. And if I need a union type, mapped type, or conditional type, the decision is made for me — only type aliases can express those."

// TypeScript for SDETs: interfaces vs types in a test framework context

// Interface — a contract for browser providers
interface BrowserProvider {
  name: string;
  launch(): Promise;
  connect(endpoint: string): Promise;
}

// Interface — extendable through declaration merging
interface PlaywrightFixtures {
  page: Page;
  browser: Browser;
}

// Later, in a custom fixture file — this merges!
interface PlaywrightFixtures {
  authenticatedPage: Page;
  adminPage: Page;
}

// Type alias — union type for test status (impossible with interface)
type TestStatus = 'passed' | 'failed' | 'skipped' | 'flaky' | 'timedOut';

// Type alias — mapped type for extracting promise values
type UnwrapPromise = T extends Promise ? U : T;

// Type alias — intersection for composing test config
type TestRunConfig = BrowserConfig & RetryConfig & ReportingConfig;

Generics in Test Utilities — The Pattern That Demonstrates Architectural Thinking

If interfaces vs types tests your language philosophy, generics test your architectural maturity. When a panel asks "how would you design a generic page object factory with full type safety?" they're testing whether you understand that test frameworks are templates parameterised by types — and whether you can design APIs that are self-documenting at the type level. A generic page object returns the correct type at compile time. A generic fixture factory enforces that the right fixture shape is passed to the right test. A generic API response handler extracts the correct response type from the request type. These are the patterns that transform a test suite from "it runs" to "it can't be used incorrectly."

// Generic page object factory with full type safety
type PageClass = new (page: Page) => T;

class PageFactory {
  static create(PageClass: PageClass, page: Page): T {
    return new PageClass(page);
  }
  
  // Navigate to a typed page
  static async navigate(
    page: Page, 
    url: string, 
    PageClass: PageClass
  ): Promise {
    await page.goto(url);
    return new PageClass(page);
  }
}

// Usage — fully type-safe
const loginPage = PageFactory.create(LoginPage, page);
//    ^? LoginPage — inferred, not any!

// Generic API client — request type → response type
interface ApiEndpoint {
  method: 'GET' | 'POST' | 'PUT' | 'DELETE';
  path: string;
}

class ApiClient {
  async call(
    endpoint: ApiEndpoint,
    body: TRequest
  ): Promise {
    const response = await fetch(endpoint.path, {
      method: endpoint.method,
      body: JSON.stringify(body),
      headers: { 'Content-Type': 'application/json' }
    });
    return response.json() as TResponse;
  }
}

// Define endpoints once — responses are typed forever
const createOrder: ApiEndpoint = {
  method: 'POST', path: '/api/orders'
};

const order = await client.call(createOrder, {
  productId: 'abc', quantity: 2
});
//    ^? Order — fully typed. order.total.amount autocompletes.

The generics interview answer that scores highest: "I use generics in three layers of a test framework. Layer 1 — Page objects and components: a generic PageFactory.create<T> that constructs typed page objects from page classes, and generic component classes (class DataGrid<TRow>) that parameterise over the row type. Layer 2 — API testing: generic endpoint definitions (ApiEndpoint<TRequest, TResponse>) that link request types to response types at compile time, so you can never assert on a field that doesn't exist. Layer 3 — Fixtures and test context: generic fixture factories (createFixture<TConfig, TFixture>) that derive the fixture type from the config type, enforcing that the right fixtures are passed to the right tests. The principle throughout: the type parameter captures the 'what varies' — the page type, the response type, the fixture type — and the generic function enforces the invariant — the construction pattern, the request-response link, the fixture-config contract. The result is a framework where misuse is impossible at the type level." For more on the architectural patterns that generics enable in test frameworks, see our Test Automation Framework Design Interview Guide.

Async/Await and Promise Patterns — Test Orchestration with TypeScript

Every SDET writes await — but senior panels test whether you understand the Promise orchestration layer. When to use Promise.all for parallel execution, Promise.allSettled for resilient multi-step setups, Promise.race for timeout guards, and how to build a proper retry-with-exponential-backoff as a typed utility. This is the difference between someone who writes async tests and someone who architects async test infrastructure.

// Typed retry with exponential backoff
type RetryOptions = {
  maxAttempts: number;
  initialDelayMs: number;
};

async function retry(
  fn: () => Promise,
  options: RetryOptions = { maxAttempts: 3, initialDelayMs: 1000 }
): Promise {
  const errors: Error[] = [];
  
  for (let attempt = 0; attempt < options.maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (e) {
      errors.push(e as Error);
      if (attempt < options.maxAttempts - 1) {
        const delay = options.initialDelayMs * Math.pow(2, attempt);
        await new Promise(resolve => setTimeout(resolve, delay));
      }
    }
  }
  
  throw new AggregateError(
    errors,
    `All ${options.maxAttempts} attempts failed`
  );
}

// Usage in a Playwright test
await retry(
  () => page.waitForSelector('.notification-success', { timeout: 5000 }),
  { maxAttempts: 3, initialDelayMs: 2000 }
);

The interview answer that demonstrates async mastery: "I structure async test operations in three tiers. Tier 1 — Sequential (await chain): when operations depend on previous results — login before checkout, create user before assigning permissions. Tier 2 — Parallel (Promise.all): when operations are independent and should run concurrently — initialising multiple services, waiting for multiple elements to appear simultaneously. Tier 3 — Resilient (Promise.allSettled + retry): when operations can tolerate individual failures — cleanup, multi-region deployment verification, external API health checks where any one failure shouldn't abort the test. The key async utility every test framework needs is a typed retry with exponential backoff — retry<T>(fn, options): Promise<T> — because the most common failure mode in E2E tests is transient (network hiccup, rendering delay, animation race), and a properly-designed retry eliminates these false negatives without masking real failures."

Union Types and Discriminated Unions — Type-Safe Test Configuration

The question that reveals whether you've truly internalised TypeScript's type system: "How would you design a test configuration type that's impossible to misconfigure?" The answer is discriminated unions — the TypeScript pattern that makes invalid states unrepresentable. In test automation, this means: a browser config that can't specify both 'headless: true' and 'channel: chrome' simultaneously; a retry config that can't have both 'maxRetries: 0' and 'retryDelayMs: 5000'; a test environment config that exposes different fields for 'local', 'staging', and 'production' — and fails at compile time if you try to use a staging-only field in a local config.

// Discriminated union for test execution strategies
type TestExecution =
  | {
      mode: 'serial';
      maxWorkers: 1;
    }
  | {
      mode: 'parallel';
      maxWorkers: number;  // Required for parallel, meaningless for serial
      workerIndex?: number;
      totalWorkers?: number;
    }
  | {
      mode: 'sharded';
      shardIndex: number;    // Required for sharded
      shardTotal: number;    // Required for sharded
    };

// TypeScript exhaustiveness check in test runner
function runTests(config: TestExecution): void {
  switch (config.mode) {
    case 'serial':
      // config.maxWorkers — ERROR at compile time! Doesn't exist on serial.
      runSerially();
      break;
    case 'parallel':
      runInParallel(config.maxWorkers);  // maxWorkers is guaranteed to exist
      break;
    case 'sharded':
      // config.shardIndex and config.shardTotal are guaranteed
      runSharded(config.shardIndex, config.shardTotal);
      break;
    default:
      // Exhaustiveness check — if a new mode is added, this line errors
      const _exhaustive: never = config;
      throw new Error(`Unknown mode: ${config}`);
  }
}

// Template literal types for test identifiers
type Feature = 'login' | 'checkout' | 'search' | 'payment';
type TestType = 'e2e' | 'integration' | 'api' | 'visual';

// Type-safe test ID — automatically enforces naming convention
type TestId = `${Feature}-${TestType}-${number}`;

const valid: TestId = 'checkout-e2e-001';   // ✅
// const invalid: TestId = 'checkout-smoke-001'; // ❌ Compile error!

// Record type — all features must have all test types
const testMatrix: Record> = {
  login: {
    e2e: ['login-e2e-001', 'login-e2e-002'],
    integration: ['login-integration-001'],
    api: ['login-api-001'],
    visual: ['login-visual-001'],
  },
  checkout: {
    e2e: ['checkout-e2e-001'],
    integration: ['checkout-integration-001'],
    api: ['checkout-api-001', 'checkout-api-002'],
    visual: ['checkout-visual-001'],
  },
  search: { e2e: [], integration: [], api: [], visual: [] },
  payment: { e2e: [], integration: [], api: [], visual: [] },
};

The discriminated union interview answer: "I use discriminated unions to make invalid test configurations impossible to express. The pattern is: define a union type with a literal discriminant field (like mode: 'serial' | 'parallel' | 'sharded'), and each branch only exposes the fields that are valid for that mode. The advantages cascade: the test runner's switch statement on the discriminant is exhaustively checked — if someone adds a new mode, the compiler flags every branch that needs updating. Invalid combinations — like specifying maxWorkers in serial mode — are caught at compile time, not at runtime when the test executor crashes. And the discriminated union serves as self-documenting configuration — a new team member reading the config type sees exactly which fields belong to which mode, without needing a README. This is the TypeScript pattern that moves test framework design from 'hope you configured it right' to 'you can't configure it wrong.'"

TypeScript-Specific Playwright Patterns — Fixtures, Matchers, and Declaration Merging

Playwright is the dominant E2E testing framework in 2026, and its TypeScript integration is the deepest of any browser automation tool. But most SDETs only scratch the surface — they use Playwright's types, but they don't extend them. Senior panels test for whether you understand Playwright's TypeScript extension points: the fixture type system, the matcher declaration merging, and the typed expect customisation. These are the patterns that distinguish framework consumers from framework extenders.

// Advanced typed fixtures in Playwright
import { test as base, expect } from '@playwright/test';

// Fixture config — discriminated union for different auth strategies
interface AuthConfig {
  role: 'admin' | 'user' | 'viewer';
  tenantId: string;
}

// Extended fixtures with full type safety
type CustomFixtures = {
  authConfig: AuthConfig;
  authenticatedPage: Page;  // Pre-authenticated with authConfig
  apiClient: ApiClient;
};

const test = base.extend({
  authConfig: [{ role: 'user', tenantId: 'default' }, { option: true }],
  
  authenticatedPage: async ({ page, authConfig }, use) => {
    // Login with the configured role
    await page.goto('/login');
    await page.fill('[data-testid="username"]', `${authConfig.role}@test.com`);
    await page.fill('[data-testid="password"]', 'test-password');
    await page.click('[data-testid="login-button"]');
    await expect(page.locator('[data-testid="dashboard"]')).toBeVisible();
    await use(page);
  },
  
  apiClient: async ({ authenticatedPage }, use) => {
    const token = await authenticatedPage.evaluate(
      () => localStorage.getItem('auth-token')
    );
    await use(new ApiClient(token!));
  },
});

// Usage — fully typed
test('admin can view all orders', async ({ authenticatedPage, apiClient, authConfig }) => {
  // authConfig.role is 'admin' — guaranteed
  // apiClient is pre-authenticated — guaranteed
  const orders = await apiClient.getOrders();
  await expect(authenticatedPage.locator('[data-testid="order-count"]'))
    .toHaveText(String(orders.length));
});

// Custom matchers with full TypeScript declaration merging
import { expect, Locator } from '@playwright/test';
import type { Page } from '@playwright/test';

// Step 1: Define the custom matchers
expect.extend({
  async toBeWithinViewport(locator: Locator) {
    const box = await locator.boundingBox();
    if (!box) {
      return { pass: false, message: () => 'Element not found' };
    }
    const viewport = locator.page().viewportSize()!;
    const isVisible = 
      box.x >= 0 && box.y >= 0 &&
      box.x + box.width <= viewport.width &&
      box.y + box.height <= viewport.height;
    return {
      pass: isVisible,
      message: () => isVisible
        ? 'Element is within viewport'
        : `Element at (${box.x}, ${box.y}) is outside viewport`
    };
  },
  
  async toHaveTrimmedText(locator: Locator, expected: string) {
    const text = (await locator.textContent())?.trim() ?? '';
    return {
      pass: text === expected,
      message: () => `Expected trimmed text "${expected}" but got "${text}"`
    };
  },
});

// Step 2: Declaration merging — tell TypeScript about the new matchers
declare global {
  namespace PlaywrightTest {
    interface Matchers {
      toBeWithinViewport(): R;
      toHaveTrimmedText(expected: string): R;
    }
  }
}

// Now fully typed — autocomplete shows both custom matchers
await expect(page.locator('.modal')).toBeWithinViewport();
await expect(page.locator('.title')).toHaveTrimmedText('Welcome');

The Playwright-TypeScript interview answer: "Playwright's TypeScript integration has three extension points that senior SDETs should master. First, typed fixtures — using Playwright's test.extend<MyFixtures>() with nested dependencies and discriminated unions for configuration. The type system enforces that fixture dependencies are satisfied — if fixture B depends on fixture A, TypeScript guarantees A exists when B is constructed. Second, custom matchers with declaration merging — using TypeScript's declare global { namespace PlaywrightTest { interface Matchers<R> { ... } } } to merge custom matcher signatures into Playwright's expect type. Third, typed API mocking — using Playwright's page.route() with typed response bodies that match your API's TypeScript types, so mocked responses are validated against the real response shape at compile time. The throughline: Playwright's types are extensible, not just consumable — and the best test frameworks treat them as a foundation to build on, not a ceiling to work within." For the full Playwright interview landscape, see our Playwright Interview Questions 2026 guide.

Migrating JavaScript Test Suites to TypeScript — Incrementally and Safely

"We have 5,000 JavaScript tests across 200 files. Management wants them in TypeScript. How do you approach this migration?" This is the TypeScript migration question — and it tests whether you can deliver value incrementally, manage risk, and understand that migrating a test suite is a different problem than migrating application code. Tests have runtime validation built in (pass/fail assertions) — the value of TypeScript in tests is catching bugs before they reach CI, not just documenting types.

// Before: any everywhere — no type safety
function parseApiResponse(response: any): any {
  const data: any = JSON.parse(response.body);
  return data.result;
}

// After: unknown with type narrowing — full type safety
interface ApiEnvelope {
  result: T;
  status: 'success' | 'error';
}

function parseApiResponse(response: unknown): T {
  if (typeof response !== 'object' || response === null) {
    throw new TypeError('Response must be an object');
  }
  
  const envelope = response as ApiEnvelope;
  
  if (envelope.status !== 'success') {
    throw new Error(`API error: ${envelope.status}`);
  }
  
  return envelope.result;
}

TypeScript vs Java for Test Automation — The Comparison Every Multi-Language SDET Must Make

The TypeScript-vs-Java question is a fixture in senior SDET interviews — not because there's a right answer, but because the comparison reveals whether you understand tool selection as a trade-off, not a preference. TypeScript dominates the browser and API testing ecosystem. Java dominates the enterprise and mobile testing ecosystem. A senior SDET who can articulate when to use each — and, more importantly, when to bridge them — demonstrates the architectural maturity panels are screening for.

The interview answer that scores highest: "I don't pick TypeScript or Java — I match the language to the testing surface and the team. For browser E2E testing, API contract testing, and component testing in a JavaScript/TypeScript frontend stack — TypeScript with Playwright or Cypress. The ecosystem is TypeScript-native, the iteration speed is faster, and the full-stack developer can own the tests. For mobile testing with Appium, enterprise Java backend testing with Spring Boot, or performance testing with Gatling/k6 — Java. The ecosystem maturity for those domains is still JVM-dominant. In a polyglot organisation with both frontend and backend test suites, I recommend TypeScript for the UI/API layer and Java for the mobile/performance layer — with shared test data and reporting infrastructure (Allure consuming results from both). The architectural skill isn't loyalty to one language — it's knowing where each language's testing ecosystem is strongest and designing a testing strategy that puts the right language on the right surface. For my approach to building polyglot test frameworks, see my Test Automation Framework Design Interview Guide and API Testing Interview Questions 2026."

Common TypeScript Interview Questions for SDET Roles — The Question Bank

After 20 years of SDET interview panels, Mitchell has catalogued the TypeScript questions that appear most frequently in senior and lead-level rounds. Here's the question bank with the answer patterns that score highest:

The meta-pattern that scores highest: interviewers are screening for candidates who treat TypeScript as a design tool, not just a type annotation language. The strongest answers demonstrate type-system fluency (interfaces vs types with architectural reasoning), generic design patterns (typed factories, builders, and utilities that make misuse impossible), async architecture (Promise combinators chosen for the use case, not just the syntax), and practical migration experience (incremental strict mode adoption, the any-to-unknown refactor, metrics-driven migration). The SDET Interview Coach iOS app trains you in exactly this — the TypeScript for SDETs topic covers interfaces vs types, generics in test utilities, async patterns, discriminated unions, and Playwright-specific TypeScript with AI-graded mock interviews scored across type-system depth, framework design, and practical coding patterns. Download it and practise the exact TypeScript questions panels ask before you walk into the room.

Further Reading and Interview Preparation

This guide covers TypeScript for SDET interviews. To complete your test automation interview preparation across the full SDET landscape:

• Playwright Interview Questions 2026 — The Playwright patterns that TypeScript enables. Covers typed fixtures, custom matchers, auto-waiting, Trace Viewer, API mocking with route(), and the Playwright-specific questions that dominate browser automation interviews in 2026.
• Test Automation Framework Design Interview Guide — The framework design methodology that TypeScript generics and discriminated unions elevate. Covers layered architecture, page object patterns, test data strategy, and how to design a framework where TypeScript prevents misuse at compile time rather than discovering it at runtime.
• API Testing Interview Questions 2026 — The API testing patterns where TypeScript's type system shines brightest. Covers typed API clients, generic response handlers, contract testing with Pact, and how to build API test suites where the request type determines the response type at compile time.

The SDET Interview Coach iOS app brings all of this together — 800+ questions across 32 topics, including a dedicated TypeScript for SDETs module covering interfaces vs types, generics in test utilities, async/await patterns, discriminated unions for test config, Playwright-specific TypeScript patterns, and the JavaScript-to-TypeScript migration strategy with AI-graded mock interviews. The app's Job Match feature analyses any SDET job description and generates 50 bespoke questions targeting the specific tools and technologies mentioned — including TypeScript-specific questions when the role mentions Playwright, Cypress, or TypeScript. Download it on the App Store and walk into your interview with the confidence that comes from having practised the exact TypeScript questions panels ask.