QA Engineer Interview Questions for Each Hiring Stage | Kore BPO
Nearshore Hiring

QA Engineer Interview Questions: What to Ask at Each Stage

August 19, 2026
10 min read
Last updated: August 19, 2026
Interviewer taking notes while QA engineer candidate speaks across conference table
Quick Answer
What QA engineer interview questions should you ask?
QA engineer interview questions should cover three areas: test design methodology (equivalence partitioning, boundary value analysis, exploratory testing), automation tool proficiency (writing a Cypress or Selenium test live), and English communication through an async written screen before the first call. Structure interviews in three rounds to cut efficiently without wasting engineer time.
Start with async written screen to filter English and written communication before any live calls
Round 2 tests test design thinking, not automation vocabulary
Round 3 live coding screen is non-negotiable for automation roles
See pre-screened nearshore QA candidates at korebpo.com/nearshore-qa-engineers

Last updated: August 19, 2026

The questions most teams ask in QA interviews are the wrong questions. Asking a candidate to define equivalence partitioning does not tell you whether they can apply it to your specific feature specification. Similarly, asking whether they have “experience with Cypress” does not tell you whether they can write a page object model or handle asynchronous test failures. This guide replaces generic interview lists with actual questions, the reasoning behind each, and what a strong answer looks like versus a weak one.

All 15+ questions below are organized by interview round so you can run a structured process that generates comparable signal across candidates. As a result, you avoid burning your engineering team’s calendar on weak candidates who should have been filtered in Round 1.


Interview Structure Overview

A well-structured QA interview process for nearshore candidates has four rounds, each with a specific gate. The total time investment for your team on a strong candidate is approximately 2.5 hours across all rounds. By contrast, the total time on a candidate who fails Round 1 is approximately 15 minutes of review time.

RoundFormatDurationPurpose
Round 1: Async ScreenWritten exercise (async)Candidate: 20 min / Reviewer: 10 minFilter English and written communication
Round 2: Test DesignLive video call45 minAssess test design methodology depth
Round 3: Automation ScreenLive coding (shared screen)60 minVerify hands-on automation skill
Round 4: Team FitLive video call30 minSprint integration and communication style

When working with a nearshore staffing agency like Kore BPO, candidates have already passed an internal technical and English screen before you see their profile. In that case, you can often compress Round 1 and Round 2 into a single 60-minute session, reducing time-to-offer by one calendar week. This compression alone can make a meaningful difference in whether you land the best candidates before a competitor does.


Round 1: English and Async Written Screen

Send this exercise by email or via a shared document. Ask the candidate to complete it without assistance and return it within 24 hours. Specifically, you are looking for clear written English, logical structure, and the ability to communicate a technical observation to a non-technical stakeholder.

QA engineer candidate in professional interview setting, confident and attentive
Async Question 1
You are testing a login form. During exploratory testing, you discover that entering a password of exactly 256 characters causes the form to submit successfully but the user cannot access any features after login. Write a bug report for this issue as you would submit it to the development team in Jira.
Strong answer includes: A descriptive title (e.g., “Login succeeds for 256-char passwords but blocks feature access post-auth”), environment details, steps to reproduce (numbered, specific), expected behavior, actual behavior, severity assessment with justification (likely High or Critical), and any additional observations like whether this occurs at other character counts near 256. The candidate should note this may indicate a database truncation issue at a VARCHAR limit. Weak answers write a one-sentence summary without reproduction steps or severity.
Async Question 2
A developer tells you that a bug you filed last week has been fixed and is deployed to the staging environment. Write the email you would send to your team lead explaining what you tested, the results of your verification, and whether you are closing the bug or escalating it. Assume your verification found the original issue is fixed but revealed a new edge case.
Strong answer: Clear subject line, professional salutation, structured body covering what was tested (environment, build version, test steps), outcome of primary scenario (fixed), description of the new edge case found with enough detail for the developer to reproduce it, recommendation (close original ticket, open new ticket for edge case), and a clear next step. Weak answers either close the ticket without documenting the new edge case or bury the new finding in vague language.

Round 2: Test Design Methodology

This round is a live call. You are assessing whether the candidate can think through test coverage problems in real time, not whether they have memorized testing terminology. For this reason, present real scenarios rather than academic questions.

Question 3
I’m going to describe a feature and I want you to walk me through how you would design the test cases. We have a coupon code field on our checkout page. Coupons can be between 4 and 12 characters, alphanumeric only, and case-insensitive. A valid coupon gives 15% off. What test cases would you write?
Strong answer covers: Valid boundary cases (4-char and 12-char coupons), invalid boundary cases (3-char, 13-char), invalid character types (special characters, spaces, unicode), case variations (SAVE15 vs save15 vs Save15), empty field, whitespace-only, expired coupon, already-used coupon, coupon combined with another discount, behavior on the order total calculation. Strong candidates also ask clarifying questions: what happens if a coupon is valid but the cart is empty? Weak answers list only happy-path and obvious negative cases.
Question 4
What is the difference between equivalence partitioning and boundary value analysis, and when would you use one over the other?
Strong answer: Equivalence partitioning groups inputs into classes that should behave the same way (valid coupon codes, invalid codes, empty input) and you test one representative from each class. Boundary value analysis specifically tests at the edges of valid and invalid ranges (3, 4, 12, 13 characters for our coupon example) because defects cluster at boundaries. Use EP to design the overall test class structure; use BVA to generate specific values within numeric or character-length constraints. Strong candidates give an example from their work. Weak candidates define one correctly and conflate the two.
Question 5
When do you stop testing a feature and declare it ready for release?
Strong answer includes: Coverage of all acceptance criteria, all high-severity defects resolved, regression suite passing, performance within acceptable thresholds if specified, and explicit release readiness sign-off criteria from the team. Strong candidates mention that “done” is defined upfront with the product team, not ad hoc. They may also mention risk-based testing: some low-risk areas may not need 100% coverage if schedule is constrained. Weak answers say “when we’ve tested everything” without defining what “everything” means.
Question 6
Describe how you would approach exploratory testing for a feature you are seeing for the first time, with no documentation.
Strong answer: Start with a charter (what am I trying to learn?), use the feature normally first to understand intended behavior, then probe boundary conditions and error handling, use session-based test management to time-box and track findings, log observations even when they don’t produce bugs (they become test case candidates), and close by documenting what was tested, what was found, and what remains untested. Weak answers describe random clicking without structure.

Round 3: Automation Technical Screen

Run this round on a shared screen with a live coding environment. For Cypress, use the Cypress online playground or a shared CodeSandbox. For Playwright, use a shared VS Code Live Share session. You are not evaluating whether the candidate memorizes syntax. Instead, you are evaluating whether they can write working test logic, structure tests correctly, and debug when something does not work.

Two QA engineers reviewing printed test case documentation side by side at desk
Question 7 (Cypress live coding)
Write a Cypress test that visits our login page at /login, enters a valid username and password, clicks the login button, and asserts that the user is redirected to /dashboard and that an element with the data-testid “welcome-message” is visible.
Strong answer writes working code:
describe('Login flow', () => {
  it('redirects to dashboard on valid login', () => {
    cy.visit('/login');
    cy.get('[data-testid="username"]').type('testuser@example.com');
    cy.get('[data-testid="password"]').type('ValidPass123!');
    cy.get('[data-testid="login-btn"]').click();
    cy.url().should('include', '/dashboard');
    cy.get('[data-testid="welcome-message"]').should('be.visible');
  });
});
Strong candidates use data-testid selectors rather than brittle CSS class selectors, write a proper describe/it structure, and add a comment if they’d normally use cy.fixture() for credentials. Weak candidates use CSS class selectors, forget the URL assertion, or can’t complete the test without significant prompting.
Question 8 (Cypress: handling async)
Our search endpoint takes up to 3 seconds to return results. Your test clicks the search button and then asserts the result count. How do you handle the wait without using cy.wait(3000)?
Strong answer: Use cy.intercept() to alias the API request and then cy.wait(‘@alias’) to wait for the specific network response before asserting. This makes the test deterministic (waits for the actual response, not a fixed time) and provides better error messages on failure. Alternatively, use cy.get(‘[data-testid=”result-count”]’).should(‘not.be.empty’) and let Cypress retry until the element contains text. Weak answers use cy.wait(5000) or similar fixed delays.
Question 9 (API testing)
How would you structure a Postman collection to test our user management API endpoints: POST /users, GET /users/:id, PATCH /users/:id, and DELETE /users/:id?
Strong answer: Create a Postman collection with a folder per endpoint group, use environment variables for the base URL and auth token, set up a pre-request script on POST /users to capture the created user’s ID and store it as a collection variable, then use that variable in subsequent GET, PATCH, and DELETE requests so the tests chain correctly. Include test scripts on each request asserting status codes (201 for POST, 200 for GET/PATCH, 204 for DELETE) and response body structure. Use Postman’s collection runner for sequential execution. Weak answers describe clicking through Postman without mentioning variables or test scripts.
Question 10 (Code review)
I’m going to share a Cypress test file with you. Tell me what problems you see and how you would fix them.
Prepare a file with 3 to 5 common issues: fixed cy.wait() calls, brittle CSS class selectors, missing assertions, test data hardcoded in the test body rather than in fixtures or variables, missing describe block structure. Strong candidates identify all issues, explain why each is a problem (not just that it’s “wrong”), and propose specific fixes. They may also note good patterns that should be preserved. Weak candidates identify only the most obvious issue or identify problems without being able to articulate why they matter.
Two developers reviewing printed code documentation together in professional office

Skip to Pre-Screened Profiles

Kore BPO runs a technical and English screen before you see any QA engineer profile. Start with qualified candidates.

Get Profiles
Question 11 (Performance testing)
We want to load test our checkout API to confirm it handles 500 concurrent users. Which tool would you use and what would your test script measure?
Strong answer for k6: Define virtual users (VUs), ramp-up strategy (e.g., 0 to 500 VUs over 2 minutes), hold duration, and ramp-down. Key metrics to measure: response time percentiles (p50, p90, p99), error rate (should be below 0.1% under target load), throughput (requests per second), and time-to-first-byte. Set thresholds that cause the test to fail if p99 exceeds 3 seconds or error rate exceeds 0.5%. Strong candidates also mention that they would run the test against a staging environment that mirrors production infrastructure, not a shared development environment.

Round 4: Team Fit Call

This round includes the engineering lead or the person who will work most closely with the QA engineer. You are not re-testing technical skills. Rather, you are assessing communication style, workflow assumptions, and red flags that technical screens do not surface.

Question 12
Walk me through your typical involvement in a sprint. What do you do during planning, during the sprint, and during the retrospective?
Strong answer: During planning, they review user stories for testability, flag acceptance criteria that are too vague to write tests against, and estimate testing effort for the sprint. During the sprint, they write test cases as stories enter development, run tests when stories are marked dev-complete, file and triage bugs, and update the test status in the project management tool. During retrospectives, they analyze quality trends (what types of bugs slipped through, at what stage), propose process changes, and follow up on action items from previous retrospectives. Weak answers describe QA as a post-development activity with no involvement in planning.
Question 13
A developer pushes back on a bug you filed, saying it’s “by design” and the behavior you reported is intentional. What do you do?
Strong answer: First, check the original acceptance criteria or product requirements to see whether the behavior is actually specified. If the requirements are ambiguous, escalate to the product manager for clarification rather than arguing with the developer. Update the bug report with the requirements reference and mark it as a discussion item for the PM to resolve. Never silently close a bug under developer pressure if it appears to violate acceptance criteria. Strong candidates describe this as a process issue (unclear requirements) rather than a personality conflict. Weak answers either cave to developer pressure or escalate immediately to management.
Question 14
How do you stay current on testing tools and techniques? What have you learned or changed about your testing approach in the last 12 months?
Strong answer: References specific resources (Ministry of Testing, the Cypress changelog, specific blog authors, testing conferences), describes something concrete they changed (e.g., adopted component-level testing alongside E2E to reduce test run time, migrated from Selenium to Playwright for better parallel execution), and can explain why the change made their work more effective. Weak answers are vague (“I read blogs and keep up with the industry”) without specifics.
Question 15
We release to production every two weeks. The day before release, a critical bug is found at 4pm your time. The fix is delivered at 7pm. Walk me through what you do between 7pm and 9pm to verify the fix and make the release decision.
Strong answer: Deploy fix to staging, re-run the specific test case that exposed the original bug, run the full regression suite for the affected module (not just the original path), check the adjacent features that touch the same code area, document the verification results in the bug ticket, and give a clear binary recommendation to the release owner (release / do not release). If the fix introduces a new issue, that becomes a separate ticket and the release decision is escalated. Weak answers describe “testing the fix” without specifying scope, environment, or decision criteria.

Questions to Skip

These questions are commonly used in QA interviews and generate consistently low-signal responses. Removing them from your process reduces interview length without reducing decision quality.

Skip: “Tell me about yourself.” You already have the resume and cover letter. Use interview time instead for questions that reveal information you could not get from those materials.

Skip: “What is your greatest weakness?” This produces rehearsed answers that no candidate has ever answered honestly in an interview. Replace it with a scenario question about a specific time a bug shipped to production and what the candidate did as a result.

Skip: “Where do you see yourself in five years?” This is not relevant to whether a QA engineer can write a Cypress test and participate in your sprint effectively.

Skip: “Why do you want to work for us?” For nearshore roles where the agency handles sourcing, candidates often have limited prior exposure to your company. Asking this question penalizes candidates for lack of marketing research and, conversely, rewards candidates who are simply better at performing enthusiasm.

Skip: “What is a test plan?” Definitional questions filter for vocabulary, not skill. Replace with: “Give me an example of a test plan you wrote recently. What did you include and why?”


Scoring and Decision Framework

A simple scorecard prevents the bias that occurs when interviewers compare narrative impressions across candidates rather than structured scores. Use a four-dimension scorecard:

  • Test design depth (1 to 5): Does the candidate apply equivalence partitioning, boundary value analysis, and exploratory testing correctly to real scenarios, not just in definitions?
  • Automation skill (1 to 5): Can the candidate write working, maintainable test code in your framework without significant scaffolding? Do they use proper locators, avoid fixed waits, and structure tests correctly?
  • English communication (1 to 5): Are bug reports, emails, and live speech clear enough for a US developer or PM to act on without clarification?
  • Sprint integration readiness (1 to 5): Does the candidate’s description of their workflow match how your team operates? Do they take initiative on ambiguous scenarios, or do they wait for explicit direction?

Score each dimension independently. The minimum bar for an offer is no dimension below 3 and an aggregate score of 14 or above. A candidate with a 5 in automation and a 2 in English is not ready for a live-collaboration nearshore role regardless of technical skill. Similarly, a candidate with a 4 in English and a 2 in automation is not ready for an automation-focused role regardless of communication skill.


Frequently Asked Questions

How many rounds should a QA engineer interview have for nearshore hiring?

Three to four rounds is appropriate. Round 1 is an async written screen (no live time required). Round 2 is a 45-minute test design discussion. Round 3 is a 60-minute live automation coding screen. Round 4 is a 30-minute team fit call. When working with a nearshore staffing agency that pre-screens candidates, you can often compress Round 1 and 2 into a single 60-minute session, reducing total time to 90 minutes of live interviews per candidate.

Should I give QA engineer candidates a take-home coding test?

Take-home tests have a verification problem: you cannot confirm who completed the work. For QA engineers, a live coding session of 45 to 60 minutes is more reliable because you can observe how the candidate approaches problems, asks clarifying questions, and debugs when their first attempt fails. If you use a take-home test, require a 30-minute follow-up call where the candidate walks through their code and answers specific questions about their implementation choices.

What should I look for in a QA engineer’s bug reports during the async screen?

A strong bug report has five elements: a descriptive title that summarizes the defect (not “login doesn’t work”), numbered steps to reproduce that a developer can follow without guessing, a clear expected vs. actual behavior statement, an environment specification (browser, OS, build version), and a severity assessment with brief justification. The writing should be in professional English without excessive jargon but with enough technical precision that a developer understands the scope without asking follow-up questions.

How do I assess whether a QA engineer can work in an Agile/Scrum environment?

Ask them to describe their involvement in the last three sprint ceremonies in their current or most recent role. Strong Agile QA engineers participate in sprint planning (flagging untestable acceptance criteria), write test cases during the sprint as stories are in development (not after), and contribute to retrospectives with quality trend data. A QA engineer who describes their role as “we test when development is done” is describing a waterfall-adjacent process even if they call it Agile.

Is a live coding test necessary for manual QA engineer roles?

For roles that are primarily manual, replace the live coding test with a live test case design exercise: give the candidate a feature specification and 20 minutes to write a complete test suite on a shared document while you observe. This surfaces the same signal (can they apply methodology in real time without preparation?) in a format appropriate for the role. The async bug report exercise from Round 1 still applies to all QA roles regardless of automation ratio.

Disclosure: Kore BPO is a nearshore and offshore staffing agency. This article reflects our direct experience placing QA engineers from Costa Rica with US engineering teams.

Brian Hunt CEO, Kore BPO
Brian Hunt
CEO & Co-Founder · Kore BPO

Brian Hunt is the CEO of Kore BPO, a US-owned offshore hiring and BPO partner based in Dallas, TX. He has spent his career in consulting, international M&A, and building global offshore teams for growing US companies. Kore BPO has placed over 6,200 hires for 257 clients across accounting, marketing, tech, operations, and more.

Find Your Nearshore QA Engineer

Kore BPO sources, screens, and places nearshore QA engineers from Costa Rica. Profiles in 2 to 5 business days, $0 upfront fees.

Get QA Engineer Profiles
Same time zone  ·  Automation pre-screened  ·  Dallas, TX