QA Automation Engineer Interview Questions and Answers (2026): Selenium, Playwright, Frameworks and Flaky Tests

The short answer: QA automation interviews test whether you can build automated tests that are fast, reliable and worth maintaining, not just write scripts. Expect questions on what to automate (and what not to), Selenium WebDriver (locators, waits, the Page Object Model, Grid), newer tools such as Playwright and Cypress, framework design, API automation, flaky tests, CI/CD and parallel runs, and test data, plus a coding exercise in your framework’s language. Senior candidates get more on strategy, architecture and influencing developers. For testing fundamentals (test design techniques, bug reports, severity vs priority), see our QA interview questions.

The job market

The U.S. Bureau of Labor Statistics reports a median annual wage of $104,300 for software quality assurance analysts and testers in May 2025. It projects employment of software developers, QA analysts and testers combined to grow 10% from 2025 to 2035, much faster than average, with about 106,100 openings a year.

Automation strategy questions

“What should you automate, and what shouldn’t you?”

Automate tests that run often and are stable: regression suites, smoke tests, critical user journeys, API contracts, data-driven checks with many inputs. Don’t automate one-off checks, features still changing daily, or things that need human judgment (usability, visual design, exploratory testing). Automation pays off when a test runs many times.

“What is the test pyramid?”

Many fast unit tests at the base, fewer integration and API tests in the middle, and a small number of end-to-end UI tests at the top, because UI tests are the slowest and most fragile. A common anti-pattern is the “ice cream cone”: mostly UI tests and few unit tests.

“How do you decide what to cover first?”

By risk: business-critical flows (sign-up, checkout, payments), areas with frequent defects, and code that changes often.

Selenium WebDriver questions

• “What is Selenium WebDriver?” A library that drives real browsers through the W3C WebDriver protocol, with bindings in Java, Python, C#, JavaScript, Ruby and more.
• “Which locators do you prefer?” Stable, unique ones: IDs or dedicated test attributes (such as data-testid) first, then CSS selectors. Avoid long absolute XPaths that break when the layout changes.
• “Explain implicit, explicit and fluent waits.” An implicit wait sets a global time to poll for elements; an explicit wait waits for a specific condition (element clickable, text present); a fluent wait is an explicit wait with a custom polling interval and ignored exceptions. Selenium’s documentation warns not to mix implicit and explicit waits, because it can cause unpredictable wait times; its example is a 10-second implicit wait and a 15-second explicit wait causing a timeout after 20 seconds. Never use fixed sleeps.
• “How do you handle a StaleElementReferenceException?” The element was re-rendered after you found it. Locate it again right before interacting, and wait for the page state you need.
• “How do you handle iframes, new windows and alerts?” Switch context with switchTo().frame(), switchTo().window() and switchTo().alert(), then switch back.
• “What is Selenium Grid?” A way to run tests in parallel across machines, browsers and operating systems.

Page Object Model and framework design

“What is the Page Object Model?”

A design pattern where each page or component is a class that holds its locators and actions (loginPage.signIn(user)), so tests read like user steps and a UI change is fixed in one place. Keep assertions in the tests, not in page objects.

“How would you design an automation framework from scratch?”

“I’d start from what the team needs: which layers to test, which languages the developers use, and where tests will run. A typical structure: a test runner (JUnit or TestNG, pytest, or the Playwright test runner), page objects or component objects for UI, a separate API client layer, configuration per environment, test data builders, reporting with screenshots and traces on failure, and CI integration from day one. I’d keep it simple, document conventions, and review test code like production code.”

• “Data-driven vs keyword-driven vs BDD?” Data-driven runs the same test with many inputs; keyword-driven builds tests from reusable action keywords; BDD (for example, Cucumber with Gherkin) writes scenarios in business-readable language. BDD helps when business people actually read the scenarios; otherwise it can add overhead.

Playwright and Cypress questions

• “Why might a team choose Playwright over Selenium?” Playwright’s documentation says it performs actionability checks on elements before actions and auto-waits for those checks to pass, which removes much of the manual waiting that causes flaky tests. It also has built-in tracing, parallel workers, multiple browser engines and network interception. Selenium has broader language support, a long history and a large ecosystem.
• “What are Cypress’s strengths and limits?” A fast, developer-friendly runner with automatic waiting and good debugging, traditionally JavaScript and TypeScript only, and running inside the browser, which affects some multi-tab and cross-origin scenarios.
• “Which would you pick?” It depends on the team’s languages, browsers to support, existing tests and CI. Show you can compare, not just name a favorite.

API automation questions

• “How do you automate API tests?” Use a client library or tool (for example REST Assured, requests with pytest, or Playwright’s API testing) to check status codes, response schemas, business rules, error handling and authentication, with test data set up through the API itself.
• “Why test at the API level?” It’s faster and more stable than UI testing, and many business rules can be verified without a browser. Use UI tests for the journeys that truly need the UI.
• “What is contract testing?” Checking that a service provider and its consumers agree on the API’s shape, so changes that break consumers are caught before deployment.

Flaky test questions

“What is a flaky test, and how do you deal with it?”

A test that passes and fails without code changes. Common causes: timing and waits, shared or leftover test data, test order dependencies, unstable environments, animations, and third-party services.

“I track flaky tests from CI history, quarantine the worst ones so they don’t block merges, and fix the cause rather than adding retries: replacing sleeps with condition-based waits, giving each test its own data, removing order dependencies and mocking unstable external services. On my last team we cut the flaky rate of our end-to-end suite from about 8% of runs to under 1% in two months, mostly by fixing waits and test data.”

Retries can hide real bugs, so if you use them, report retried tests separately.

CI/CD and scale questions

• “How do automated tests fit into CI/CD?” Fast unit and API tests on every pull request, a smoke suite after each deployment, and fuller regression suites on a schedule or before release, with results that block merges when critical tests fail.
• “Your suite takes two hours. How do you speed it up?” Run tests in parallel, push checks down the pyramid to API or unit level, remove duplicate tests, use API calls for setup instead of the UI, and run only affected tests on pull requests.
• “How do you run tests in containers?” Use Docker images with browsers, or a hosted grid, so every run has the same environment.

Test data and environment questions

• “How do you manage test data?” Create the data each test needs through APIs or builders, clean it up afterwards, avoid depending on shared records, and mask production data if you use it.
• “How do you test against an unstable environment?” Isolate external dependencies with mocks or stubs where the dependency isn’t what you’re testing, add health checks before runs, and report environment failures separately from product failures.

Coverage and metrics questions

• “How do you measure the value of automation?” Defects caught before release, time saved on regression, how fast feedback reaches developers, flaky rate, and escaped defects. Code coverage shows what was executed, not whether behavior was verified.
• “What does 100% automation mean to you?” Usually an unhelpful goal: some testing should stay exploratory and human.

Coding exercise questions

Expect a short task in Java, Python or JavaScript, for example:

• Write a Selenium or Playwright test for a login page with a page object.
• Reverse a string, find duplicates in an array, or count word frequency.
• Parse a JSON API response and assert on specific fields.

Write readable code, name things clearly, handle waits correctly, and talk through your choices. See our software engineer coding interview guide.

Questions for experienced (5 to 10 years) automation engineers

• “How have you introduced or replaced an automation framework, and how did you migrate existing tests?”
• “How do you get developers to own tests?”
• “How do you decide the balance between UI, API and unit tests across teams?”
• “Tell me about the worst flaky-test problem you solved.”
• “How do you use AI tools in test automation, and where don’t you trust them?”
• “How would you set up quality gates for a team moving to continuous deployment?”

Behavioral questions

• “Tell me about a critical bug your automation caught.”
• “Tell me about a time you pushed back on a release.”
• “Tell me about a time a test suite you owned became unreliable. What did you do?”

Use the STAR method and include numbers: suite runtime, flaky rate, defects caught.

Related guides: QA interview questions, Jenkins interview questions, Web API interview questions and DevOps engineer interview questions.

Frequently asked questions

Sources

• U.S. Bureau of Labor Statistics, Software Developers, Quality Assurance Analysts, and Testers, Occupational Outlook Handbook. Read on 2 October 2026.
• Selenium, Waiting Strategies. Read on 2 October 2026.
• Playwright, Auto-waiting. Read on 2 October 2026.