The art of technical interviews is an old one, but not always a well practised one. There are always a few variables and a lot of theories. Should they be long? Many ? How about spread out? Or all in one day? Recently, we have had to conduct a few and I think I have learnt a few things from them. When I combine these ones with the ones I have given in the past, I have come to the following conclusions from the point of view of an interviewer:
- It should be hard to pass an interview. You are not there to make the interview easy. Making the interviewee comfortable and making the interview easy are not the same thing, and too often the difference is glossed over. You are not there to be friends, and you are not there to be his or her mentor. Be nice, but blunt and if you spot a weakness in understanding, zero in and don’t let go till you have identified why that weakness is there.
- Don’t assume anything. Don’t assume they know what a source control is! Do not assume they understand the difference between static and dynamic types! Do not assume they understand what your business model is! Ask ask and then ask some more.
- Codility does not tell you how the person thinks. It tells you whether they can solve a programming puzzle quickly. You want to find out how a person thinks and whether there is decent base beneath the layers of programming on top. What you want is a person who can think for himself, learn and build on his understanding. What you do not want is a code monkey who likes typing characters. So create a simple coding test by all means, but rather than using codility, put it in a git repository which you then mail to them. Get them to solve the problem, test it and send it back to you in a day or two. Then you read the commit logs. That will tell you more about how a person thinks than codility. It also has the added benefit of demonstrating to you whatever it is you wanted from Codility.
- When you get the person into your office, make sure they spend an hour pairing with an experienced developer on an existing feature that is being developed. This should be enough to show whether the person has had some pairing experience; whether the person can navigate while someone else is typing and point out errors; whether the person commits often, tests regularly etc etc. Most of all, it will tell you whether the person stops his pair to ask something which he does not understand.
- Make sure that the person is a cultural fit. This is the most easy thing to stuff up as it is the hardest to check in a short amount of time. Which is why most companies should have probationary periods for new comers.
In the end, the worst case scenario is that the person you hired turned out to not be what you wanted and you will have to let them go! The only caveat at that point is that if you and the person are not a good match, make sure that it is not a surprise to that person, otherwise it is fair on neither of you.
. This has made me realise that software development, and deployment, is amazingly rewarding when done with awesome people. 
