If you had to pick your top 10 interview questions to test someone’s knowledge and skills in testing (manual, automation, or even DevOps if you prefer)…
What would they be?
Not just technical questions, but also ones that uncover:
Testing mindset (how they think about risk, coverage, and exploration)
If I had to narrow it down to just 10, I’d focus less on “trivia” and more on questions that show how someone thinks, explores, and balances trade-offs. My list would look something like this:
How do you decide what not to test when you’re close to a deadline?
(Reveals prioritization and risk-based thinking).
Tell me about a bug you missed that slipped into production. What did you learn from it?
(Shows humility, ownership, and learning mindset).
If requirements are unclear, how do you still move testing forward?
(Exploration, stakeholder collaboration, and adaptability).
How would you explain the value of testing to a product manager who thinks testing slows delivery?
(Communication and advocacy skills).
What’s your approach to designing automation that lasts beyond the next release?
(Framework thinking and maintainability).
If your automation suite suddenly takes 6 hours to run, how do you tackle that problem?
(Debugging skills, optimization, CI/CD awareness).
How do you test something that’s not visible — like an API response, background job, or data pipeline?
(Technical depth, beyond just UI).
Imagine production monitoring shows a sudden spike in errors at 2 a.m. How would you investigate?
(DevOps awareness, logs, monitoring tools, and calm under pressure).
What’s the most creative test idea you’ve used to uncover a tricky bug?
(Exploratory mindset and curiosity).
If I give you a brand-new feature today, how do you start testing it from scratch?
(End-to-end thought process, from reading requirements to exploratory and regression coverage).
For me, these questions separate someone who just “executes” test cases from someone who thinks like a tester. The answers don’t have to be perfect; I care more about the reasoning, the trade-offs they make, and whether they can balance speed with quality.
Really difficult to answer, but I think the above quote nails the questioning approach. It isn’t for me about finding a great tester, just the right tester - one that fits the team and of course ensuring the team fits the tester. I’ve turned down great testers because it affected the balance of the team, and I’ve told them “we’re not right for you”. I’ve seen their careers take off as a result when they found a role that did fit them. But obviously, I’ve seen the entire team grow when we’ve hired the right person.
So…questions. My caveat is they’ll change depending on the candidate and their answers. But hopefully this will give you an idea of my thinking. Here goes:
Whats you’re biggest success working in quality and testing?
What mistake in testing taught you the most?
What is your ideal working environment?
What examples can you giove of having a positive influence on those outside of QA/QE?
What are you favourite tasks in testing?
What tasks in testing do you think are an unnecessary burden?
How do you see test automation fitting in the quality process to bit its most effective?
What scenarios do you consider to be ideal for using AI?
What do you see the difference in quality risks are from a Product that acquires data through user input to a product that acquires data through automatic data feeds?
How would define a great quality product?
As you can see my questions are less about testing techniques and acronyms. I want to find out about the person, I want to be excited about the prospect of them working in my team. I’m not steering them on non-functional testing, I want to see if that insight comes out naturally. I want to see behaviours and mindset that loves testing, loves people and building relationships and wants to be better than they are today. I want to trust the person, not the list of skills.
Questions depend upon the role and position we want to hire a candidate where the job role should match the candidate’s capability. But here are the generic ones I prefer to ask and based on the answers given, we can get to know the candidate:
Can you introduce yourself, walk through your professional career ( Aim is to let the candidate feel comfortable as he speaks and I can match candidate’s words with the CV shared)?
What do you understand by the term Software Quality( Aim is to know how a candidate thinks about quality)?
What process is followed in your project and when do you get involved in the process? What are your roles and responsibilities
Significance of automation - To what extent it is important to automate the features?What are the test cases which cannot be automated?
Can you describe your automation framework?
Any experience with the CI/CD integration? Which tool have you used?( Let the candidate speak themselves about their experience and exposure and then follow up questions may be put)
What are the Key Contents in a bug report ?
Have you ever had a conflict with your colleague/manager ?
What action do you take when a bug is found in production for a feature tested by you?
Are you using any of the AI tools for your testing?
It’s worth asking the question, can my interview question be googled and likely satisfy the bias I have in my desired for answer? Are you risking fooling yourself?
Focus where you can on real experience, what they did, why they did it, what did they learn, what they would do differently in the future.
The semi open ended discussion that Gord mentioned is also key for me, I am interviewing them as much as they are interviewing me and my company. To ignore that and you may find a great match for your team only for it a few months later not to be a match for them. Use this to dig deeper into their actual experience.
Interviews can be reflective of the companies testing model, are you sticking close to an interview script or are using running an interview exploratory session with goals and desired information outcomes in order to make a good hiring decision.
More likely topic areas rather than questions but I adapt based on what is needed at the time.