Software engineering interviews are like putting together IKEA furniture, a little bit of it is fun and interesting, but it gets dull quickly if you have to put together an entire office worth, and there are always a few extra bits at the end that you are unsure about because you haven’t read the manual, also, your opinion of the candidate feels complete, but if pressed on it more often than not it will fall down much like that IKEA cabinet. Simply put, an interview will never give us a complete picture of the candidate, so let’s discuss how to live with that.

There is no point in rapid fire technical questions about data structures, message brokers, database indexes, caching and so on, all you are checking with those is if the candidate got a passing grade at the university or if they recently read through AWS or Azure documentation with enough brain turned on to actually remember it. What’s far more important is them being able to apply their knowledge to solve a real business case problem in a reasonable way.

Another lacklustre exercise that became popular is the live coding challenges, the reasoning behind those is fine, but it might as well be passed by someone who went through an Udemy course on basics of whatever the framework in question is. I really hope that inverting a binary tree is just a meme at this point and that nobody actually uses it, because that would be like hiring a firefighter for their ability can piss very far, impressive, but hardly useful in a real emergency scenario.

Let’s think again about actually what are we looking for, is it individuals with vast technical expertise or code prodigies? Such skills are useful of course, but in a team environment it’s far more valuable to find people who can collaborate to solve genuine human or business problems, and be decent at coding solutions to those. Therefore interviews should centre around what software engineers spend most of their time doing: working with others, brainstorming ideas, being able to understand the essence of what needs to be done and how much effort is worth investing in that.

What should we do instead?

OK, so that’s a lot of what not to do, so what do I actually want to propose for successful interviews? Let’s imagine we are interviewing a fresh new candidate with a reasonable CV. We’ll start it off with a round of obligatory introductions and some friendly get to know each other, then let’s take a moment to say that the goal of the interview is mainly to have a nice conversation, that it’s encouraged to ask questions that there are no wrong answers, well, I mean, of course there are, but the idea is to make the candidate understand that we value open and clear communication the most.

My favourite starting question is “tell me about the something you recently worked on that you’re proud of for solving it”, yeah, it’s a bit cliche, but I like it because it’s an easy starting question, it allows the candidate show themselves off right at the start which help lighten any nerves, but there is also a lot to be discovered from their answer. What they say here also shows what this person finds important and how pragmatic they are about their solution. It also tells you what kind of a engineer they are, are they mainly technical or also product and business oriented, are they a lone wolf or a team member, are they are short term or long term thinker. Another thing, I always think highly of those who point out any mistakes they’ve done, or what they could have been done better, this is a quality that only those eager to improve show, you want those.

Next up is a brainstorming exercise with the candidate where I will present a real issue that my team had to tackle recently. I think it’s especially important that the problem is something you’ve personally worked on because it gives you the background knowledge on requirements and possible pitfalls that you can use to steer the discussion and see how the person sees those and how they handle the new information you present them. It’s not expected that the candidate will necessarily think of those on their own if they are niche enough, you as well might have only became aware of those during implementation work so be understanding of that when judging their answers. Here I’m always wary of overly confident candidates, they will not question themselves and often speak in absolutes, this is where your experience means a lot, you can find flaws in their logic and push them on it. The candidate being unsure or openly admitting they would need to investigate a bit actually show a great mindset, it tells your that they are aware of their gaps in knowledge and will always try to consider alternative options before committing.

The amount and depth of questions that the candidate asks at any point during the interview will tell you a lot more about them then how good they are at explaining the differences between linked and array lists. When was the last time that something like that was the biggest blocker in the implementation of a feature, in reality, the blockers are incomplete requirements, bad user experience and vague expectations and your new hire should be adept at navigating this unclear environment to get the best possible outcome for the customer, these people will bring true quality.

Lastly, the coding exercises should not be about writing new code, instead they should be about reading existing code, so I much prefer doing code review exercise to writing a new bit of code. This candidate will come into a living code base with real technical debt and most of their time will be spent understanding the existing stuff so it’s super important they are able to do that and that they offer quality feedback on it, much more then them being able to quickly churn out a new frontend component or a backend endpoint.

Let’s conclude

You’re hiring someone that will be a part of your team, be influenced by people already there and affect the culture of the existing team and company. Use the interview to understand if this person will bring a net positive effect to the culture and help steer it into the direction you believe is right. Yes, I understand that I’m asking you to see if the candidate passes the “vibe check” but you will be spending a lot of hours working with this person every day and so will your team, you should “vibe” them.