Senior SDET Interview Questions: 30 Most Asked (1970) — Architecture, Leadership & Behavioral

Structure your answer in three layers — test layers, tooling, maintenance — so the interviewer can see the whole pyramid in 60 seconds:

Test Layer:
- Unit tests (Jest, JUnit) — fast, isolated
- Integration tests (REST Assured, Postman) — API + DB
- E2E tests (Playwright, Selenium) — full user journeys

Tools:
- Framework: Playwright + TypeScript
- Reporting: Allure + Mochawesome
- CI: GitHub Actions with matrix strategy

Maintenance:
- POM for each page
- Fixtures for setup/teardown
- Component POM for shared UI
- Test data factories

For the underlying Playwright setup, see our Playwright Complete Guide.

Use a simple, defensible formula:

• Time saved = (manual test hours) × (runs per year) − (automation maintenance hours)
• Cost saved = Time saved × hourly rate
• ROI = (Cost saved − Investment) / Investment × 100

Worked example: Manual regression = 8 hours × 50 releases/year = 400 hours. Automation maintenance = 40 hours/year. Time saved = 360 hours × $80/hour = $28,800. Investment = $20,000. ROI = 44%.

See our QA Automation Framework Consulting guide for more.

Root-cause analysis first, retry second. The senior answer is always "fix the cause, don't mask it":

1. Identify the root cause (race condition, network, shared state).
2. Fix the underlying issue.
3. Use retries only as a last resort, with a flake dashboard.
4. Quarantine persistent flakes from main CI.

Never mask flakiness with blanket retries — it hides real bugs. See our Selenium WebDriver Guide for synchronization deep-dive.

The pyramid:

• Many unit tests (60–70%)
• Moderate integration tests (20–30%)
• Few E2E tests (5–10%)

How I apply it in production:

• 500 unit tests — run on every commit
• 100 integration tests — run on every PR
• 30 E2E tests — run nightly + pre-release

See our Test Pyramid Explained.

• Pair with devs on testability during design
• Static analysis on every PR
• Contract tests on every merge
• Feature flags for safe progressive rollout
• Test plan reviewed during backlog grooming

See our Shift-Left Testing Guide.

Three-phase approach — never a big-bang rewrite:

1. Pilot — 1 team, 1 feature, prove the value.
2. Scale — 3–5 teams running both in parallel.
3. Migrate — convert all tests, retire Selenium.

For the full migration playbook, see our Playwright Cloud Testing guide.

Tell a real story in five beats so the interviewer remembers it:

• Symptom — what users saw
• Root cause — why it happened
• Fix — what was changed
• Prevention — the test/guardrail added so it never recurs
• Impact — users, revenue, time saved

Quantified outcomes are what separate senior answers from mid-level.

• Pair-programming sessions on real tickets
• Code reviews with detailed, kind feedback
• Pair on the hardest debugging — they learn the muscle
• Brown-bags on testing topics they pick
• A documented growth path with quarterly check-ins

1. Re-read the requirement.
2. Reproduce the bug calmly with steps.
3. Gather data — logs, screenshots, network traces.
4. Discuss with the developer, not at them.
5. Escalate to PM only if needed.
6. Never make it personal.

• Externalize test data (JSON, CSV, fixtures)
• Use factories for unique-per-test data
• Reset state in beforeEach
• Avoid shared mutable state at all costs
• Mock external services to stay deterministic

• Contract testing with Pact between services
• Integration tests against real services with Testcontainers
• End-to-end tests only for critical flows
• Performance tests for inter-service calls (latency budgets)

See our Microservices Testing Strategy.

The consumer publishes the expectation; the provider verifies against it on every build. This catches breaking changes pre-merge, not in production.

// Consumer side
const provider = new Pact({ consumer: 'Frontend', provider: 'UserService' });
test('GET /users/1', async () => {
  await provider.addInteraction({...});
  const user = await fetchUser(1);
  expect(user.email).toBe('test@example.com');
});

• Validate queries, mutations, and subscriptions
• Test query depth limits to prevent abuse
• Confirm introspection is disabled in production
• Test partial errors and union/interface resolution

See our GraphQL API Testing Guide.

• Unit + integration on every commit
• Smoke E2E on every PR
• Full E2E nightly + pre-release
• Parallel execution (50+ workers)
• Failed-test quarantine lane so a flake never blocks merges

• Ephemeral environments per PR (one URL per branch)
• Docker Compose for local parity
• Staging mirrors production data (with PII scrubbed)
• Mock external services at the network layer

• Page POM — one class per page
• Component POM — one class per reusable component
• Fragment POM — shared UI fragments (nav, modal)
• Fluent POM — methods that return the next page object for chainable flows

For the full POM pattern, see our Playwright POM with TypeScript guide.

Combine the test pyramid with risk-based testing:

• High-risk + high-frequency → automate first
• High-risk + low-frequency → automate if cheap to maintain
• Low-risk + high-frequency → automate
• Low-risk + low-frequency → keep manual

• Smoke tests on every PR (fast feedback)
• Full suite nightly (covers all endpoints)
• Schema validation on every test
• Contract tests for every service boundary

See our API Testing Tutorial.

• OWASP Top 10 checklist as the baseline
• SQL injection, XSS, BOLA test suites
• Authentication / authorization regression tests
• SAST + SCA + DAST wired into CI

See our OWASP Security Testing Checklist.

• Smoke load test on every CI run
• Full load test pre-release
• Stress test quarterly
• Soak test monthly
• Tooling: k6 for devs, JMeter for QA-led runs

See our Performance Testing Certification guide.

• axe-core automated checks in CI
• Screen-reader manual testing (NVDA / VoiceOver)
• Keyboard-only navigation testing
• Colour-contrast checks
• WCAG 2.2 AA as the compliance bar

See our Accessibility Testing WCAG Guide.

• Espresso for Android (in-app, fast)
• XCUITest for iOS (in-app, fast)
• Appium for cross-app and cross-platform suites
• Real-device cloud for device-coverage breadth

See our Appium Tutorial.

• AI drafts test cases from requirements
• AI self-heals broken locators
• AI agents navigate the UI autonomously for exploratory passes
• A human reviews every AI-generated artifact before merge
• Build vs. buy depends on scale and data-sensitivity

See our AI in Software Testing.

Show business outcomes, not vanity metrics:

• Defect escape rate ↓ from 8% to 1.5%
• Cycle time ↓ from 48h to 14h
• One prevented P0 bug = $50k saved
• Faster releases = faster revenue

"I prevent bugs by building quality into the platform, not by finding bugs after they're shipped."

Express your own version. Senior interviewers care that you have a philosophy, not the exact words.

• Read testing blogs and newsletters weekly
• Attend conferences — SeleniumConf, TestBash
• Contribute to open-source test tools
• Experiment with a new tool every month
• Mentor others — teaching reinforces learning

Tell a STAR story with a quantified outcome:

• Situation: "Our regression suite took 8 hours."
• Task: "Reduce it to under 1 hour."
• Action: "Migrated from Selenium to Playwright, added parallelism, removed redundant tests."
• Result: "Down to 45 minutes, flake rate from 12% to 2%, defect escape from 8% to 1.5%."

• Runbook for the top-10 common issues
• Clear escalation path with named owners
• Pre-written communication templates
• Post-incident review for every incident
• A regression test added so the same bug never recurs

Tell a real story with the lesson learned. Senior interviewers look for humility, ownership, and growth — not perfection. End with the guardrail you added so it won't happen again.

Connect your skills to their needs. Reference their product, their tech stack, and the specific problem you'd love to solve in the first 90 days. Generic answers are an immediate downgrade.