// Interview Prep/Mock Interviews/SDET technical mock interview

🔬 SDET technical mock interview

Set a timer, work through each round out loud, then score your answers against the rubric. No one is listening — the goal is honest self-assessment, not a perfect performance.

Senior⏱ 60 min·SDET

// ROUND STRUCTURE

  1. 1
    Warm-up— 5 min

    Background, current tech stack, and what you've built vs used.

  2. 2
    Framework architecture— 20 min

    Design decisions, extensibility patterns, SDK design for teams.

  3. 3
    Infrastructure & CI— 15 min

    Containerisation, parallelism at scale, observability, test quality metrics.

  4. 4
    System design— 15 min

    Design a test platform for a given multi-team scenario.

  5. 5
    Wrap-up— 5 min

    Candidate questions and interviewer summary.

// INTERVIEW QUESTIONS

  1. 01

    You need to build a UI automation framework from scratch for a 50-engineer team. Walk me through your architecture decisions.

  2. 02

    How do you design a framework so teams can extend it without modifying the core?

  3. 03

    What is the difference between a test framework and a test harness?

  4. 04

    How do you run UI tests in parallel without test interference?

  5. 05

    Walk me through how you'd containerise a Playwright suite for CI at scale.

  6. 06

    How do you track and enforce test quality — flakiness, coverage, and execution time — at team scale?

  7. 07

    A junior dev asks: 'Should our E2E tests call the database directly to set up state?' How do you answer?

  8. 08

    Design a test platform to support 5 product teams, 3 different tech stacks, and a 15-minute CI budget.

  9. 09

    How do you decide what belongs in unit tests vs integration vs E2E?

// EXPECTED ANSWER POINTS

Compare your answers to these points — one per question, in order.

  1. Framework decisions: (1) Language/ecosystem matching the team's primary stack. (2) Driver/browser management — abstracted via a factory, auto-managing versions. (3) Base page abstraction with wait utilities, not raw WebDriver calls. (4) Test data strategy — API-based setup, isolated per worker. (5) Reporting — Allure or Extent with artefact upload to CI. (6) Parallel execution model — workers with isolated contexts. (7) Lint rules and PR gate to enforce framework usage. Document the 'why' for every decision.

  2. Open/Closed Principle: Strategy pattern for reporters (swap Allure for Extent without changing tests), Factory pattern for driver creation (add a new browser without changing page objects), plugin hooks for pre/post test events. Configuration injection instead of hard-coded values. Publish as an internal package with semantic versioning so teams upgrade on their schedule.

  3. Framework = the reusable test infrastructure: base classes, wait utilities, configuration, reporting integrations, helper libraries. Harness = the execution environment: containers, parallel runner configuration, CI pipeline steps, result collection, environment provisioning, scheduling. A framework runs inside a harness. An SDET builds both; a senior automation QA typically builds the framework and uses an existing harness.

  4. Parallel without interference: each worker gets an isolated browser context (Playwright) or browser instance (Selenium). Test data is created fresh per test via API — no shared DB rows. No shared file system state between workers. Feature flags or test environments per worker for destructive tests. Randomised identifiers prevent name collisions.

  5. Containerise Playwright: use the official Playwright Docker image (mcr.microsoft.com/playwright) with browsers pre-installed. Pin image tag to match your @playwright/test version. In CI: docker-compose for local dev grid, Kubernetes Jobs or GitHub Actions matrix for scale. Mount a shared volume for screenshots/traces/videos — artefact upload in the post step. Run containers as non-root for security.

  6. Flakiness: instrument every test with a flakiness tracker (pass/fail/flaky status per test per run, stored in DB or test management tool). Alert when a test exceeds a 5% flake rate. Quarantine policy: tests above 10% are blocked from merging until fixed. Coverage: track by feature area, not just line count. Execution time: alert on regressions — a test that triples in duration is a canary for a real issue.

  7. No — E2E tests should set up state through the same interfaces a real user or service would use (API calls, UI flows). Direct DB writes bypass the application layer, meaning the test does not cover the creation path and relies on DB schema knowledge that diverges from the app. Use API factories for fast, realistic state setup. Direct DB access is acceptable only in teardown when the API does not expose a deletion endpoint.

  8. Multi-team platform: (1) Shared framework library published as an internal npm/Maven/pip package with version pinning. (2) Team-specific config files that override base settings (base URL, environment, credentials). (3) Unified reporting dashboard (centralised Allure server or TestRail integration). (4) CI: each team runs in an isolated container matrix; 15-minute budget enforced via risk-based selection — smoke suite (critical paths, 5 min) on every PR, full suite nightly. (5) Onboarding runbook and a framework team to own upgrades.

  9. Unit tests: pure logic, no I/O or external dependencies, millisecond execution, highest count. Integration tests: service boundaries with real or test-double dependencies (DB, cache, downstream service), second-range execution. E2E tests: critical user journeys only — not every scenario, not every edge case. The test pyramid inversion (E2E-heavy) is expensive in execution time and maintenance. Cover the same behaviour at the lowest layer possible.

// SCORING RUBRIC

Strong (4–5)

Names design patterns (Strategy, Factory, Open/Closed) and applies them to test infrastructure. Distinguishes framework from harness clearly. Has containerised test suites. Gives a concrete multi-team platform architecture. Articulates the test pyramid with cost/benefit reasoning.

Acceptable (3)

Can design a framework with reasonable decisions but lacks platform-level thinking. Knows patterns conceptually but cannot articulate how they apply. CI knowledge is surface level. Cannot design for multi-team scale.

Weak (1–2)

Describes using an existing framework without modifications. No infrastructure knowledge. Recommends direct DB writes without qualification. Cannot explain the difference between a framework and a harness. No knowledge of containerisation for testing.

// RED FLAGS

Answers or behaviours that signal a weak candidate to the interviewer.

  • Cannot distinguish between a test framework and a test harness.

  • Recommends Thread.sleep or direct DB writes for test setup without any qualification.

  • Has only used existing frameworks — has not authored or extended one for a team.

  • Cannot name a design pattern they have applied to test code.

  • No knowledge of containerisation for test execution.

  • Cannot articulate why E2E tests should not replicate unit test coverage.

// FOLLOW-UP QUESTIONS

Questions a strong interviewer adds if you answered the main round well.

  1. 01

    How do you handle breaking changes when upgrading a shared framework that multiple teams depend on?

  2. 02

    What observability hooks would you build into a test framework — what events would you expose?

  3. 03

    How do you onboard a team of manual QAs onto a new automation framework with no automation experience?

// SELF-ASSESSMENT CHECKLIST

Tick these off mentally after the mock. Be honest — this is for you, not for the interviewer.

  • I described a framework architecture with at least four concrete decisions and their rationale.
  • I named at least two design patterns and explained why they apply to test framework extensibility.
  • I gave a concrete answer on containerisation — specific image, volume strategy, CI execution model.
  • I correctly answered the DB setup question with the right rationale (bypass the application layer).
  • I designed a multi-team platform with the 15-minute CI constraint as a hard requirement.
  • I articulated the test pyramid with cost/benefit reasoning for each layer.

// RECOMMENDED NEXT MOCK

👑 QA Lead mock interview

Senior · 45 min

// STUDY THESE NEXT

SDET role track →SDET prep plan →Practical assignments →All question banks →