My thoughts on the interview process and whether technical coding tests are worth it.
I prefer a single-stage "informal chat" approach where possible, usually around an hour long. For me, it's the best way to get a good idea of a candidate's skillset, especially if they have a lot of experience. I don't see very much value in technical code tests. In my opinion the only thing worse than a mandated technical code test is an on-the-spot, while-we-watch mandated technical code test. Even if the candidate works well under pressure, you're still testing their ability to perform under unrealistic and impractical conditions, so who cares if they are good at something completely irrelevant to the role?
Sometimes, if torn and unable to decide one way or the other, maybe an offline coding exercise time-boxed to a week or so might give some pointers that can help. But I still find code tests more often than not are fraught with false-negatives which makes it difficult to take anything of value from them. In general, in my experience a coding exercise is just not worth it in the end. A big part of my reasoning on this is probably because I'm not really looking for low-level programming skills anyway. I'm far more interested in the following skills:
Obviously, it's important to be able to actually code as well! But it's definitely not the most important skill and besides, it's much easier to figure out if someone can code (by having a discussion with them) than it is to score them on the above criteria. A good programmer excels at low-level programming skills. A good Software Engineer is a good programmer plus all of the above. Even the most technically focused role is still more about working in a team than being somone who is shit-hot at a particular language but hates talking to anyone or sharing knowledge. In general, code readability is far more important than using advanced coding techniques that reduce readability. The ability to clearly and patiently teach how a system works in an approachable and non-offensive manner is far more important than being the only dev in the building who understands it!
When I tell people I conduct interviews as an informal chat, sometimes they get the wrong impression and presume I'm just being lazy or that it's just an easy way out so I can get it over with, but it's quite the opposite! Conducting interviews fairly and with a view to getting as much value out of them as possible for both parties is one of the hardest parts of my job. I find candidates respond to the "informal chat" format extremely well, not because it's easy but because they are being seen as individuals and being treated fairly. It also helps to relax the candidate and make them feel at ease so we can really focus in on finding out if we are a good fit for them and vice-versa. It reframes the entire interview from being a one-sided meeting with an interviewer leading from a position of superiority and an air of suspicion to something far more authentic and effective - a back-and-forth chat where the candidate is just as likely to be asking the questions as the interviewer.
A lot of interviewers start by describing the role. This is a waste of time because most of the time the the candidate isn't even listening at this stage! They are too busy freaking out whether there will be an on-the-spot technical test! This is why I always start by explaining up-front there will be no tests or on-the-spot technical trivia - it will be an informal discussion structured around their CV. I find this instantly puts them at ease. Next, I ask the candidate to walk through their CV and give an overview of each role, their technical skills, programming languages experience, etc. I try very hard not to interrupt them during this part - the purpose of it is to provide the context for the rest of the discussion, so I'm hoping they cover a wide range of topics that I can revisit when asking questions later. One way I avoid interrupting is because I'm too busy writing notes but I have to be careful about doing so. I often make a joke "I have a terrible memory so I'm just writing down reminders so I can't come back to them later" or something like that. Again, this puts them at ease and helps prevent them from wondering "what is he writing about me? Did I just say something wrong?".
After the candidate has finished summarising their CV, I begin asking questions such as “what are you most proud of?” and “can you discuss a project you hated and why?” and “discuss a time when you made a mistake and had to recover”. However, it’s better to avoid asking those questions generically without any context as that puts the candidate on the spot and they might rush and choose a suboptimal example. So I try to focus the questions on the candidate’s experience as that makes it easier for them to choose ideal examples from stories they have already mentioned in their CV summary.
Here are some more guidelines I try to follow for getting the best out of the discussion:
Some general topics I like to consider depending on the type of role:
It’s easy as an interviewer to forget how one-sided the interview process can be. To the interviewer, it’s just another meeting in a familiar environment where they know exactly what’s going to happen and what they are looking for. To the candidate, it could be life-changing, everything is unknown, it’s an unfamiliar environment and they have no idea what to expect or how they are going to be treated. This puts the candidate at an immediate disadvantage. Unless this inequality is defused right at the start, there is an extremely high chance of false-negatives and a danger the entire interview will end up being a waste of time for both parties. Or worse, the interviewer may make a decision to hire or reject the candidate based on these false-negative which sadly, is often the case.
To summarise, the informal-chat approach is based on the interviewer and the candidate starting from a position of equality forming a balanced discussion with questions coming from both parties where the goal is clear - to find out if the company is a good fit for the candidate and vice-versa.