QA engineer interview questions for startups: 20 questions

qa-engineer-interview-questions-for-startups:-20-questions

Updated October 2026

A startup QA engineer interview needs four stages: a screen, a test strategy session on your own product, a pairing session on a flaky test, and a final round with a founder. Between them they test whether the candidate will make developers ship faster or add a queue at the end of each sprint.

Spend more time on what a candidate would choose not to test than on what they would test. Anyone can list test cases. The QA engineers who speed a team up can explain which risks they would accept, and why, before you ask.

Our illustrative example runs through the questions: a Seed-stage consumer app with six developers, a fortnightly release, and two founders who test by hand the night before each one.

The QA engineer interview plan

StageWhoLengthWhat it tests
1. ScreenHiring manager30 minWhich kind of QA they are, release cadences they know
2. Test strategySenior developer60 minWhat they would test, automate and skip in your app
3. Flaky test pairingA developer90 minDebugging, test code quality, working with developers
4. Final roundFounder and product lead45 minRelease judgement, how they say "not ready"

Which QA engineer is in front of you

  1. In your last team, how was your week split between automation, testing by hand and helping developers test?
  2. Who wrote the tests in your last team, and did you want that to change?
  3. Tell me about a release you held back. What did you see, and who agreed?
  4. Tell me about a release you let go out with known bugs. Why?
  5. What is a bug you found that no script would have caught?

Strong answer: Concrete examples on both sides of the release decision, and a clear sense of whether they prefer building automation or exploratory testing.

Red flags: Every story ends with them blocking a release, or they cannot recall a bug they found outside a script.

Test strategy and risk

  1. Here is our app. What would you automate first, and what would you never automate?
  2. How do you choose between a unit, integration or end-to-end test for a given bug?
  3. The spec for this feature is a Slack thread. How do you test it?
  4. How would you take our founders out of the night-before testing?
  5. How do you know your suite covers the right things, without quoting a coverage number?
  6. What do you need from developers at the start of a feature rather than the end?

Strong answer: Starts from risk and how often each area changes, pushes tests down to the cheapest level, and asks to join planning.

Red flags: Wants end-to-end tests for everything, or treats coverage as the goal.

A rule of thumb for what to automate first
High risk, stable
Automate first. In our example app: sign-up and payments.
High risk, changing often
Automate the core path, explore the rest by hand.
Low risk, stable
One smoke test, then leave it.
Low risk, changing often
Exploratory testing only. Automating it now is wasted work.
A strong candidate draws something like this unprompted.

Question 4 is the one to grade hardest, because it is the job you are hiring for.

Illustrative answer to question 4 in this section, scored on release confidence

"I'd write end-to-end tests for sign-up and checkout first and run them on every merge. Then I'd pair with each developer on unit tests for their own features, so the founders only test what changed."

1
2
3
4

Why 3, not 4: a sound plan with no date for the last manual night, and no word on what happens when a check fails at midnight before release.

Flaky tests and automation

  1. Tell me about the flakiest test you fixed. What was the real cause?
  2. A test fails now and then on CI. What do you do today, and what do you do this week?
  3. When is it right to delete a test rather than fix it?
  4. How do you keep end-to-end tests fast enough that developers don't skip them?
  5. Show me a test you are proud of and one you would rewrite.

Strong answer: Named causes such as timing, shared test data or test order, and a quarantine rule with an owner and a deadline.

Red flags: Adding retries or longer waits as the fix, or never deleting a test.

Working with developers

  1. How have you got a developer who didn't write tests to start?
  2. A developer says your test is wrong and the feature is fine. What happens next?
  3. The founder wants to ship today and you are not confident. What do you say?
  4. From what you've seen today, what would you change in your first month?

Strong answer: Coaching rather than policing, and a clear statement of risk that leaves the founder to decide.

Red flags: "QA signs off" language, or treating developers as the people who make the bugs.

Work sample: pair on a flaky test

Give the candidate a small web app with five end-to-end tests, two of them flaky: one from a timing problem, one from shared test data. Pair for 90 minutes with a developer, with a short written note afterwards. Keep the whole exercise under 3 hours.

First 20 min
Reproduce
Can they make the flaky test fail on demand?
Next 40 min
Find the cause
Timing, shared data or the app itself?
Last 30 min
Fix or quarantine
And explain the choice to the developer

Listen to how they talk to the developer. Your QA hire will spend most days persuading people, and the pairing shows that better than any question.

Scoring rubric

Outcome1234
Release confidenceRelies on gut feelUses a checklistClear criteria for "ready"Releases without a manual freeze
Regression automationManual onlyAutomates when toldAutomates by riskRemoves manual passes for good
Flaky testsReruns until greenQuarantines, never fixesFinds root causesBuilds a suite people trust
Developer testing habitsTests after developersReviews their testsPairs on testsDevelopers test unprompted
Escaped bugsNot trackedCountedTracked by causeCauses shrink release on release

Where Funded.club fits

We run engineering searches on a fixed fee agreed upfront from $4,900 to $21,900 per hire (see pricing). One dedicated recruiter screens candidates against your scorecard, with first screened candidates within 7 days. More on how we hire.

Frequently asked questions

How technical should a startup QA engineer be?

Technical enough to write and review test code in your main language. Set the level in your QA engineer job description before you interview.

Should QA candidates do a take-home test?

A paired session beats a take-home for QA, because it shows how they work with developers. Keep any exercise under 3 hours.

How quickly should I hire a QA engineer?

Aim to finish the four stages within two weeks. If QA is part of a wider engineering push, see how to hire 5 engineers in 60 days.

Worth a brief chat about your next hire? Book a free call.

Hiring after a funding round?

First candidates in 7 days. Fixed-fee, no commission.

See pricing Book a free call Try the Growth Planner