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.
Actually, this is like beating a dead horse so I’ll keep this brief. I’ve already talked broadly about this regarding interviewing technical testers for broad skills and regarding interviewing testers as if you want testers.
Companies are still doing things like FizzBuzz, Anagrams, summing up numbers in an array, etc. I saw one about building a Sudoku solver. Now I get it: knowing algorithms can be useful. But there’s actually a lot more that’s useful for automation.
So let’s say your primary role, in the context of testing, would be automation in a given role. Maybe someone is even going to call you a SDET or SET. All of those things I just mentioned are absolutely not things that a test solution developer in that context would tend to code. So why do companies still waste time with these for technical testers?
I would rather see something like what I present here: Amazon Automate. This is the basis for a Selenium challenge, essentially using Amazon to see if someone understands how to write tests and code them up. That works because you’ll probably use Selenium a whole lot.
So, hiring managers, if you are interviewing candidates for an automation-style role and (1) you are not making sure that person is a good tester first and (2) you are focusing on the oft-used “algorithms” checks — you’re doing it wrong!
Automation is not testing. Automation is a particular technique; it is one that can be applied in the context of testing. As such, automation is not about writing a solution for the “FizzBuzz” problem. Automation is not about seeing if you can write code that will check if two digits in an array sum to a target value. Automation is not about seeing if you can solve palindromes or isograms.
Automation is about making decisions about technology such that it augments the testing work of humans, without the suggestion that it can replace it. Thus you want automation that is going to scale; that is going to be maintainable.
You want automation that is going to have a specific design philosophy for how it is constructed. You want automation code that is going to employ reasonable patterns in a way that is relevant to how test and data conditions are expressed and executed. Automation is often about choosing the right level of abstraction for consuming tests and executing them as checks, to use the current distinction of “testing” vs “checking.” (That is something I believe we testers get wrong.)
Given all this, if you are the kind of interviewer that I’m talking about, why are you interviewing for these roles as if you were interviewing for an enterprise developer?
Stop wasting everyone’s time, including your own.