I spoke with a QE director who oversees a pretty complex environment. He was telling me about some of the roles he had open, and one thing caught my attention: the level of product and domain knowledge he wanted from the engineers.
It was deep.
Deep enough that I started wondering whether we were talking about a QE requirement, a product/BA requirement, or some combination of the two.
I didn’t want to make that call myself.
So I took the conversation to Ryan, an engineering manager I work with, and asked him to help me understand what questions I should be asking the hiring manager.
We talked through things like:
- How critical is the domain knowledge on day one?
- What happens if someone has strong QE skills but needs to learn the product?
- Is this requirement based on previous hiring experiences?
- What does the current team makeup look like?
- Is there a gap somewhere else on the team?
- Is the engineer expected to take on responsibilities I’d normally associate with a BA or product role?
- How much are they willing to trade a smaller candidate pool for faster ramp-up?
Ryan reviewed the laundry list of vetting questions and was able to look at it from an engineering perspective and say, essentially, “I understand what we’re actually going to need to test.”
I not trying to talk the hiring manager out of his requirements but as a recruiter it’s imporatant to understand the why underneath them, whats wanted vs needed and how does that compare to the current landscape.
Where does the domain knowledge belong?
We also spoke about the environment itself.
They’re not heavily using AI to do the interpretive work around the product and domain.
What does the BA or product person own?
What does the engineer need to understand well enough to do their job?
And where does the QE’s technical responsibility start and end?
Those questions matter when you’re hiring for a highly specialized environment.
A manager may genuinely need someone with deep domain expertise. Or they may be looking for that person because the team is missing something elsewhere.
Those are two very different recruiting problems.
And I don’t think the answer is always to challenge the requirement or blindly accept it.
Sometimes you just need to understand the reason behind it.
That’s what I took away from this conversation.
Don’t just ask, “Can I find someone with these requirements?”
Ask:
“Why does this role need them?”
Because once you understand that, you can figure out what actually needs to be tested, what skills are truly necessary, and what might simply be a preference based on how the team has operated in the past.