Test Engineer interview questions and how to answer them
A test engineer interview is really checking one thing: will you find the bug that matters, and can you get people to act on it. Expect a mix of test design puzzles, coding, and stories about times you pushed back. Here's what each round is looking for and how to answer the questions that come up again and again.
What happens in each round
- 1
Recruiter screen
What happens
Whether your tools match the posting. Say the frameworks and languages you've really used, by name, and be ready to say if the role is software or hardware testing.
- 2
Hiring manager call
What happens
How you think about quality on a team. They want to hear where testing fits in your last team's process and how you handled a release you didn't think was ready.
- 3
Technical or coding round
What happens
Whether you can write a clean, readable test and a small bit of automation live. Expect a Selenium or Playwright exercise, an API test, or a plain coding problem in Python or Java.
- 4
Test design exercise
What happens
How you break down a feature into test cases. You'll get something like a login page, a search box or an elevator and be asked how you'd test it. They're watching your structure, not your speed.
- 5
Team or behavioral round
What happens
How you work with developers and product managers when you're the one bringing bad news. Friendly, specific stories beat polished ones.
Questions you're likely to get
1.How would you test a login page?
Why they ask
It's the classic test design warm-up. They want to see whether you go wider than typing a good password and a bad one.
How to answer
- Ask a clarifying question first: who uses it, is there single sign-on, is there a lockout rule
- Group cases into functional, security, usability and performance instead of listing them randomly
- Name specific cases: empty fields, very long input, SQL injection strings, password managers, session timeout
- Say which cases you'd automate and which you'd leave as a quick manual check
2.Tell me about a flaky test you fixed.
Why they ask
Every automated suite has flaky tests, and a test engineer who can't diagnose them ends up with a suite nobody trusts.
How to answer
- Describe the symptom: passes locally, fails in the pipeline, or fails only in parallel runs
- Explain how you found the cause, such as a race condition, shared test data or a hard-coded sleep
- Say what you changed: explicit waits, isolated data, a retry only where it made sense
- Mention what you did so the same kind of flake didn't come back
3.How do you decide what to automate and what to test by hand?
Why they ask
Automating everything is expensive and slow. They want someone who spends automation effort where it pays back.
How to answer
- Automate stable, repeated, high-risk paths like checkout, sign-up and core APIs
- Keep exploratory testing and brand new, still-changing screens manual at first
- Push checks down to the API or unit level when the UI isn't the thing being tested
- Give an example of a test you chose not to automate and why
4.Walk me through how your last team's tests ran in the pipeline.
Why they ask
They want proof you've worked with CI, not just written tests that live on your laptop.
How to answer
- Name the tool, such as Jenkins, GitHub Actions or GitLab CI, and what triggered a run
- Explain which tests ran on every pull request and which ran nightly
- Describe how failures were reported and who was expected to act on them
- Say one thing you'd change about that setup
5.A developer says your bug isn't a bug. What do you do?
Why they ask
Test engineers who win arguments but lose the room don't last. They want to see how you handle disagreement.
How to answer
- Go back to the requirement or acceptance criteria, not your opinion
- Show the evidence: steps to reproduce, logs, a screen recording
- Frame it by customer impact so the product manager can make the call
- Accept the decision if it goes against you, and note it in the ticket
6.How would you test a REST API endpoint that creates an order?
Why they ask
A lot of real test work happens below the UI. They're checking that you know how to test an API directly.
How to answer
- Cover status codes for success, bad input, missing auth and duplicate requests
- Check the response body against the schema and the database record it creates
- Test boundary values on quantities and prices, and missing or extra fields
- Name your tool, such as Postman, Karate or pytest with the requests library
7.What goes into a good bug report?
Why they ask
A vague bug report wastes a developer's afternoon. This is a quick check of your habits.
How to answer
- A short title that says what broke and where
- Exact steps, expected result and actual result
- Environment, build, browser or device, plus logs or screenshots
- Severity based on user impact, kept separate from priority
8.Tell me about a time you stopped or delayed a release.
Why they ask
They want to know you'll speak up late in a sprint, and that you do it with judgment, not panic.
How to answer
- Describe the bug and why it mattered to customers
- Explain who you told, how you showed the risk, and what options you gave
- Share the decision and whether it held up after release
- Say what the team changed so it got caught earlier next time
9.How do you design test data so tests don't interfere with each other?
Why they ask
Shared data is a common cause of broken suites. This separates people who've scaled a suite from people who haven't.
How to answer
- Create data per test through an API or factory instead of reusing fixed accounts
- Clean up after each test or use throwaway environments
- Keep secrets and real customer data out of test fixtures
- Mention how this made parallel runs possible
10.How would you start performance testing a new feature?
Why they ask
Not every test engineer owns load testing, but they want to see that you know where to begin.
How to answer
- Ask what normal and peak traffic look like and what response time is acceptable
- Pick a tool like JMeter, Gatling or Locust and script the realistic user flow
- Run against an environment close to production and watch server metrics too
- Report where it slowed down, not just whether it passed
11.Why do you want to be a test engineer rather than a developer?
Why they ask
They're checking that testing is a choice, not a stepping stone you'll abandon in a few months.
How to answer
- Say what you like about the work: finding edge cases, thinking like a user, protecting a release
- Give a moment when finding a bug felt better than writing a feature
- Show you still write real code as part of the job
Mistakes that sink good candidates
Calling manual testing beneath you
Most teams still do exploratory testing and want someone who respects it.
Talking only about tools
Naming frameworks without explaining how you chose what to test sounds like a list, not experience.
Blaming developers in your stories
The interviewer may be one, and they're picturing working with you.
Claiming you've never missed a bug
Everyone has. Tell them about one and what you changed.
Need more Test Engineer interviews to prep for?
HeroApply applies to Test Engineer jobs that match you, every day. 3,167 jobs are open today.