What Happens When a Candidate Cannot Explain Their Automation Script

THE STALL — READ AS AN INTERVIEWER:

Interviewer: "Walk me through this test
script."

Candidate: "Sure. So this line... finds the
element? And this one... clicks it? And
then it checks... something."

What I notice:
- The candidate reads the code aloud like
  a beginner.
- They describe syntax, not logic.
- There's no "why" in any sentence.
- They pause at the assertions.

What the stall reveals:
❌ They haven't read their own code
  recently
❌ They don't know why each line exists
❌ They can't debug it if it breaks
❌ The script is a black box to them

What I do next:
- I ask: "Why an explicit wait here, not
  an implicit wait?"
- If they answer "it's what the tutorial
  said," the stall becomes a stop.
- If they can reason about it, they
  recover.

The strong answer:
"This test verifies the checkout flow. The
first line navigates to the cart. The second
waits for the cart total to be visible —
I used an explicit wait because the total
loads asynchronously, and an implicit wait
would only check for the element's presence,
not its visibility. Then it clicks checkout,
and the assertion checks the order number
against the regex."

Why it works:
✅ The test is named: checkout flow
✅ The logic is explained: navigate, wait,
  click, assert
✅ The why is named: async total, visibility
✅ The assertion is specific

THE TRUST DROP — READ AS AN INTERVIEWER:

Candidate: "I think this is a Page Object
Model. I'm not sure. It was written by a
teammate."

Interviewer: "So you didn't write this
script?"

Candidate: [pause] "I contributed. I ran it
a lot."

What I notice:
- "I contributed" and "I ran it" are the
  phrases that tell me the candidate didn't
  own the script.
- The tone shifts from evaluative to
  skeptical.
- I'm now asking myself: did they write
  anything on the resume?

What the trust drop reveals:
❌ The script is borrowed
❌ The framework depth isn't there
❌ The candidate's claims are now suspect
❌ The interview is now about verifying,
  not evaluating

What I do next:
- I ask about a different script, one the
  candidate claims to have written alone.
- If they can explain it, they recover
  some trust.
- If they can't, the interview is over.

The rule:
- A script you can't explain is a
  liability, not evidence
- A borrowed script contaminates every
  other claim
- The recovery has to start with honesty
  about what you wrote

COPIED SCRIPT — READ AS AN INTERVIEWER:

Interviewer: "What does this locator do?"

Candidate: "It's an XPath. It finds the
button."

Interviewer: "Why an XPath here, instead of
a data-testid?"

Candidate: [pause] "I'm not sure. The
tutorial used XPath."

What I notice:
- The candidate knows what the line does,
  but not why it's written that way.
- "The tutorial used XPath" is the tell:
  they copied it.
- They can't defend the choice.

What it reveals:
❌ The script is copied, not written
❌ The locator strategy wasn't a decision
❌ They can't debug a locator failure
❌ They're a script runner, not an
  engineer

What I do next:
- I ask: "What would you use if you wrote
  it today?"
- If they say "data-testid, because it's
  stable against CSS changes," they
  recover.
- If they say "I don't know," the depth
  score drops.

The strong answer:
"I'd use a data-testid instead of an XPath.
XPath breaks when the DOM structure
changes, and we've had three failures from
that. A data-testid is a contract between
the frontend and the test — it only changes
if the element changes. If the frontend
team doesn't add test IDs, I'd ask for them;
that's a conversation, not a workaround."

Why it works:
✅ The locator strategy is a decision
✅ The failure mode is named: DOM changes
✅ The fix is a contract: data-testid
✅ The conversation with the frontend team
  is the deeper fix

FULL RECOVERY — THREE STEPS IN 60 SECONDS:

Interviewer: "Walk me through this script."

WHAT YOU SAY:
"Sure. I want to be precise about what I
wrote and what I didn't.

I wrote the locators and the assertions. My
teammate wrote the helper functions — the
login helper and the data setup. So let me
walk through my part.

This locator finds the checkout button. I
used a data-testid instead of an XPath,
because the XPath broke three times when
the DOM changed. The test ID is a contract
with the frontend team.

This explicit wait waits for the total to be
visible, because the total loads
asynchronously. I didn't use an implicit
wait because it only checks presence, not
visibility, and I need to assert on the
visible text.

The assertion checks the order number
against a regex — a UUID format.

If I rewrote it, I'd extract the wait logic
into a helper. It's duplicated in four
tests right now, and that's a maintenance
cost I'd remove."

What the interviewer thinks:
- "They were precise about what they
  wrote." ✅
- "They explained the locator choice and
  the wait choice." ✅
- "They named the design debt." ✅
- "This is an owner, even if not the sole
  author." ✅
Signal: recovered. Strong hire.

Why it works:
✅ Honesty: what you wrote, what you
  didn't
✅ Depth: locator strategy, wait semantics
✅ Judgment: the design debt you'd fix
✅ The interviewer trusts the parts you
  claim

WHEN YOU DIDN'T WRITE IT — STILL RECOVER:

Interviewer: "Walk me through this script."

WHAT YOU SAY:
"I have to be honest — I didn't write this
script. My teammate did, and I inherited it
when they left. But I can tell you what
I've done with it since.

I refactored the locators from XPath to
data-testid after three DOM-change failures.
That's my change — I can show you the PR.

I added the explicit wait on the total
because it was flaky in CI. That cut the
flake rate on this test from about 15% to
under 2%.

And I wrote the assertion on the order
number — before, the test only checked the
page loaded, not that the order was created.

What I can't explain is the helper functions
— the login helper. I haven't touched it.
If you want, I can read through it now and
tell you what I think it does, but I'd
rather be honest that it's not mine."

What the interviewer thinks:
- "They were honest about what they
  inherited." ✅
- "They named three changes they made." ✅
- "They quantified one: 15% → 2% flake." ✅
- "They offered to read the part they don't
  own." ✅
Signal: recovered. Hire.

Why it works:
✅ Honesty: not the author
✅ Ownership: three specific changes
✅ Numbers: flake rate 15% → 2%
✅ Humility: offer to read the rest
✅ The interviewer trusts the parts you
  claim

Automation Script Checklist:

FOR EACH SCRIPT ON YOUR RESUME:
☐ Purpose: what it verifies in one sentence
☐ Structure: the steps in order
☐ Locators: the strategy and why
☐ Waits: explicit vs. implicit and why
☐ Assertions: what's checked and why
☐ Design debt: what you'd fix

BEFORE THE INTERVIEW:
☐ Read each script end to end
☐ Write a 60-second walkthrough for each
☐ Practice out loud, line by line
☐ Record and listen for "I think" and
  "maybe"

DURING THE INTERVIEW:
☐ Name what you wrote and what you didn't
☐ Walk the part you own, line by line
☐ Name the why for each choice
☐ Name the design debt
☐ Offer to read the part you don't own

RED FLAGS IN YOUR OWN ANSWERS:
❌ Reading the code aloud without the why
❌ "The tutorial used XPath"
❌ "I just ran it"
❌ "One is longer" for explicit vs.
  implicit
❌ "The teammate wrote that" with no
  ownership

THE OWNERSHIP TEST:
For each script, ask yourself:
1. "Can I explain why each line exists?"
2. "Can I name what I wrote vs. what I
   inherited?"
3. "Can I name the design debt?"

If any answer is no, that's the script to
study before the interview.

30-DAY SCRIPT PLAN:

Week 1 — Read your own scripts
☐ Pick 3 scripts from your resume
☐ Read each end to end
☐ Write a 60-second walkthrough for each
☐ Record and listen for vague language

Week 2 — The why
☐ For each line, write the why
☐ Locators: why this strategy?
☐ Waits: explicit vs. implicit and why
☐ Assertions: what's checked and why
☐ Practice the why out loud

Week 3 — The ownership
☐ For each script, write what you wrote
☐ Write what a teammate wrote
☐ Write what you changed after inheriting
☐ Practice the honest attribution

Week 4 — Mock interview
☐ Have a peer pick a script and ask
  "walk me through this"
☐ Give the 60-second walkthrough
☐ Have them ask "why this locator?" and
  "why this wait?"
☐ If you pause, that's the line to study

Signs it's working:
✅ You name the purpose in one sentence
✅ You explain the why for each choice
✅ You attribute honestly
✅ You name the design debt
✅ The interviewer asks "tell me more"
  instead of "let's move on"
✅ You leave feeling you were understood,
  not just quizzed