I’ve focused on the danger of the technocracy before, which is where we turn testing into a programming problem. This has, in many cases, infused the interview process for test specialists as well. And yet automation is important! There’s no doubt that automation is a scaling factor and a way to leverage humans better. So that does bring up an interesting dynamic when you interview test specialists but where you hope to have some sort of programmatic focus.
I see a lot of companies who have trouble getting started with quality assurance and test positions. They do a lot of interviewing but make a lot of mistakes when bringing in those crucial first people that will let them scale for the future. These companies look for things like “ability to write test cases” or “knowledge of automation.” They don’t look for people who have specialized in testing. But what does that even mean?
I previously talked about some heuristics for hiring test specialists. There was an assumption in that post that you do, in fact, want to hire specialist testers. But, of course, that is just an assumption. Perhaps you don’t. And before you say “But of course we do!”, let’s talk about this a little bit.
I’ve talked quite a bit about the interview process for testers. Here I’ll try to distill some of that material around my experiences with hiring test specialists. By this term, I mean exactly what it sounds like: people who have chosen to specialize in the discipline of testing.
There is still so much wrong with how testers — even those who will write automation — are interviewed. I talked about this already regarding how technical test interviews are broken and about interviewing technical testers more broadly. Is there really more to say? I think so; let’s see if you agree.
Here I’m not speaking to the people who are interviewing for roles in automation. I’m speaking to the people hiring them. The interview process is entirely broken in so many places. According to Eric Elliot, code-based interviews have always been broken. And he’s probably right. Sahat Yalkabov said something similar. He’s probably right too. But here I’m focusing on the companies and hiring managers that are exacerbating the technocrat problem. So let’s talk about this.
It has been and continues to be my contention that many test and quality assurance interviews these days are handled terribly. I have seen, and participated in, interviews where candidates were barely tested for the wider aspects of how they think and approach problems at a human-focused level. Instead the focus is almost entirely about how they think and approach at the code level. So let’s talk about that.
One of my pet peeves in the industry is the often very lackluster ways I see testers being interviewed. So let’s talk about that a bit.
I recently did an interview for a “technical testing” position and it was one where they had you do a whole lot of exercises for coding. In fact, as far as I could tell, that’s pretty much what all the interviews were going to be. The interview was thus, to me, largely a waste of time. I actually told the interviewers that and, to be fair to them, they were quite gracious, did engage me in discussion, and actually seemed to agree with me on a few points. But here I want to talk about why I felt the interview was a waste of time and what role “coding exercises” have when hiring so-called “technical testers.”