I’m talkin’ to alot of QA engineers in the Charlotte market and have ran into automation engineers getting contacted about roles that look heavily focused on manual testing.
For example, I came across a QA Engineer role in the insurance brokerage space that called for 7+ years of manual testing experience, SQL, Agile/Scrum experience, and a willingness to learn a low-code automation tool.
I had several automation engineers reaching out to me to see if I knew anything about this role and I thought to myself: Would an automation engineer actually be a fit for this kind of role?
And honestly, what does “7+ years of manual testing” actually tell me about a candidate?
Instead of guessing, I grabbed the req and took it to my engineering manager, Ryan. I asked him: Without more of an understanding from the client, if you were evaluating candidates for this specific role, how would you actually figure out who can do the work?
His answer gave me a much better way to think about technical recruiting.
Start with the work, not the keywords
My first instinct as a recruiter might be to look for:
- 7+ years manual testing
- SQL
- Agile
- API testing
- Automation
- ACCELQ or another low-code tool
But a list of keywords doesn’t tell me how someone actually works. Ryan started giving me questions that would uncover the experience behind those keywords. That was the part I wanted to share with other recruiters.
What does “manual testing” actually mean?
If a candidate tells me they have 7+ years of manual testing experience, I can certainly document that.
But what does that experience actually look like?
Ryan suggested asking questions like:
- How do you know when you’re done creating test plans?
- What’s the difference between exploratory testing, feature testing, and regression testing?
- When would you use each?
- Where do accessibility, security, and load testing fit into your testing strategy?
Those questions tell me more than any number of years on a resume.
What does “SQL experience” actually mean?
SQL can be another big one. A resume might say “SQL” and a recruiter could check the box and move on.
Instead, Ryan suggested asking:
- What types of issues have you uncovered when testing databases or schemas?
- Have you tested stored procedures?
- Have you run into challenges with data integrity?
- What’s the most interesting SQL bug you’ve found?
Now I have something I can take back to the hiring team.
Maybe the candidate has only used SQL to pull basic data. Maybe they’ve actually used it to investigate production issues and validate data across systems. Those are very different levels of experience, even though both resumes might simply say SQL.
What does “Agile/Scrum experience” actually mean?
“Worked in an Agile environment” is probably one of the easiest things to put on a resume.
But what did that actually look like?
Ryan suggested questions around how the team breaks down work:
- How did your team break down epics, features, user stories, tasks, or subtasks?
- Did QA acceptance criteria live on the story or somewhere else?
- How did QA estimate work for a sprint?
- How did your team decide what could realistically fit into a sprint?
- What worked well about that process?
This also changed how I think about requirements like “support multiple Scrum teams.”
It’s not necessarily about whether someone supported one team versus five. I’m more interested in whether they understand how to manage competing priorities, estimate testing work, communicate risk, and coordinate with development teams.
What about “API testing”?
Again, I could search for “Postman” on a resume and call it a day.
But Ryan pushed it further.
Questions like:
- What tools have you used for API testing?
- Have you done contract testing?
- How have you handled API workflows where one request depends on the state created by another?
- How have you handled credentials or authentication between API calls?
Now I’m not just asking whether they’ve opened Postman I’m trying to understand whether they’ve actually worked with API workflows and the problems that come with them.
What if they don’t know the exact automation tool?
The role I was looking at mentioned a specific low-code automation platform.
That raised another recruiting question: If the candidate doesn’t have that exact tool on their resume, should I move on?
Not necessarily.
I’d want to understand:
- Have they used other low-code or no-code testing tools?
- What types of tests did they build?
- What did the tool allow them to automate?
- What were its limitations?
- How have they learned new testing tools in the past?
And then there’s bug triage
“Walk me through what happens when you find a bug.”
Ryan suggested digging into things like:
- How does the team determine whether something is actually a bug?
- How is severity determined?
- How is priority determined?
- Who participates in bug triage?
- Is there a regular process for reviewing and prioritizing defects?
So, are automation engineers “overkill” for a manual-heavy role?
Going back to my original question: not necessarily.
Ryan’s perspective was that automation experience can actually be beneficial because an automation engineer should understand manual testing before deciding what is worth automating.
Someone with that background may be able to recognize what can be automated, what still needs hands-on testing, and where automation could eventually make the team more efficient.
Of course, there are still practical recruiting questions around compensation, career interests, and whether the candidate actually wants the work the role requires. But that’s different from automatically ruling someone out because their background includes more automation.