How to conduct a great IT job interview
If you own a software company or work there in HR, it is your goal to hire the best engineers for your business. So you certainly don’t want to mess up the recruitment process. As someone who’s in the industry for two decades (sitting on both sides of the table), I would like to share a few points about how to make an interview a positive and insightful experience for everyone.
Don’t encourage the candidate to ask questions, if you’re not qualified or willing to answer them. It’s really frustrating to talk to someone who’s encouraging you to ask questions and every single time you get answers like: “Sorry, I can not answer that – I do not know the product in detail” or “We can answer that as soon as you start working here”. Do you expect your best candidates to ask self-answering questions? Great candidates are evaluating you, your company, and whether they really want to work for you.
Don’t pretend you’re doing the candidate a favour
If you really want the best engineers, say so (and pay them well). Don’t give the impression that the candidate might be at best a tiny addition to your already great team of engineers. Would you like to spend more time with a company, who doesn’t really need you than with your best friends and family? Full-time jobs are like that.
Good engineers are usually not impressed by people who try to sell them something. They’re used to evaluate software tools and libraries on a daily basis without being dazzled by fancy marketing brochures. If your company built an awesome technology stack or has other unique offerings, say so – but provide credible evidence without being asked. It’s not credible, if you say you built the highest quality application framework and at the same time, your application is slow or contains obvious bugs. Engineers can notice those smells, which sometimes indicate deeper problems within the software or the organization.
Make the interview a conversation, not an interrogation
Nothing shows less respect towards an obviously experienced candidate than being forced to answer a huge list of “standard technical questions”. That might be alright for somebody coming straight from university, but even those candidates usually have a unique story to tell, if you let them. Just asking standard questions might also expose a severe lack of preparation on your side. How would you feel, if you built several database libraries and wrote magazine articles covering advanced SQL topics – and then being asked how a simple SQL join works? If an experienced database engineer was sitting in front of me, I would take the chance and start a conversation about actual issues we have to solve on the production servers. Maybe the candidate can provide a solution for free? Who knows.
Treat your candidates as unique individuals and find their strengths. If you do, they’ll open up, you can have a great conversation and you might even be able to learn from them. Don’t desperately try to find a question they can not answer. Don’t play the “I am smarter than you” game. Do you really want to hire an intimidated engineer based on “knowing” all weaknesses?
No good and focused engineer knows all the books, APIs and software libraries out there. Some of the best use intuitive problem-solving strategies, which they can not describe in words.
Take some time to prepare yourself
Before going into an interview, carefully read the candidates resume, thoroughly check her/his code on GitHub, read a few blog posts and maybe have a short chat with her/his references, so that you already got a first impression and something to start a conversation with.
The candidate will love you for that!