What Junior Software Testers Get Wrong About Talking to Interviewers

Interview Insights · Software Tester

What Junior Software Testers Get Wrong About Talking to Interviewers

SECTION 01The five talking habits that hide a junior tester's real skill

When I interview a fresher or junior tester, I am not expecting deep automation frameworks. I am trying to answer one question: if I give this person a build tomorrow, will they find real problems and explain them clearly to a developer? Most candidates can do the first part. Many fail to show the second part, because the way they talk hides it.

The habits below are not about grammar or accent. Simple English is perfectly fine. They are about structure and specificity. Each one makes me work harder to find your skill, and in a busy interview day, I may simply not find it.

Interviewer: Tell me about a bug you found.

Candidate: In my project I found many bugs.
Like UI bugs, functional bugs.
I reported them in Jira and the developer fixed them.
We did regression testing also.

Interviewer: Tell me about a bug you found.

Candidate: On the checkout page of our e-commerce project,
if I applied a coupon and then changed the quantity,
the discount stayed at the old amount.

Expected: discount recalculates with quantity.
Actual: total was wrong, customer pays less.

I logged it as high severity because it affects money,
attached a screen recording and the API response,
and retested on the next build. It was fixed.

The clear answer is not longer because it adds filler. It is longer because every sentence carries evidence: the feature, the steps, the expected result, the actual result, the severity reasoning and the retest. That is exactly what a developer needs from a bug report, so it also proves you can write one.

SECTION 02Using testing vocabulary without sounding like a textbook

Junior testers often believe that more technical terms will impress me. So they say 'boundary value analysis', 'equivalence partitioning', 'smoke', 'sanity' and 'STLC' in one breath. The result is the opposite of what they want. When terms come without examples, I start testing whether you really understand them, and that turns the interview into a quiz.

Vocabulary is useful when it saves time. 'I did a smoke test on the new build' is a good sentence because it is short and tells me exactly what you did. The trick is to attach every term to a real action from your work.

Field: Age (valid range 18 to 60, whole numbers)

TC01  17   -> error 'Age must be 18 or above'
TC02  18   -> accepted
TC03  19   -> accepted
TC04  59   -> accepted
TC05  60   -> accepted
TC06  61   -> error 'Age must be 60 or below'

Extra negative checks:
TC07  blank   -> required field error
TC08  'abc'   -> numeric only error
TC09  18.5    -> whole number error

"For the age field the rule was 18 to 60.
I used boundary value analysis, so I tested
17, 18, 19 and 59, 60, 61.

I also added blank, letters and a decimal,
because the spec did not say what happens with those.
The decimal case actually got accepted,
so I raised it with the BA before logging a bug."

Notice the last line of the spoken version. Saying that you checked with the business analyst before logging a bug shows judgement. It tells me you know that an unclear requirement is a question first, not automatically a defect.

SECTION 03A simple answer shape for every tester question

Junior testers ramble when they do not know where the answer ends. A fixed shape solves that. For experience questions, I suggest a tester-flavoured version of STAR: Context (which feature, which build), Check (what you tested and how), Catch (what you found), Close (what happened next and what you learnt).

For concept questions, use Define, Example, Limit: one line of definition, one example from your work, and one line on when the concept is not enough. That last part is what separates a thinking tester from someone repeating notes.

Q: What is the difference between smoke and sanity testing?

Define:  Smoke checks that a new build is stable enough
         to test at all. Sanity checks one specific fix
         or change works before deeper testing.

Example: New build arrives -> smoke on login, search, cart.
         Coupon bug fixed -> sanity on coupon flow only.

Limit:   Neither replaces regression. A passing sanity
         check does not prove nearby features still work.

Q: How would you test a password reset feature?

Clarify: Is reset by email link or OTP? Link expiry time?

Areas:   - valid email, unregistered email, blank email
         - link works once, expires, cannot be reused
         - new password rules and confirm-password match
         - old password stops working after reset
         - rate limit on repeated reset requests

Priority: security cases first (reuse, expiry, old password),
          then validation, then UI and messages.

The scenario answer starts with a clarifying question. Junior testers often skip this because they think it looks like they do not know. In reality, asking about the reset method and expiry is exactly what a careful tester does before writing test cases.

SECTION 04Rewrite worksheet for your own tester answers

Take three answers you usually give and run them through this worksheet. Write the weak version first, honestly, then rebuild it. Doing this on paper once makes the better version come out naturally in a real interview.

MY BEST BUG STORY

Feature / module: ______________________
Build or sprint:  ______________________
Steps I followed:
  1. ____________
  2. ____________
  3. ____________
Expected result: _______________________
Actual result:   _______________________
Severity I chose and why: ______________
Evidence I attached: screenshot / video / logs / API response
What happened after: fixed / deferred / rejected
What I learnt: _________________________

LIST EVERY TESTING TERM YOU USE IN ANSWERS

Term                | My real example        | Keep?
--------------------|------------------------|------
Regression          | ____________________   | Y / N
Boundary values     | ____________________   | Y / N
Smoke / sanity      | ____________________   | Y / N
Test plan           | ____________________   | Y / N
RTM                 | ____________________   | Y / N

Rule: no example, no term.
Remove any term you cannot back with your own work.

AFTER EACH MOCK INTERVIEW, TICK HONESTLY

[ ] I named a specific feature, not 'the project'
[ ] I said 'I' for my own work at least once per story
[ ] I gave expected vs actual for every bug I mentioned
[ ] I explained severity with a reason
[ ] I asked at least one clarifying question in scenarios
[ ] I ended stories with an outcome, not 'I reported it'
[ ] No definition was given without an example

Score: ___ / 7   Fix one item before the next mock.

SECTION 05Small talking habits that make junior testers sound ready

These habits take a week or two to build and change how every answer lands.

• Lead with the feature name — Start bug stories with 'On the checkout page' or 'In the login API' so I can picture the screen before you explain the problem.
• Always say expected and actual — These two phrases instantly show that you think like a tester and know how a defect is proven.
• Own your part clearly — Use 'I' for what you personally did, then mention the team. Interviewers hire individuals, not projects.
• Disagree without blame — When asked about developer conflicts, talk about evidence and reproduction steps, never about the developer being wrong.
• Stop when the answer is done — After your outcome line, stop and let me ask the next question. Silence after a complete answer is confident, not awkward.

SECTION 06Interview Q&A — Junior tester talk

SECTION 07Test yourself — Junior tester talk quiz

SECTION 08Frequently asked questions

SECTION 09Related reads