I pulled my engineering manager Ryan Anderson aside to discuss what he’s seeing across client environments right now.
What surprised me wasn’t the technology.
It wasn’t AI. It wasn’t Modern Automation Tools.
It was how companies describe their problems.
When engineering leaders reach out for help, they rarely come with a precise diagnosis.
Instead, they come with symptoms.
The bug count is climbing.
Customer complaints are increasing.
Releases feel riskier than they used to.
Teams are spending more time fixing issues than building new features.
Leadership knows quality is suffering. They know something needs to change. What they don’t always know is why it’s happening.
As Ryan put it:
“It’s more like a ‘they don’t know what they don’t know’ type situation.”
That observation stuck with me because it highlights a challenge I see recruiters and engineering leaders run into all the time. And the job seeking community can feel the effects.
Many organizations jump straight to hiring before fully understanding the problem.
Symptoms Aren’t Root Causes
Imagine a company notices a steady increase in production defects.
The immediate reaction might be:
“We need more QA engineers.”
Maybe.
But what if the real issue is a lack of test coverage?
What if the automation framework has become unstable?
What if the team lacks visibility into risk areas?
What if releases have accelerated but testing processes haven’t evolved with them?
Hiring additional people can help, but only if the underlying problem has been identified correctly.
Otherwise, you’re adding capacity to a system that may already be broken.
The Questions Clients Actually Ask
One of the more interesting things Ryan shared is that clients rarely show up with a detailed prescription.
They’re not usually saying:
“We need two Playwright engineers with five years of experience.”
Instead, the conversation sounds more like:
“We’re having quality issues.”
“Our customers are finding bugs.”
“We need to move faster.”
“What should we do?”
They’re looking for guidance on strategy, process, tooling, skills, and staffing all at the same time.
In many cases, the first step isn’t finding talent.
It’s understanding what problem the talent is supposed to solve.
Why Quality Problems Are Hard To Diagnose
Quality is unique because the symptoms often appear far away from the source.
A customer reports a bug.
The issue may have originated months earlier in:
- Test coverage decisions
- Framework architecture
- Release processes
- Technical debt
- Team structure
- Communication gaps
- Missing quality ownership
By the time the symptom becomes visible, the root cause can be buried underneath layers of process and technology.
That’s why experienced quality leaders spend so much time asking questions before recommending solutions.
The goal isn’t simply to add more testing.
The goal is to understand where quality is breaking down and why.
The Best Engineering Leaders Start With Diagnosis
One theme I’ve heard repeatedly from engineering managers and quality leaders is that strong organizations don’t begin with a hiring request.
They begin with problem definition.
Instead of saying:
“I need three automation engineers.”
They ask:
“What is preventing us from delivering quality software consistently?”
The answer might be people.
It might also be tooling, process, architecture, coaching, or a combination of all four.
The companies that improve quality the fastest tend to be the ones willing to diagnose before they prescribe.
Why Candidates Are Feeling This Right Now & What Recruiters Can Do
If you’re a Quality Engineer on the job market, you’ve probably noticed something feels different.
One company insists on Playwright experience.
Another demands AI-assisted automation for an environment that doesn’t even have mature automation framework yet.
A third wants someone who can evaluate multiple AI models and understand where each fits into the software development lifecycle because each team member is using AI in their own way, but have no clue how to vet for what specific experience is needed.
The reality is many organizations are still figuring out what’s required and what “good” looks like themselves.
As Ryan shared during our conversation, clients often come to Loop because they know they have a quality problem, but they aren’t always sure what combination of people, process, tooling, and strategy will solve it. Now Ryan comes from a technical background so he’s able to bridge that gap but often times that uncertainty makes its way into the hiring process. So if you are a non-technical recruiter, it’ll be tough to uncover specifics before you go to market with the role.
Candidates don’t see those conversations happening behind closed doors, but they absolutely feel the effects:
- Interview processes change.
- Expectations shift.
- Feedback becomes less consistent.
- Different companies define “AI experience” differently.
- Many companies don’t have a clear way to vet QE/AI skillset.
For recruiters, this creates a new challenge.
The goal is no longer just understanding the tech stack. It’s understanding the problem the hiring manager is trying to solve.
So if you’re a recruiter, before taking a QA Automation Engineering role to market, consider asking:
- What business problem is driving this hire?
- Does your team understand what success look like 6 months after this person starts?
- Are we hiring for framework expertise, quality strategy, AI adoption, or some combination of all three?
- How will this candidate actually be evaluated during interviews?
- What separates a good candidate from an exceptional one?
Those answers won’t eliminate every hiring challenge.
But they can help bridge the gap between recruiters, hiring managers, and candidates at a time when quality engineering expectations are evolving faster than many organizations can document them.
And that ultimately leads to a better experience for everyone involved.