🔀 QA → SDET interview prep

// WHO THIS IS FOR

For manual testers and traditional QA engineers actively transitioning into automation and SDET roles — building coding fluency, a first framework, and CI familiarity while leveraging the strong testing instincts they already have. Interviewers for these roles know you are a switcher: they value your testing foundation and want evidence of genuine, self-directed progress in code.

// SKILLS INTERVIEWERS EXPECT

Green = most frequently tested

// TYPICAL INTERVIEW ROUNDS

1. 1

   Transferable fundamentals

   Interviewers for switcher roles know your testing depth is a strength and your coding is a work-in-progress. This round probes your test-design instincts — equivalence partitioning, boundary values, exploratory heuristics, defect lifecycle — and asks how those foundations carry into automation thinking. Strong answers show that your manual experience actively shapes how you write tests in code: you already know what to assert, what edge cases matter, and what a good bug report looks like.

2. 2

   Coding screen (lightweight)

   Basic JavaScript or TypeScript: variables, functions, arrow functions, array methods (map, filter, find), async/await, and simple error handling. The bar is lower than a pure SDET role, but you must demonstrate genuine coding fluency — not copy-pasted snippets. Common exercises: transform an array of test data, write a small helper that retries a flaky operation, or parse a JSON response and assert on a field. Interviewers want evidence of a consistent learning habit, not perfection.

3. 3

   Automation basics

   Write or extend a simple test in Cypress or Playwright against a given URL or staging environment. You are expected to: pick stable locators (preferring ARIA roles or data-testid over brittle XPath), write a meaningful assertion beyond just 'page loaded', and handle setup/teardown cleanly. Interviewers look for the translation of your test-design instincts into code — your locator choices, your assertion coverage, and the way you handle a failure all signal how far your learning has progressed.

4. 4

   Behavioural and motivation

   Why the switch, what you have built or studied so far, and how you are handling the learning curve. Interviewers want to see self-directed momentum: a practice repository, a completed course, a test suite you built against a real or demo app — not just 'I want to move into automation'. Strong candidates articulate exactly where their skills are today, what they are actively building, and how their testing background gives them an advantage over candidates who can code but cannot test.

// TOPICS TO STUDY

• JavaScript/TypeScript fundamentals: variables, functions, arrow functions, array methods, destructuring
• async/await and Promises: why they matter in Playwright and Cypress — and how to avoid unhandled rejections
• Cypress vs Playwright: command queue vs async/await model, auto-wait differences, when to choose each
• Locator strategy: prefer ARIA roles and data-testid; understand why XPath and CSS class selectors break
• Git workflow: clone, branch, commit, push, open a pull request — the daily loop on any team
• CI basics: running tests on push with GitHub Actions, reading a failing pipeline, fixing a broken build
• Leveraging your manual experience: test design and exploratory instincts are a genuine advantage — automation encodes them, it does not replace them
• Debugging test failures: reading Playwright trace viewer output, Cypress screenshots and video, stack traces
• Common beginner pitfalls: hard-coded sleeps instead of auto-waits, over-reliance on XPath, testing implementation detail instead of user-visible behaviour

// READINESS SELF-CHECK