Interviews done right

Tech job interviews. They are a very important part of the continuity of an organisation and the trajectory can wildly vary per company. I want to highlight a couple of tips for both interviewer as interviewee, from my perspective as having done both on several occasions.

Let's take a look at the companies' perspective. I think this perspective hold most value for both parties. Usually we can break down the interview process in a couple of steps, which boils down to the following phases:

Exploratory

This would be the first contact between both parties. The starting point can be originate from more than one point. It could be that you saw a job listing somewhere. Maybe you got in touch with someone already working at the company (not a recruiter), or maybe the company just stood out for a particular reason. This part is mostly about providing transparency (this will be a reoccurring theme) and a solid reputation. This is the stage where an interviewee will decide whether he/she would want to work for the company.

Introduction

From that stage on, you would want to get to know each other, basically the first exchange of information. This is where the job description gets analysed and maybe also some general meetings can talk place to disclose more information on the company and the job opening. As interviewee, this is where you can introduce yourself and provide a resume. If both parties are interested enough based on the mutual information exchanged, then this is usually the start of the hiring process.

General fit

Next up, try to find out whether the applicant would fit within the companies' culture. I think this might be the most important aspect to find out. Somebody can be super qualified for the job on paper, but if the collaboration just doesn't work, then all of that qualification is moot. This again, goes both ways.

Assessment

This can be a dangerous stage of the process and it can be done in a multitude of ways. Some companies provide online coding challenges or tests that are standardised. The good thing is the standardisation, but the drawback is that it doesn't really reflect a practical approach or show the thought process. You could also provide an assignment to solve (this is something we do in our current company). It give a bit more insight in the pragmatism, but still doesn't really highlight the thought process. In order to shine a bit more light on that, we take the output of the assignment as input for a second interview.

Then there's the dreaded whiteboard: solving code while being interviewed. This is not something I want to encourage, unless you allow for pseudo code or decision charts on high level designs rather than low level code solutions. Nobody codes on a whiteboard, so why would you interview that way.

Decision making

At this stage, I think the most important question to answer is whether the person you're interviewing has enough maturity for the role and if there's a cultural fit. I don't believe you can get more information by lengthening the hiring process. There has always been a shortage of engineers or developers. So it's a competitive market. The longer your process takes, the more likely it is that and interviewee drops out of the process for whatever reason out of your control.

I think key to successful hiring and retaining is to always be as transparent as possible. Hiring is a costly process. Tricking someone into a contract is not sustainable, because it will make sure that the turnover is higher than it could be and also taints your reputation as a company. Hiring for long term is much like getting into a relationship: honesty and clear agreements provide a more stable basis than putting someone through a gauntlet or sugar coating.