We need to start again with the concept of a tech interview
Interviews are now bi-directional, you’re not just assessing whether the candidate would fit the company, the culture, and the role, but they’re assessing whether your company, culture, and role are going to fit them. Assuming you’ve already nailed your internal company culture and people would love to work within it, you’re going to need to sell it to the candidate!
How many times has the first question been in your interview “So how much do you know about our company?”. I’ve tried to unpick the goals, outcomes, and reasons as an interviewer this would be at all a relevant question. Does it highlight the individuals capability to analyse and ingest information? It might show their experience in similar domains in their ability to digest what your company does? Perhaps you’re testing your marketing department’s abilities? Fundamentally, I think it boils down to a preconceived idea that ‘you should really want to work here — prove it’.
The idea that someone should really want to work at your company for them to even be entertained as a candidate is rapidly dissolving as a concept, particularly in the software development world. It’s a candidate-focussed market, individuals have more choice and options open to them than ever before.
Code tests have grown across the market in different forms, sometimes it’s a live code test done in front of a panel of people, a ‘do at home’ test that you discuss in the interview, or even doesn't even get mentioned. I have been in interview processes where a printed sample of code was given to live debug with the panel was done. If we focus on the positives here, we’re looking for a candidate who can talk knowledgeably about code, can decipher things quickly and can apply existing concepts to new code bases quickly.
However, these code tests are so far away from the reality of how we develop software now, with the wealth of online articles, blogs, examples, StackOverflow and even AI tools like CoPilot to help us, are we sure this is the value we seek? The outcome we need is to understand whether someone has the technical capabilities to do the job and fundamental knowledge that will allow them to grow within our organisation.
One of the things so often quoted by recruiters when discussing roles is that ‘you either need to pay the most, or move the fastest’. Our goal is to have a team of the right people who will fit culturally and be driven to learn, grow, and succeed. Multi-stage interviews are largely designed around pitting potential candidates against each other, comparing them, and landing on the one of the cohort that is the best of all of them. How many times have you been through this process to find that none were suitable? Or indeed that two were so good that you found a way to hire both? If you remove the anxiety that the next CV could be even better, or the next candidate could be incredible, then you don’t lose sight of how good the person you’re interviewing for the role is right now. I suppose the other solution could just be to pay more?
So what have we done in our interview process?
- Removed code tests across the board. Do I want to take hours of someone’s own time to demonstrate capabilities that we can assess from a good CV and some pointed technical questions? Not at all. Being able to respond quickly and interview interesting people with no delay is a huge plus.
- Don’t ask what the candidate knows about the company. We introduce the candidate to our company, the culture, what we do and how we do it. We also discuss some of the things they will be working on, the stack, how modern it is and what the opportunities to learn and grow will be. Typically we’re only going to keep staff for 2–3 years, so we want to be in a position where if people are leaving it’s for an exciting new opportunity that we can all celebrate.
- Single stage, where possible, and take a decision very quickly (ideally the same day). Agility is key in the market, if we find someone talented, driven and aligned to your culture, then why should we wait for someone that could be ‘even better’. We invite people to interview typically either one at a time or in very small cohorts to allow us to offer quickly when we find the right fit.
- We focus our questions on getting to know the person, how they operate, how they learn, and how they’ve grown to get to this point. If someone doesn’t excel in technical questions, but has demonstrated a capability to learn and grow quickly, then they will probably succeed in our teams.
- Technical questions should be pointed, but relevant. None of this Google logic problem nonsense. If we were developing cutting edge data algorithms, then sure, this would be very important, but very few organisations need this level of logician. On the other side of the coin, we want to give people who know their stuff the opportunity to shine.
- Intentionally bring the team banter into the interview space. Our goal is to relax the candidate but also allow people to be more honest and open with us in the interview. We want to know really how someone will fit within our teams, not just how someone performs ‘under pressure’.
Overall we’ve worked hard to create a people-first culture (or ‘clan culture’ we learned we’d accidentally created almost word for word) and our interview process has shifted to enforce that. We do have some good stats to back this up too, 100% of people that were offered, accepted. We also have an average time to fill a role that is measured in weeks which given our salaries are certainly around a very middle benchmark we stand by as a great metric in the industry.
