Why Software Testers Who Ask Questions Back Impress Me Most

Interview Insights · Software Tester

Why Software Testers Who Ask Questions Back Impress Me Most

SECTION 01Why asking back is the tester job in miniature

In real projects, many serious defects are not coding mistakes. They are requirement gaps: nobody decided what happens when a refund is requested after partial delivery, or when a user changes their mobile number during OTP verification. Good testers catch these during requirement review, before a single line is tested. This is called static testing, and it is often the cheapest place to find a defect.

So when I give a vague prompt such as 'test the refund flow', I am partly checking whether the candidate notices it is vague. A candidate who asks 'is it full refund only, or partial too?' is showing me the exact skill that saves a team days of rework later.

Interviewer: Test the refund flow.

Candidate:
I will place an order, click refund, and check the
amount comes back. I will check the refund status
changes to 'Refunded'. I will also test with an
invalid order ID.

(Reasonable, but tests only the simplest version of
the feature. The biggest risks were never found.)

Interviewer: Test the refund flow.

Candidate: Before I start, is partial refund allowed,
for example one item out of three?

Interviewer: Yes.

Candidate: Then my riskiest cases are around amounts:
- refund item 2 of 3, check the amount includes its
  share of tax and excludes shipping, if that is the rule
- refund all items one by one, total must not exceed
  the amount paid
- refund the same item twice, second must be blocked
- refund after a coupon was applied on the whole cart

The question took five seconds. It changed the whole answer from checking a button to checking money calculations, which is where real refund bugs usually live.

SECTION 02Questions back that impress versus questions that stall

Not every question back helps. Some candidates ask so many questions that it becomes a way to avoid answering. Others ask about things that do not change the test, such as 'which language is the backend in?' for a UI form question. The interviewer can tell the difference quickly.

A useful test for yourself: before you ask, check whether the answer would change what you test. If yes, ask. If no, make an assumption and move on. Usually one or two questions are enough. After that, start testing and ask new questions only when you hit a real fork.

Interviewer: Test the CSV export on the reports page.

Candidate:
- Which browser should I use?
- Is it a web app or desktop?
- Which database is used?
- Who are the users?
- Is there any documentation?
- Can I see the screen?

Interviewer (thinking): Six questions, zero tests.
Is this candidate avoiding the question?

Interviewer: Test the CSV export on the reports page.

Candidate: Two quick questions. Is there a maximum
number of rows, and does the export respect the filters
on screen?

Interviewer: Up to 50,000 rows, and yes, filters apply.

Candidate: Then I would test:
- export with a filter, row count matches the screen
- export of exactly 50,000 rows and of 50,001
- names with commas and quotes, columns must not shift
- Hindi or special characters, open in Excel correctly
- date columns stay in the same format as on screen

The comma and quote case is worth remembering. A customer name such as Sharma, Ravi can break a CSV file if the export does not quote fields properly, and it is a very real export defect.

SECTION 03The questions I want testers to ask at the end of the interview

When I say 'do you have any questions for me?', many tester candidates say 'no, everything is clear' or ask only about salary and work hours. Those are fair topics, but they miss a chance. The end of the interview is where a candidate can show that they already think like a member of the QA team.

Good end-of-interview questions are about how testing works on the team: who writes acceptance criteria, how bugs are triaged, what is automated, how releases are signed off. These tell me the candidate cares about doing the job well, and the answers genuinely help the candidate decide whether the role fits them.

Interviewer: Any questions for me?

Candidate: No sir, everything is clear.

or

Candidate: What is the salary and when will I
know the result?

(Fair questions, but nothing that shows interest
in the testing work itself.)

Interviewer: Any questions for me?

Candidate:
Yes, two. First, do testers review user stories before
development starts, or does testing begin after the
build?

Second, how is the regression suite split today
between manual and automated tests? I have done some
Selenium practice and would like to know where I could
contribute.

(Short, relevant, and connects the role to the
candidate's own skills.)

Two good questions are enough. Five or six can feel like you are interviewing the interviewer. Pick the ones whose answers you genuinely want.

SECTION 04Question-back practice bank for tester interviews

Use these sheets to train the habit. For each prompt, write the one question that would most change your tests, then answer it with an assumption and list the tests it unlocks.

WRITE ONE QUESTION BACK FOR EACH

1. Test the 'change mobile number' feature
2. Test the leave application form on an HR portal
3. Test a 'buy now, pay later' option at checkout
4. Test a password reset email
5. Test a seat selection screen for a bus booking
6. Test an 'invite a friend' referral reward
7. Test the dark mode toggle in an app
8. Test a monthly sales report for managers

Rule: your question must change at least
two of the tests you would run.

PROMPT: Test the referral reward

Question back:
  When is the reward given: on sign-up, or after the
  friend's first purchase?

Assumption: after first purchase above Rs 500.

Tests unlocked:
  - friend signs up, no purchase   -> no reward
  - purchase of Rs 499             -> no reward
  - purchase of Rs 500             -> reward credited once
  - friend cancels the order       -> reward reversed?
  - same person refers own 2nd ID  -> blocked?
  - two referrers claim one friend -> only first wins

PICK 2 FOR EACH INTERVIEW

About requirements
  - Do testers review stories before development?

About bugs
  - How do you decide severity and priority here?

About automation
  - What is automated today, and what is next?

About the role
  - What does a good first quarter look like?

About quality culture
  - What happens when a bug reaches production?

Avoid: questions already answered in the interview.

SECTION 05How to ask questions back without losing momentum

These habits keep your questions sharp and your answers moving.

• Ask one, then act — Ask your most important question, take the answer, and start testing straight away. Momentum shows confidence.
• Explain why you ask — Adding 'because it changes the amount calculation' turns a plain question into evidence of your thinking.
• Assume the rest out loud — For minor gaps, say 'I will assume the limit is 5 MB'. It shows control and saves time.
• Restate instead of asking to repeat — Instead of 'can you repeat?', say 'so you want me to test X, right?'. It checks understanding without sounding lost.
• Prepare two end questions — Walk in with two questions about QA process ready, and drop any already answered during the interview.

SECTION 06Interview Q&A — Testers asking questions

SECTION 07Test yourself — Testers asking questions quiz

SECTION 08Frequently asked questions

SECTION 09Related reads