As one of the "elder statesmen" at MojoTech, I interview a lot of engineers. Over the years, I've come to see this more and more as a discipline in itself.
I've found that the craft of conversational interviews, like many inexact sciences, consists of navigating tensions between opposing forces. It's all about finding the right balance.
Here are a few pairs of conflicting goals and some advice about how to make the tensions between them work for you.
Put your applicant at ease.
Your candidates are applying for software engineering positions. The ability to keep one's cool in a high-pressure situation (like a job interview), while an advantage in any walk of life, is not a prerequisite to being a great software engineer. Unlike in other fields (for example, espionage, presumably), there tends to be very little "performance" involved in programming. Performance-oriented jobs consist primarily of finding acceptable solutions in trying circumstances; in contrast, software engineering, at its most fulfilling, is much more about finding amazing solutions given ideal circumstances.
For that reason, there is no point in making your candidates feel like they are being interrogated. In fact, you'll get a much better picture of your candidate's capabilities as a software engineer if you make him or her as comfortable as possible during the interview.
Be friendly. Be "on their side". Ask your questions casually, as if it were just an everyday conversation and you were asking for advice. Unless your workplace is very unpleasant, you want to see your candidate at his or her best, not under the gun.
An aside about this: I've had some great working relationships with engineers who were also socially awkward. If you meet a candidate who is honestly having a tough time maintaining a calm and collected sheen, try to see past it. Work a little extra to put such a person at ease — you'll both enjoy the experience more, and you might just discover your next star engineer.
...but challenge your applicant.
You want your candidate to feel comfortable, but that isn't actually the goal of the interview. You need to discover the limits of your candidate's knowledge and capabilities.
Especially on open-ended questions, keep pushing it a little further as you explore the problem scenario you are presenting. If the candidate handles the basics easily, make it incrementally harder by adding wrinkles into the requirements.
If you're talking to someone exceptional, who is knocking all of your questions out of the park without a second thought, look for opportunities to ask far-reaching questions that you don't even know the answer to yourself. This can make the question into more of bidirectional conversation, where both participants muse on an open-ended topic. Since this is exactly how you'll interact with exceptional engineers when you do hire them, you might as well take your chance to obtain a sneak preview.
Focus on gathering information rather than on achieving judgement.
Oftentimes, something that someone says early in an interview will produce an emotional reaction in you. The reaction can be either positive ("oh wow, this person writes blog posts about functional theory, maybe she can help us adopt Clojure within the organization!") or negative ("this person just made a totally indefensible assertion about the performance capabilities of language x..."). Either way, your heart is made up.
Remember that the quick judgement at which you have arrived is not very valuable. It's more important to continue to accumulate as much information and understanding as possible in the time you have. That way, you and others can think about the candidate at your leisure, with the benefit of more context.
If you arrive at an early judgement, keep pressing on. Try not to let your first impression color the rest of the conversation. Don't ease up on questions because you like someone, and don't try to trap someone because you don't like him or her. After all, you haven't known the person long enough to have anything more than a first impression.
...but admit that you can never be totally objective.
Although a zen-like, emotion-free, totally objective observation of your candidate is a worthy ideal, you must realize that you can never achieve this. Meeting a new person is always going to be a bit of an unpredictable adventure, capable of throwing your perspective for a loop.
It's not only the candidates themselves that tint your perceptions of various interviews, it's the whole situation surrounding each interview. It's what kind of mood you were in, how well your engineering work was going before you had to take a timeout to do the interview, maybe even what you had for lunch. I've certainly noticed that I tend to enjoy candidates much less when I'm stuck on a brain-burning technical problem at the time.
You will have different reactions to different candidates, and these reactions will color the way you see the rest of the conversations. You can't help it! So, instead of attempting to imagine what you would say about a candidate if you were totally objective, the best thing to do is to try to recognize your own reactions and to keep them in mind when you describe or reflect on how the interview went. Emotions are like enemies... keep them close to you so you know what they are doing!
Build up a "standard library" of questions that you ask many applicants.
Your ability to compare candidates to each other will improve dramatically if you ask each of them many of the same questions. You reflect on the answers each candidate gave, and on the way they arrived at those answers, to glean insights into the experiences and thought patterns of each candidate.
For this reason, it behooves you to build up a "library" of questions and exercises that you like to ask a lot.
For questions that have single correct answers, try to zero in on the ones that many candidates get right, and many other candidates get wrong. For example, I often ask candidates with JavaScript experience, "Most languages have the concept of private functions, which are intended to prevent the outside world from being able to call the function. How would you accomplish this in JavaScript?".
I'd say that about half of candidates with significant front-end experience are able to answer this. If they do get it right, it shows that they've likely spent time trying to discover the limits of JavaScript's capabilities, as opposed to simply hacking pages together as quickly as possible, or editing existing code in order to fix surface bugs.
With enough questions that stump somewhere in the neighborhood of half of the candidates, you can quickly reach a meaningful basis for comparison between them.
Make sure your "standard library" also includes some open-ended exercises, where you invite your candidates to "think out loud", and where you aren't looking for a single specific answer. The idea is that you want to give exceptional candidates a chance to surprise you. I tend to remember the really good answers to my standard data modeling exercise, and the "best answer" to it in my own mind has evolved several times over the years as various candidates have come up with better and better ideas during our interviews.
...but don't stick with the same exact script.
You aren't a robot. There are many good reasons to interject variations into your standard library.
First of all, this is the way that you can slowly improve your questions. My own standard library continues to get just a little bit better as I continually experiment. By observing the responses you get, you can decide whether a given question continues to make the cut, or whether you want to tweak it a little bit. Each time you talk to someone, try at least a couple of small variations.
Second, some questions just aren't worth asking some people. Remember, you are trying to learn a lot in a very limited amount of time. For example, if a candidate has no experience with design implementation, don't run him or her through your entire canned gauntlet of CSS quiz questions, just fast forward and spend your time learning more about what he or she has done.
Third, you can discover treasures by following worthwhile tangents when they appear. You have the advantage of being a person rather than an algorithm. Thus, you have the ability to recognize strengths and weaknesses that you might not have even known you were looking for! If the candidate starts talking about something interesting that you hadn't considered, see where the flow of that conversation leads, even if it isn't helping you get through your list of canned questions.
Take interviewing seriously.
Giving interviews probably isn't the number one item in your job description, and it may not figure prominently in the way you see yourself. Nevertheless, if you're going to be doing a lot of interviewing, you should try to get really good at it. Improving your skill at interviewing will help both you and your organization in concrete ways. In other words, Your performance actually matters!
With practice, you can learn to learn more in the time you have. Your ability to make incisive observations will ensure that you will be surrounded with people that you admire.
You will also waste less time pursuing unproductive conversations during interviews. You will learn to gracefully move things along so that you touch on all of the topics you need to investigate, without feeling like a game show host (simply moving from one topic to the next without regard to the flow of conversation). This lets you get back to all of those other things that you wanted to do with your day — like programming!
After each interview, reflect back not only on what you think of the applicant but also on how it went in terms of how much you were able to learn and how quickly. Was there anything you wanted to ask, but didn't get around to? Did you spin your wheels too long on an exercise that wasn't going anywhere for this applicant? Did you say something that soured the mood? Make a note of these things and resolve to do a little bit better next time.
...but not too seriously!
No matter how smoothly an interview goes, your picture at the end of the conversation will never be so clear that you should hire solely on that basis. When hiring an engineer, always do at least one interactive coding exercise in addition to a "talking interview".
Some people are really good at talking, and even better at figuring out what other people want to hear. All else being equal, this is a positive quality, but make sure that such a person can really get things done with a code editor. Suffice it to say that I have often been extremely surprised at the level of coding skill revealed when actually working with someone — even after talking about it for an hour or so beforehand.
You want to spend a couple of hours coding with someone in order to really let them get into the groove, so don't try to squeeze it into the same time slot with the technical interview. Schedule the coding exercise separately. You can use the conversation as a "gatekeeper", to decide whether to go forward with the coding exercise or not — but regardless of ordering, the increased breadth of topics covered in a conversational interview is always useful to augment what is learned during coding.
Conclusion
There are, of course, other goals and concerns, and other balances to be found. I hope that, by thinking about these tensions as an interesting puzzle to be solved, you eventually come to enjoy conducting technical interviews as much as I do!
P.S. Want to see our interviewing practices in person? MojoTech is always looking for its next great hire. https://www.mojotech.com/jobs/.