I had a friend call me last week after an interview: upset, and crying.
She’s a strong manual QA tester. Solid fundamentals. The kind of person who can break down a product, find edge cases others miss, and actually think like a user. Not someone “figuring it out”, someone who already knows the craft.
I pulled up the job description she interviewed for.
It was clear on paper:
A QA Engineer role built on fundamentals: test case design, boundary testing, regression testing, exploratory testing, paired with automation and emerging AI-assisted testing tools.
The kind of role where manual testing and automation are meant to work together, not compete.
Here’s a shortened version of what the JD looked like in practice:
- Strong testing fundamentals (test design, regression, edge cases)
- Hands-on manual exploratory testing
- Automation for web and mobile apps (Cypress / Playwright / Selenium-type stack)
- Some exposure or curiosity around AI-assisted testing
- Collaboration with product and engineering teams
- Ownership of QA strategy, not just execution
On paper, it reads like a hybrid QA role:
manual + automation + emerging AI tooling.
So she applied. She was screened by a recruiter. Her background aligned with the fundamentals listed in the job description. She was submitted.
And then she walked into the interview.
The interviewer didn’t ask about testing fundamentals.
Not test strategy. Not edge cases. Not regression approach. Not exploratory testing.
Instead, she was given software engineering-style questions and a live coding scenario.
That was never the role she prepared for.
And when she struggled through it, the interviewer kept saying things like, “I’m trying to help you out.”
But it didn’t feel like help. It felt like exposure.
She called me afterwards completely deflated. Not frustrated at the process, frustrated at herself. Like she had failed something she was never actually aligned to do in the first place. In the moment, she didn’t stop the interview or redirect it…she just rode it out, like alot of candidates do when they’re caught off guard like that.
And that’s the part that sticks.
Because this wasn’t a skill gap story.
It was a setup gap story.
We talked it through.
And I told her plainly: this isn’t on you.
If a manual QA engineer is placed into a coding-heavy interview for an automation-first expectation without alignment upfront, of course it breaks down.
That doesn’t make her “not good enough.” It means the signal between the role, the recruiter, and the interviewer was misaligned.
But we also talked about what she can control next time:
- Ask the recruiter to clarify what the actual day-to-day looks like
- Push for clarity on where the role sits on the manual ↔ automation spectrum
- If an interview suddenly shifts into a different lane, pause and reset:
“Can we align on what this role is prioritizing? I want to make sure I’m answering in the right context.”
Simple things, but they keep candidates from getting pulled into the wrong narrative about themselves.
Because interviews like this don’t just evaluate skill.
They shape confidence.
But here’s the harder truth.
This isn’t just a candidate issue.
It’s a recruiting and alignment issue.
Before anyone gets sent into an interview process, three things need to match:
- What the job description says
- What the hiring manager actually expects in the room
- What the candidate actually brings
If those don’t align, the answer isn’t “send them anyway and see what happens.”
The answer is: pause, clarify, or don’t submit.
Because a bad intro doesn’t just waste time.
It can shake someone’s confidence in their own ability when nothing was actually wrong with them in the first place.
It’s a small world afterall and I know that internal recruiter. So I spoke with him to see what happened.
He liked the candidate overall and saw strong domain experience. While there were some concerns around programming depth for that particular loop, he felt her broader background and experience made her a potential fit, so she was advanced to a leadership interview. There were a few relevant overlaps in her experience that aligned with the team’s world, which helped justify moving her forward in the interview process.
And I get that instinct to forward the resume over to leadership for review. Most good recruiters want to create opportunity where they can.
But this was a mismatch in the wrong direction.
Not a stretch opportunity.
Straight up misalignment.
And in this case, it landed on the candidate’s confidence instead of on a productive conversation.
After we walked through it, even she softened her view of the situation. Not because the outcome changed but because the intent and the breakdown were finally clear.
So what’s the takeaway?
For recruiters:
Before you send someone in, pressure test the req.
Ask things like:
- If this person spent 70% of their time on automation backlog and 30% on sprint coverage, would that be success?
- What does the actual week-to-week breakdown look like today, not in theory?
- When you say “manual testing when needed,” who decides when that need shows up?
Because those answers determine whether you’re sourcing a tester, an automation engineer, or something in between.
And if you don’t know the answer yet—you’re not ready to submit.
Because the goal isn’t just filling a role.
It’s making sure the person walking into the interview actually has a fair chance to show what they’re good at.
Otherwise, you’re not evaluating talent.
You’re just testing misalignment in real time.
Have you ever walked into an interview expecting one role, only to realize it wasn’t aligned at all?
Did you ride it out like this candidate did, or did you pause and redirect?