Interviewing software engineers
Interviewing basics
When interviewing software engineers, you typically want to answer one simple question: Will they be a good fit for my team? Therefore, your interviewing process should focus on answering this question. Obviously both sides try to answer the same question and so you also want to sell yourself as a great place to work.
Over the last years I was interviewing a lot of software engineers, mostly Android developers, for different positions. At first I always introduce myself and the company, explaining what we do and why it would be great to work with us. HR managers often like to ask the candidate why he or she applied to our company. I try to avoid these type of questions. If you are neither Google, nor Facebook nor Apple, chances are candidates didn’t choose you because of your great products, the famous community relations or because they love to work on the cutting edge. What you should do is to talk about their CV and let them explain some topics in detail.
Let them code
The most important part of an interview is a live coding session. Many engineers don’t like being tasked with a coding challenge. I even had Freelancers refusing to work on it. While I understand the negative bias, in my opinion it is still the best way to evaluate candidates. Interviewing is hard and hiring the wrong people is fatal to your business.
The result of any interview heavily depends on personal taste. and sympathy. This is especially true when you are looking for a skill set you are not 100% familiar with. Engineers with deep knowledge like to see multiple problems in every situation. Others might not know the same limits. This is called the Dunning-Kruger effect.
To prevent this from happening, you have to see applicants do what they are supposed to do: Let them write code. Now at least you have something to compare, not only how many buzz words they have memorized. Keep in mind, you will never be sure to have a top performer just by interviewing. But you can consistently wipe out everyone who just can’t code. Depending on how hard your tasks are and where you set your bar, you will also wipe out applicants who are nervous, get confused with your task or just have a bad day. This is not good. But it is still better than hiring the wrong people.
To reduce applicants nervousness at the beginning, I try to let them feel at home as much as possible. They can use their own laptop, their own IDE and language. And of course I will offer my cooperation in solving the task, by answering questions and telling when they are going the wrong direction.
You will be surprised by how much more you can see than just the resulting source code. It starts with the approach they take. Do they have an idea of the algorithm before starting? Do they ask clarifying questions? Then there is the coding itself. Will they use the IDE like Notepad or do they navigate the code quickly using all famous shortcuts? How to they verify and test their program? All this is more important than the actual solution.
Preparation
Most important part of the preparation is to understand how hard your task is. Only then can you evaluate others based on it. That means you (or one of your engineers) have to solve it in exactly the same setup and time.
A great source of tasks is ProjectEuler. It starts with FizzBuzz and gets slightly more complicated over time. Another great collection of interviewing tasks with solutions is rosettacode. It is tempting to use challenges from there, but don’t forget to solve them before reading the solution.
Final words
Finding the right engineers for your team is hard. It is tempting to cut corners when you have to staff your team quickly. However, hiring the wrong person is much worse. Not only will you pay for an unproductive developer, but you can severely damage the productivity of others. Talking about NNPP. You could part ways with a non performer after a few months, but at that point it becomes much harder. He or she might have become good friends with the rest of the team including yourself. Firing someone has a great impact on the team morale and you should really limit it to exceptional cases.
On the other hand, if you feel confident about a candidate, then make it your first priority to close the deal. Send updates about everything, telling when to expect the next step. It is not hard to stand out from other companies (at least where I come from) nowadays. A positive feedback goes a long way for making someone want to work for you.