I Started Hiring for QA. I Ended Up Rethinking the Role.

A couple of months ago, we merged QA into Engineering as part of a broader effort to improve how the team works, and I took over hiring across the QA positions.

This happened during our shift-left journey. Engineers were already taking more responsibility for testing their own work, which forced me to think more seriously about what we expected from the people specializing in quality.

There was clearly still a place for dedicated quality expertise inside Engineering. I just had a much less clear idea of what that role should look like.

I come from an engineering background and naturally like building things and questioning processes once they become too comfortable. That has caused a few healthy clashes with QA teams over the years.

One pattern has always bothered me. A feature gets finished, somebody receives it, clicks through a predefined set of cases, reports the findings, and moves on. Repeat that every sprint, and quality slowly becomes routine.

From QA to QE

We started with the job description.

Manual testing became a smaller part of the position. Several older testing tools disappeared from the requirements. Framework development, CI/CD, telemetry, technical investigation, and working closely with engineers became much more important.

As we worked through the role, it became clear that what we were describing was much closer to Quality Engineering than traditional QA.

Framework development was high on my list because I had seen automation suites grow in fairly predictable ways.

You start with a few Playwright tests. Every feature adds another E2E flow. Helpers get copied, coverage overlaps, execution gets slower, and flaky cases creep in. Eventually a red pipeline triggers a discussion about whether the test is broken before anyone looks at the application.

You can have hundreds of automated tests and still have very little confidence in the suite.

I treat test code like code we expect to maintain for years. Structure, reuse, reviews, and ownership matter. Counting tests tells me very little about the health of a testing setup.

I also expect a QE to understand enough of the underlying architecture to inspect what is happening inside the system. A browser should never be the only place you know how to validate behavior.

Depending on the change, the useful evidence might be an API response, a database record, a Redis value, an object in S3, or an application metric. That understanding makes testing faster and usually gives you a much clearer picture of what actually happened.

I expect the same level of thinking when reviewing a pull request or any meaningful code change. Someone should be able to understand the likely impact, see what coverage already exists, and decide how much additional validation makes sense.

Once engineers take on more of the testing work themselves, QE can spend more time improving the framework and helping the team make higher-quality decisions.

Hiring changed my assumptions.

This part became more interesting than I expected.

We received plenty of candidates with long careers, recognizable company names, and impressive collections of testing tools. Selenium, Cypress, Playwright, Postman, JMeter, Cucumber, Appium. Sometimes the list felt endless.

Their CVs looked like Swiss Army knives. Every possible tool was there.

Then I would ask what they had actually changed in their previous organization.

That question became surprisingly effective.

After enough interviews, the classic IBM or Accenture-style profile stopped carrying much weight for me. A famous logo and fifteen years of experience provide some context. I became far more interested in what someone had improved, introduced, or personally pushed forward.

One thing genuinely surprised me. Some candidates had spent years testing the same product and knew very little about its architecture. Occasionally the business domain was equally vague.

That is a serious red flag for me.

If you spend several years working in the same product or domain, I expect you to understand how it works beyond the surface. You should know where the complexity lives, which areas are fragile, how the main components interact, and what tends to make releases risky.

Some candidates with fewer years in QA impressed me more simply because they had stronger stories. They had changed things, built things, challenged existing processes, and could explain why.

That became a much stronger signal for me than another ten tools on a CV.

Resume screening also became harder.

Almost every CV now looks excellent. The wording is polished, the experience matches the job description, and every relevant technology appears somewhere. Somehow everyone has spent the last five years preparing specifically for a vacancy we posted last week.

AI clearly plays a part in that.

We changed the early screening questions to encourage real stories. What did you change? Which problem did you solve? What are you proud of?

People who really owned those situations usually remember the messy details. The disagreements, failed attempts, and strange workaround that finally worked tend to come out naturally.

I also use our AI Recommendation Engine, along with a few custom prompts, to surface candidates who match the characteristics we consistently see in stronger profiles.

There is something mildly ridiculous about using AI to deal with a pile of AI-polished resumes.

It gives us another signal and often tells me where I should dig deeper in the next conversation.

The interview changed too

I am keeping the actual exercises private while we are still using them.

Strong candidates tend to spend some time reading and thinking before touching anything. They ask questions and look for structural problems. Quite often they start questioning the test itself.

What are we trying to validate here? Does the specification make sense? Where is this behavior already covered?

I like that.

I have also developed a lot of respect for candidates who are comfortable asking for more information.

A surprising number of people seem terrified of doing that during an interview. They guess, defend the guess, and then invent more detail when you ask another question.

Sometimes you can watch the answer drift further and further away from reality.

At that point, the interview starts to feel like talking to an LLM with the temperature set too high.

Knowing when you are missing information is part of engineering. Knowing which question to ask next matters just as much.

What I learned

Taking over QA hiring forced me to learn much more about the discipline on my own.

I went deeper into testing frameworks, automation architecture, and tooling. I also spent time understanding why certain QA practices existed in the first place.

If you interview specialists, you need enough domain knowledge to recognize when an answer sounds impressive and makes very little sense.

The process changed some of my own views too. Coming from engineering, it is easy to look at QA and form strong opinions about how things should work. Learning more about the domain and speaking with many different candidates gave me a more nuanced view.

The profile I am looking for is much clearer now: an engineer by nature who specializes in quality.

Finding that person takes time, and I have become much more careful about compromises made to fill an open position.

Shift-left changes the people you need around the engineering team.

Figure out where you want quality engineering to go, then hire people who can help you build it.