Thoughts on Tech Interviews Wed 1 Jun, 2016

In recent months, I've taken part in quite a few job interviews. I was looking to make a switch from an agency/consultancy role, back into the world of product development. Now I've had numerous interviews before, and I've also conducted a few in my time, so I feel as though I have pretty decent outlook on them. I try to view them as a 2-sided conversation, where each party tries to give a true representation of themself. No more, no less. It was with this same mindset that I approached recent interviews. This time, however, things didn’t go quite as well as I'd hoped. 😞

The first few rejections I dismissed as rustiness, or luck of the draw. After a couple more, I started to get introspective about what was going wrong. I thought my hypothesis was confirmed after coming up short yet again, so then I vowed to spend time rectifying it. Not long after, and before I’d had any real opportunity to address my perceived weaknesses, I landed a couple of job offers. So what changed? Did I magically improve in some way? Was it blind luck?

Having experienced a range of interview styles and formats, and marrying those against my own views, I wanted to take stock of the current state of tech interviews.

Face-to-face

A face-to-face interview is not for testing technical ability. If you have some purely technical criteria that candidates have to fulfil (more on that later), I’d suggest keeping it away from the interview. This is the time to determine whether or not you are a good fit for each other, not to test whether they have the technical capabilities required to join your company.

In my experience, being given a test^[1] in an interview, and having to pass said test, immediately creates an adversarial dynamic. I go from listening to what you’re saying, and thinking about the conversation at hand, to an overwhelming awareness that, “I need to pass this test now”. Intentionally or otherwise, you’ve massively increased the chances of me screwing up. Now, there are people who might excel in this kind of situation. Hats off to them. But as an interviewer, why would you choose to hinder the proportion of people who don’t? What is the value in that? Our jobs as developers do not require us to carry out tasks on-demand, whilst being watched and evaluated in real-time. By creating this kind of dynamic in an interview, that’s what you’re optimising for.

Also, it's probably fair to say that you don’t know exactly what challenges or opportunities your company will face in the future. How do you test someone against that reality? The industry these days embraces the notion of uncertainty. We find the best solutions given what we know now, in the knowledge that we’ll probably need to change things in the future. I feel as though this ethos has yet to transfer into how we evaluate prospective employees. If it did, then I think more people would see that it isn’t what a candidate knows today that is most valuable, it’s what they can know in the future. Therefore, the face-to-face interview should be about gauging an individuals ability to communicate, and their potential to learn and adapt.

[1] By test, I am referring to things such as exam style questions, brain teasers, live-coding, or white boarding exercises. These tend to be either jarring, discreet exchanges, or completely one-sided. Ideally, an interview should be a flowing, 2-way conversation.

Technical Capability

I’ll admit, this is a tough one. Opinions on how to gauge technical capability vary wildly, and there’s no doubt that different companies have different requirements. Here, I’m only referring to my experiences in web (predominantly UI) development.

I am not averse to asking candidates to complete a technical exercise. This should be done before a face-to-face interview, and can be used as an anchor for the conversation. However, before settling on that approach by default, I would also consider using their previous professional work as a means of evaluating their ability (not what’s on their personal GitHub!). If they are willing, and are legally allowed, asking to see what they’ve worked on in the past is the truest indicator of what they are capable of producing. You also get to hear how they communicate in a professional context. I have encountered some concerns that get raised to this approach though;

1. What if they overstate their involvement?

   That’s what the interview is for. If they are able to clearly explain the project’s background, how it was carried out, the technology choices made along the way, then I think you’re on safe ground. But also, assuming that the candidate will lie sounds awfully adversarial. 🤔

2. Previous work uses a different tech stack

   Are you kidding? If someone has experience in a particular tech stack/language, and is taking the decision to move to another, that shows a whole bunch of traits that you surely want on your team? Broader perspective, curiosity, drive, desire to learning new things… the list goes on. This boils down to long vs short term outlook, though if you're not hiring a freelancer, it should always be long.

3. It’s not an even playing field. The same coding exercise for everyone is more objective

   We know that standardised testing doesn’t work. People are complex and varied, and you are trying to hire from that pool (hopefully). Acknowledge that diversity and work with it. There is no short-cut, so why take the risk when we know that a bad hire is far more costly than no hire.

If you ultimately do need to set a technical exercise, here are what I think are some sound rules to follow;

• The exercise should resemble the kind of work that happens in your company. If you make pretty marketing websites, don’t ask them to write a sorting algorithm, or solve an abstract puzzle.
• Explicitly state what you value. Do you want to see tests? Then say so.
• They should be able to do it in their own time
• They should have a sensible time scale in which to try to complete it (e.g. a few days)
• They can use any or all of the resources that your own employees have access to (Google, Stack Overflow, their peers etc)

Finally

So what was different about the interviews I was ultimately successful in? I think it says everything that I came out of them with an absence of feeling crap about myself, and I put that down in large part to how they were conducted. I got the sense that it was a level playing field. Each session was eased into, allowing both sides to build rapport and get comfortable with the situation. Things felt natural, to the point where when some technical questions were asked, it was no big deal. The technical exercise I had been asked to do beforehand was to build a responsive web page from a static design (shock horror!). All in all, the whole process was, dare I say, enjoyable, and I feel as though I was given every chance to show the best of myself. There is no reason why this shouldn’t be the norm, and I'll be doing my best to try and make it so.