Skip to main content
Donate
BLOG / QA & SDET

Interview prep and automation guides.

Practical, opinionated articles from a working SDET — covering interview loops, framework design, flakiness, CI/CD, API testing, and AI-driven quality engineering.

Interview PrepCareerFramework DesignPlaywrightAutomationFlaky TestsCI/CDAPI TestingContract TestingLearning PathTest StrategyAI TestingLLMsPipeline DesignQuality Gates
FEATURED
8 min read
Interview PrepCareerFramework Design

How to prepare for a senior SDET interview loop

Most candidates fail the loop not because they can't code — but because they prepare for the wrong rounds.

The senior SDET loop typically runs four to six rounds: a coding screen, a framework design session, a test strategy deep-dive, a behavioural round, and sometimes a take-home. The coding screen matters less than most candidates assume. Hiring managers are not looking for LeetCode hard solutions — they are evaluating whether you write testable code, handle edge cases naturally, and think about reliability. A clean, readable implementation that covers boundary conditions beats a clever algorithm with no error handling.

The framework design round is where most candidates lose the offer. The weak answer describes a stack: Playwright, Page Object Model, GitHub Actions. The strong answer asks clarifying questions first — what is the release cadence, what is the risk profile, who owns the suite after handoff, what existing CI infrastructure is in place? Then it proposes a layered strategy with explicit reasoning for each choice. The interviewer is not assessing whether you know Playwright. They are assessing whether you can think architecturally about quality.

Behavioural rounds for SDET roles are routinely under-prepared for. The questions are not about teamwork and communication — they are about quality judgment under pressure. Expect: 'Tell me about a time you pushed back on releasing a feature you felt was not ready.' 'Describe a defect escape. What changed in your process?' 'How did you handle a team that kept bypassing the test suite?' These require STAR answers with specific numbers, tools, and outcomes, not general statements about caring deeply about quality.

The test strategy round rewards risk-based thinking, not comprehensive checklist coverage. The question is not 'what tests would you write?' It is 'given limited time and a production deadline, where does the most testing value per hour sit?' Candidates who demonstrate that instinct — who can rank coverage decisions by risk — signal the seniority level that senior roles require.

KEY TAKEAWAYS

  • Treat the framework design round as a systems thinking exercise, not a tool name-drop.
  • Prepare three to four STAR stories specifically about quality decisions under pressure — not generic teamwork examples.
  • Know your portfolio automation projects in forensic detail: numbers, failure modes, what you would do differently.
  • The test strategy round rewards prioritisation by risk — not the longest list of test types.
  • Know your target company's tech stack and prepare framework-specific depth for the two most likely subjects.
Practice a mock SDET interview →
ALL ARTICLES · 8 POSTS
7 min read
PlaywrightAutomationFramework Design

Playwright framework design: what hiring managers actually look for

The answer 'I use POM with TypeScript and GitHub Actions' is correct and forgettable. Here is what makes candidates stand out.

Playwright has become the default surface for senior SDET interviews, and most candidates answer it the same way: 'I use Page Object Model with TypeScript fixtures, run it in GitHub Actions with sharding.' That answer is correct and forgettable. The candidates who stand out demonstrate that they have thought about the tradeoffs Playwright forces you to make — and made deliberate, defensible choices rather than following a tutorial.

KEY TAKEAWAYS

  • Describe fixtures as composition tools with explicit scope reasoning — not just setup and teardown.
  • Know your selector hierarchy and be able to justify every level: role > test ID > CSS > XPath.
  • Have a specific flakiness investigation process: trace-first, then isolation, then quarantine.
Study Playwright interview questions →
6 min read
Flaky TestsAutomationCI/CD

Why your test suite is flaky — and the fixes that actually work

Flakiness is not a test problem. It is a trust problem. Once the team stops believing in red builds, the suite stops providing value.

Flakiness is the most expensive problem in test automation, and not primarily because of the engineering hours spent investigating failures. The real cost is invisible: the team gradually stops trusting the suite. They rerun everything until it passes. They treat red as the new yellow. They merge on green without checking what the green actually covers. By that point the test suite is providing ritual, not signal.

KEY TAKEAWAYS

  • Categorise failures before fixing: interdependence, timing, environment coupling, or genuine non-determinism — the fix is different for each.
  • Quarantine flaky tests immediately. One unresolved flaky test in the main suite halves the team's confidence in every other test.
  • Per-test isolation is non-negotiable: own your data, use fresh contexts, clean up completely.
Practice CI/CD and automation questions →
7 min read
API TestingContract TestingInterview Prep

API testing beyond Postman: what SDETs get wrong

Verifying a response is not the same as testing an API. The gap between those two activities is where most SDET candidates lose interview points.

Postman is an excellent exploration tool. It is a mediocre test automation framework. The gap most candidates fail to articulate is the difference between verifying an API response and actually testing an API. Verifying a response means checking that the status code is 200 and the body contains an id field. Testing an API means probing contracts, state machines, failure modes, and integration boundaries — with the explicit goal of finding the conditions under which the system misbehaves.

KEY TAKEAWAYS

  • Shift test effort from happy-path coverage to failure-mode coverage: auth expiry, missing fields, upstream failures, retries.
  • Understand the difference between schema validation (API matches its docs) and contract testing (docs match consumer needs).
  • Learn Pact at the conceptual level at minimum: pactfile generation, broker publishing, provider verification in CI.
Study API testing interview questions →
9 min read
CareerLearning PathAutomation

From manual QA to SDET: the honest 12-month path

Most transition timelines online are dishonestly optimistic. Here is what the path actually requires and roughly how long each phase takes.

Most 'manual to automation' content online is dishonestly optimistic. Learn Selenium in a weekend, land an SDET role in three months. The reality is that SDET positions require programming competency, framework design judgment, debugging ability, and CI/CD literacy — none of which can be absorbed in a few weekends of tutorial completion. Twelve months of structured, deliberate practice with working code is a realistic timeline for a motivated manual tester. Six months is possible with prior programming exposure. Three months is marketing copy.

KEY TAKEAWAYS

  • Twelve months is realistic for motivated manual testers with zero prior programming; plan accordingly.
  • Programming fundamentals before automation frameworks — debugging instinct is what separates SDETs from script writers.
  • One polished, fully explainable portfolio project beats ten tutorial completions on a resumé.
Explore the QA learning roadmap →
6 min read
Interview PrepTest StrategyCareer

How to answer the test strategy question without sounding generic

'Unit tests, integration tests, E2E tests following the pyramid' is correct and immediately forgettable. Here is how senior candidates answer this question.

Walk me through how you would design a test strategy for this feature is the question that determines seniority more than any other in the SDET interview loop. It appears in every senior and staff-level interview because it reveals whether you can reason about risk and trade-offs, or whether you have memorised a testing taxonomy. The generic answer — unit tests, integration tests, E2E tests, smoke tests on deployment, test pyramid — is both technically correct and immediately forgettable. Every candidate says it. It tells the interviewer nothing about your judgment.

KEY TAKEAWAYS

  • Ask clarifying questions about risk, business impact, and engineering context before naming any test types.
  • The test pyramid is a reasoning framework, not an answer — use it to justify choices, not substitute for them.
  • Be specific: name the exact logic, flows, or boundaries each layer covers and why a lower layer cannot cover it instead.
Practice the strategy round →
8 min read
AI TestingLLMsCareer

AI in testing: what is real, what is hype, and what to actually learn

Two camps have formed — believers and dismissers. Both are wrong. Here is a calibrated view from the testing floor.

The AI in testing space has split into two camps: vendors claiming their tools eliminate the need for SDETs, and engineers dismissing all AI tooling as unreliable noise. Both positions are wrong, and they are wrong in ways that are costly to your career. The engineers who will be most effective are the ones who can distinguish genuine leverage from marketing copy — and who can explain that distinction clearly in an interview when asked about AI-driven testing.

KEY TAKEAWAYS

  • Use LLMs for test case ideation and first-draft generation — human review for domain accuracy is non-negotiable.
  • Autonomous test generation is not production-ready for non-trivial business logic — evaluate carefully before adoption.
  • Learn to build evaluation harnesses: labelled datasets, reproducible model runs, and metric-based pass/fail gates.
Study AI testing concepts →
7 min read
CI/CDPipeline DesignQuality Gates

CI/CD quality gates: fast feedback or false confidence?

A green pipeline does not mean the code is ready to ship. It means the code passed the checks you put there. Those are not the same thing.

A CI pipeline that passes does not mean the code is ready to ship. It means the code satisfied the checks you put in the pipeline — and the quality of those checks is exactly what most teams have never explicitly examined. False confidence from CI is more dangerous than no CI. A team with no pipeline knows it has no automated safety net. A team with a consistently green pipeline that does not actually catch regressions believes it has protection it does not have. Defect escapes in that environment are particularly damaging because they contradict the team's conviction about their own process quality.

KEY TAKEAWAYS

  • Measure pipeline false-negative rate: how often does a green pipeline precede a production defect?
  • Layer quality gates by speed and scope — fast pre-merge smoke, full post-merge suite, canary pre-deploy check.
  • Track and publish per-test flake rates; high flake rates destroy the signal value of the entire suite.
Practice CI/CD interview questions →
PRACTICE

Apply what you just read

Run a mock interview on any of the topics covered in these articles and get immediate scoring feedback.

Start mock interview