The series:
Interviewing Developers: triggers, part III
Of course the key point about the interview is which questions to ask. In the beginning my attempts to come up with relevant and challenging ones were very painful. I struggled a lot and jumped from one topic to the other always being sure that I miss something important. However, when we speak of technical knowledge and skills, it turns out that the most fruitful questions to ask are quite simple. For example, I usually focus on basic textbook-level Object-Oriented Programming and C# topics. Keeping things simple you may quickly see that the candidate demonstrates only shallow knowledge and, which is more important, inability to explain technical stuff in plain and simple words with reasonable examples. Such an outcome means an end to an interview - if a person can't discuss basics they likely won't be able to reason clearly about the complex stuff that your team deals with. On the other side, the potential employee may show great ability to articulate the subject and its practical implications in such a way that you see the experience behind their words and learn quickly that you're not wasting time with them. In this case you may proceed with more complex problems, but this is rarely necessary unless you're looking for some very specific skills.
Simple practice exercise have the same advantages and provide enough insight into the way the candidate reasons and knows his tools. Even the easiest programming problems usually give enough room for mistakes and bugs and allow to get a good evaluation of a programmer's skills. It may be a good idea to challenge the candidate with some really serious coding puzzle, but you definitely don't want to start with that. Because the technical interview is to large extent about assessing candidate's abilities to analyze problems and explain solutions we also always offer a logic problem. Being an exercise suitable for the 5th grade or something like that, it still tells a lot about the way a person would analyze the situation and draw conclusions, not to speak of their explanation skills.
Still, you don't want you candidates to spend the whole interview fighting boolean algebra, so you will need some reasonable practice problems. One good place to look for these is the domain that your software models. It is usually enough to spend a couple minutes thinking of what you do on duty to come up with a couple great yet moderately difficult problems. Just keep in mind that these should not require too much context or be too large, so that you can stick them into the timeframe of the interview. For instance, my list of practice problems includes an SQL question that I faced when developing one of our features - it is a pretty real-life yet very simple and thought provoking problem.
While technical questions usually take the most of my interview time, I also dig into the personal experience and attitude. Our HR talks to every candidate before I get to them, but I still find it very important to discuss the potential employee's background and soft skills. Anyway, I have to check whether the person will fit into the team and will be able and willing to do a good job. In additional to usual questions on their duties on the last job I love to ask for a couple achievements, which they feel proud of - people are frequently taken aback and start to dig for their best, which makes the answer very valuable. In addition to unveiling the candidate's experience, such questions allow to assess personal traits. For instance, I can learn a lot about the person's involvement into their job - good candidate would usually be able and happy to speak about their duties and achievements, explain them in depth and do it in such a way that I will get interested even with little context. The way a candidate speaks of his tasks and situation in the office also tells a lot about their attitude and motivation and may uncover teamwork-related risks.
To ensure that both technical and non-technical questions are informative and easy to handle I have them written out carefully and usually ask the same ones, mostly in the same order. Even though this might not seem important, it plays a great role as it prevents hesitation and fears of forgetting something crucial. Additionally, if I follow more or less the same path through the interview, it becomes easier to utilize past experience to spot patterns in the way candidates respond and dive deeper into certain subjects. Finally, this helps to compare candidates to each other, which is quite hard otherwise.
Another aspect of conducting interview, that I find very important, is to be kind. When I am open, attentive and helpful I can definitely learn more about a person than if I demonstrate them my superiority or show that I want to get away as fast as possible. A candidate in an interview usually puts enough emotional pressure on themselves, so there is no need to introduce any artificial stress. This helps not only throughout the interview, but after it as well: I may decide to make an offer and in this case I'd better have the person willing to work with me - not being frightened to death.
Thanks to all these tiny how-to's I got much better at doing interviews, but I still face certain issues. In particular, sometimes I pay too much attention to the person's communication skills. While their ability to speak and listen means a lot and helps both integrate them into the team and teach whatever is important to our business, there are many valuable hires in the world of programming who might be a bit tough to talk to. I also tend to try too hard to find pros about the candidate - in particular when it is already obvious that I won't hire or recommend them. I constantly fight this trait, but it requires a degree of discipline to cut off all of my willingness to understand the person better and say a firm "no" quickly. One inevitable consequence is that my interviews take a lot of time, but at least I know how to shorten them.
Still, the most unpleasant problem about interviewing and hiring may come in the process of making a hiring decision. It can be really tough when I think good of the candidate, but at the same time have a feeling that something's wrong with them. In most cases such sensation means no offer - even though I can't explain what bothers me, the hesitation is a good indicator of hidden problems, which may surface later. In spite of knowing the general rule "doubt = no hire", I sometimes have a hard time making the "no" decision and need to work on that too.
Despite these issues, the simple practices outlined above, like having a regular question list and focusing on candidates' reasoning abilities allowed me to become more efficient and confident on the interviewing side. In particular, this helped to hire several great team-members who have already delivered great results and became valuable employees. Overall, interviewing is not too difficult a process, but it takes some time to get it right. I'm still actively working on improving in this area, so please share your insights and how-to's!
