One Approach to Interviewing Testers: The Epilogue

No recruitment process is perfect, for several reasons, and neither was the one I described i the previous three posts. While I think we had pretty good success with it there are certainly things to consider and modify, and it needs to be adapted to suit your context. Let’s have a look at some of the challenges:

It’s a lot

As evident by the fact that it took me three posts to describe the process it’s relatively comprehensive. Given that a candidate might have already had a chat or two with their agent, if they work with one, and depending on your process maybe an initial chat with an internal recruiter, this entire thing ends up being fairly long. One of the reasons for going for the full day SIAD I think was to at least get it done rather than stringing things out even further.

As mentioned, we considered moving the final session, where we discussed culture, teamwork, agile, organisational and behavioural things, up front before the SIAD. We did this for at least one developer interview that I was part of when the candidate was from abroad. We did that by video conference and I think it worked pretty well. It’s not quite the same as having someone there in person but as long as both ends has a somewhat stable Internet connection I think it’s OK. The drawback is of course that this is likely to prolong the process by at least a couple of days, likely more, unless you really streamline things. If you’re not scheduling the next stage until making a decision on the previous it can en up taking a long time. Asking the candidate for their next availability, sending an invite and getting a confirmation and aligning with whoever will do the interview can in worst case end up taking several days, maybe a week or so.

I think it would be a good thing to move it though. After a long SIAD day with various tasks at a relatively high tempo it might not be easy find the energy and creativity to generate great questions and arguments for that last session, or even to speak somewhat coherently at all.

The Homework

Few people like homework, but more importantly it might be difficult for some to find the time.

If you’re actively searching for jobs you might have multiple applications in play at the same time. Getting loads of homework from multiple companies can quickly stack up and there’s only so many hours in the day.

Aside: There is some sense in stating that you should limit yourself to applying for only the jobs you really want but on the other hand this is a bit simplistic. If you currently have a job, fine. You can take your time. But if you’re out of a job or on notice you most likely need to hedge your bets a bit and work multiple good looking opportunities.

Being a single parent, having a long commute, caring for family members young or old, or working multiple jobs to make ends meet are only a few of many reasons why some might find it difficult to spend a lot of time on homework. This is an important aspect to recognise and you might want to consider carefully what information you are likely to get from the assigned task. At the very least, let the candidate know that you understand this can be an issue and that you are willing to consider alternatives. Does the candidate have a blog, or a GitHub repo with anything relevant? Even if they are squeezed for time at the moment they might have done things in the past. Have they written any articles or presented at conferences or meetups? These things are not for everyone though. It’s fine not being a bubbly extrovert who loves to be in the spotlight.

Depending on your situation I think maybe the homework would be my favourite for getting rid of. When I went through this the process had some small differences. At that time the candidate was asked to implement a simple Rock-Paper-Scissors(-Lizard-Spock) game, preferably in Java, and using TDD would be nice. The planning session, pair programming session, and the in-office (monitored) testing, all revolved around an RPS application. My Java/UnitTesting experience was pretty much limited to doing half a course on Selenium/Webdriver for Java at that time so it was an interesting weekend hacking something together. Due to the way we worked with testers embedded in the teams it was quite valuable for a tester to be comfortable seeing code, but we later reduced the emphasis on being able to code and switched to the Sudoku homework described in Episode Two to open it up a bit more and give the candidate a broader range of skills to display. In retrospect, this brought it at least a little bit closer to what would be done during the SIAD and perhaps making it a bit more redundant. Because of this, and as good candidates with several good options might not bother when you ask for homework, I think skipping the homework and replacing it with the Behavioural/Agile video call would probably be my first suggestion for an experiment to simplify or shorten the process.