Why Good Software Tester Candidates Still Get Rejected

JOB DESCRIPTION (example)

Software Tester, 0-2 years
- Perform functional and regression testing of web apps
- Validate REST APIs using Postman
- Write SQL queries to verify data in backend tables
- Log and track defects in Jira
- Participate in sprint ceremonies

MY READING:
  Core:      functional + regression (I am strong)
  Must-show: Postman and SQL (I am weak on SQL joins)
  Process:   Jira and sprints (I can explain from training)

ACTION BEFORE INTERVIEW:
  Practise 10 SQL queries with JOIN and GROUP BY.
  Prepare one Postman collection to show on screen.

Use the JD language in your introduction:

"I have done functional and regression testing on two
web projects, logging defects in Jira. I have also
validated REST APIs in Postman with status and body
assertions, and I write SQL queries with joins to check
that order and payment data match in the backend."

Every clause maps to one JD line.
The interviewer does not have to guess the fit.

Bug 1: Form not submitting

Description: When I fill the form it does not submit.
Please fix.

Severity: High

(The developer now has to ask: which form, which
fields, which values, which browser, what did you
see? Each missing answer costs a round of messages.)

BUG-04  Submit stays disabled after valid PIN code entered

Env:      Chrome 130 on Windows 11, build shared 10 Nov
Severity: Major   Priority: High

Steps:
  1. Open the address form
  2. Name: Ravi Kumar, Phone: 9876543210
  3. PIN code: 201301 (valid, auto-fills Noida)
  4. Leave 'Landmark' (optional) empty

Expected: Submit button enabled
Actual:   Submit stays disabled; enables only if
          Landmark has text

Evidence: screen recording, console shows no error
Note:     Optional field is being treated as required

-- Task: find orders that have no payment record

SELECT o.order_id, o.customer_id, o.amount
FROM orders o
LEFT JOIN payments p
       ON p.order_id = o.order_id
WHERE p.order_id IS NULL;

-- Task: find orders paid more than once

SELECT order_id, COUNT(*) AS payment_count
FROM payments
GROUP BY order_id
HAVING COUNT(*) > 1;

-- A finalist who explains why INNER JOIN would
-- hide the unpaid orders usually wins this round.

Symptom: Cart page shows total Rs 0 after adding an item.

Step 1: Open DevTools > Network, reload the cart.
Step 2: Find the request GET /api/cart
Step 3: Read the response body:

  { "items": [ { "sku": "TS-01", "price": 499 } ],
    "total": 499 }

The API returns the right total, so the defect is
in the front end display, not the backend calculation.
Log it against the UI component with this evidence.

If the API had returned total: 0, it would be a
backend defect instead.

INTERVIEW LOG

Company type / role: __________________
Rounds cleared: _______________________
Where it ended: _______________________

Questions I answered well:
  1. ____________  2. ____________

Questions I struggled with:
  1. ____________  2. ____________

JD skills I could not show evidence for:
  ______________________________________

Most likely reason (fit / assignment / skill gap):
  ______________________________________

THIS WEEK'S GAP: SQL joins (example)

Day 1: INNER vs LEFT vs RIGHT JOIN on a small schema
Day 2: Find missing records with LEFT JOIN ... IS NULL
Day 3: GROUP BY and HAVING for duplicates
Day 4: Write 5 data-validation queries for an order app
Day 5: Explain each query out loud in 60 seconds
Day 6: Mock question from a friend
Day 7: Add one SQL check to your project README

Only one gap per week. Depth beats coverage.

BEFORE SUBMITTING A TESTING ASSIGNMENT

[ ] Read the instructions twice, list deliverables
[ ] Test cases have IDs, steps, data, expected result
[ ] Each bug has env, build, steps, expected, actual
[ ] Severity and priority are set and make sense
[ ] Evidence attached: screenshot or recording
[ ] Duplicates merged into one bug with notes
[ ] One summary: scope tested, not tested, top risks
[ ] File names and format are clean and readable
[ ] Submitted before the deadline