The Technical Interview

15 Feb 2009

I love the interview process…no, no, no, not the part where you are applying for a job, no, heavens no.  I love being on the other side of the table performing the interview and asking the questions.  Being interviewed?  Another topic for another time.

During your career, be it in software or otherwise, you will likely find yourself in a position to interview new people to join your company.  This task is not one to be taken lightly, good talent is hard to find, and making a hiring mistake can be very difficult to correct.  So what is one to do?

I found myself in this situation a few years back.  My team was growing, and we had the opportunity to hire a couple co-op students from the local university.  I had sat in on a few technical interviews before for other co-op students where I was more an observer than participant.  A couple of times during those early interviews when I was asked if I had anything to ask the applicant, I would usually respond with a, “nope.”  At that time I didn’t bring too much to the table.

This time around not only did I want to participate, but I wanted to run the interviews.

What follows is my typical interview “script”.  I call it a script because everyone involved plays a role, including the candidate.  The script metaphor works because we need to follow the same basic outline from interview to interview in order to accurately compare candidates.  My team and I have run this script around 30-40 times as of this post, and so far we have had great results in who we have hired.  Of course, your mileage may vary.

Some may ask, “if you are providing your script, and I interview for you, won’t that be like cheating?”

Yes, yes it would.  If you plan to ever interview with me in whatever company I’m working for in the future and I’m sitting on the other side of the table from you I’ll know you’ve read this post.  You’ll know that I know, and I’ll know that you know that I know.  It won’t be pretty; the tension in the air will be palatable.  We won’t even get to the first question before I jump up on the table and scream “I know!” and you’ll respond, “I’m sorry!” and the weeping will begin.

Actually have it, bring in a copy of this post, I’m not too worried.  This isn’t like having the answers to the SAT.  Nerves, fear, and plain old doubt can cloud an interview…anyone who knows what is coming may be a little more relaxed and give a clearer picture of what they would be like on a regular basis.

The Framework

I hate re-inventing the wheel.  I know others before me have interviewed people for technical positions with great success, ::see Microsoft and Apple:: so there must be lots of material on the web to say how they do it?

There is.

Most of it is outdated.

Most of it is directed at the interviewee.

Except one.

::I’m sure there are others, but if I said, ‘lots and lots of others,’ it would lose the dramatic effect.::

I have taken Joel’s, The Guerrilla Guide to Interviewing, and tweaked it here and there.  Take a minute and read version 3.0, which I linked to above before going on.

All read up?  Good.  Let’s begin.

Hiring Criteria

Simple:

• Smart
• Gets Things Done
• Passionate

Joel covers ‘smart’ and ‘gets things done’ at length in his guide, I won’t repeat them here.  However, I don’t think he calls out how much of a role passion plays in hiring an engineer.  I’ll cover more on passion down below.

The Team

I am an avid believer in having multiple people in the room for interviews; not only does this save time, but everyone will hear the same exact thing.  This is key when comparing notes about the candidate afterwards.  I keep three people on my team, with three different roles.

The Lead - The Lead runs the show.  They are the ones who ask most of the questions, they take care of meeting the candidate at the door, and pacing the interview.

Number 2 - Number 2 drives smaller sections of the interview, often focusing on schooling, prior projects, and prior jobs.  As the interview gets going The Lead and Number 2 will often tag team back and forth on the different sections of the interview.  Having a Number 2 in the room is a great stress relief to The Lead as they can chime in with clarifying questions if The Lead misses something and give The Lead a chance to gather their notes and not talk the entire time.  Where The Lead runs the overall structure of the interview, the Number 2 fills in with a supporting role.

The Jerk - The Jerk plays a key role during the ‘writing code’ section of the interview.  Their job: challenge the candidate and see how they react to adversity during the interview.  The Jerk is charged with asking the pointed, hard questions during the coding phase of the interview.

Typically, I like to have everyone on the interview team be full time developers who buy into the interview process, i.e. we have all discussed the format of the interview beforehand and we all know our roles.  There is nothing worse than getting into an interview and appearing like no one knows what they are supposed to do next.

The Time of the Interview

Have The Lead meet the candidate in the foyer/reception area/whatever you have available and walk them back to the conference room.  Typically during the walk I try to make some small talk, “How’s the weather outside”, etc.  The goal is to try to get the candidate as relaxed as possible given the circumstances.  The last thing you should be doing is walking silently with a look of contempt on your face.  This person may become your new co-worker; try to make them feel welcomed to your company.

The Introduction

Introduce everyone on the team and thank the candidate for coming in today.  I like to layout the format of the interview so there aren’t any surprises.  A typical format will be:

• Talk a little bit about yourself, your passions.
• Dive into past work experiences, or for co-ops classes and projects
• The whiteboard question(s)
• Any questions for us the interviewers
• Talk about the company

A couple of points about the format:

• We never say how many questions there will be at the whiteboard.  Ever.  Normally we have a very easy one, and a very hard one.  There is no point going into the hard question if the candidate cannot pass the easy question.
• Always close by talking about the company and how great it is to work there.  I don't care if this candidate thinks the CD-ROM drive is a place to hold your coffee cup and you know you are never going to see them again-you sell your company!  This will likely be the last thing the candidate will remember as they leave your office, and I would like to leave them with the thought of, “Wow, that was a tough interview.  I hope I did well because I would love to work there.”  At least if they do not get an offer letter they can tell their friends how cool your place is to work and not create any ill will.

Talk a Little Bit About Yourself

The key, get the candidate to relax, get them talking about something they are experts on, themselves.  This is a great place to ask the softball questions, such as:

• Where do you see yourself in five years?  It doesn't have to be work related.
• If you could get out of bed every morning and be living your dream job what would you be doing?
• What do you read on a daily/weekly basis to keep up to date in our industry?

All of these questions are those horrible open-ended type questions that don’t have any real answer, but they serve a key purpose.  Get the candidate talking and try to get them to not feel as stressed about the interview.  Out of this section you will likely learn what they are passionate about, if anything, if they have any vision for the future, and what they do to hone their craft.

There is nothing worse than having someone come in and go, “I don’t know where I want to be in five years.”  Really?  No idea?  None?  Living on a beach, write a couple of books, anything at all would suffice for this question.  I’m looking for a spark of personality, what are your interests, are you passionate about anything?

Passion is one key indicator I have found when hiring engineers.  Show me someone who has zero passion for anything and I’ll show you an unproductive engineer.  Show me a guy who is passionate about his family and I’ll show you a person who writes solid, robust code so he can leave at the end of the day to spend time with his family, and not be called in on the weekend to fix sloppy code.

Asking about their dream job again attacks their passion.  Do they love writing LabVIEW VI’s that talk to hardware or are they hardcore Ruby on Rails developers at heart.  These are key things to know if you are trying to hire a SQL DBA.

Lastly, our world is changing so quickly, we need to stay on top of what is going on out there if we hope to be viable in this industry 10, 20, 30 years down the road.  Learning if your candidate has a passion for their craft, and a desire to hone and refine it, for me, is a key hiring point.  If you are going to stop learning the second you see that offer letter I’m not interested.

Work / Project Experience

I like to have Number 2 take the lead here and drive this section.  During the intro and the open ended questions section he has had plenty of time to review the resume, listen to the first few answers, and craft a few questions based on those answers about the candidate’s past roles, and in the case of co-ops, classes and project experiences.  Again, this section is fairly open ended with the goal to get the candidate to talk about a subject they know the most about, themselves.

Hopefully the first two sections will give you an insight into the candidate, their personality, what they have done in their past jobs, and their goals for the future.  This is the warm and fuzzy feeling you might have on a first date as you sit down to get to know someone.  However, once this section is over the real fun begins.

The Whiteboard

The whiteboard is single handedly the scariest piece of equipment ever invented for a job interview.  It’s big, it’s blank, and a whole mess of code is going to be written on it.  As The Lead, it’s your job to relax the candidate before they get up to the whiteboard.  I will often say:

“Ok, lets get you up to the whiteboard for a coding question.  I know you are not at your desk with your favorite compiler; the whiteboard compiler is very forgiving.  It doesn’t care about semi-colons or perfect curly brace placement.  “

“We also know you don’t have Google at your fingertips in here.  For this interview, we’ll be your Google.  If you have any questions you would normally ask Google, ask us.”

“We care about how you are thinking about the problem at hand, we want to hear your process of how you are going to solve the question.”

This preamble sets the stage for the whiteboard in that:

• I don't care what the code looks like, as long as the candidate can explain it and it resembles some sort of programming language.  Writing out sentences 'read in input from user' will not work, I need to see how you would go about doing that, but I don't care if you miss a semi-colon in the process.
• I expect people to know a fair amount about the position they are applying for, but if something escapes them that they might use Google to look up I don't want that to stall the interview.

“The question: Given three integers write a function that will tell me if they form a right triangle.”

::Anyone who has read anything I’ve put out in the past couple of years should recognize this question as one I have used a bunch of times for many, many articles, examples, and even a code challenge for the Viewpoint eNewsletter.::

Simple, yes?

Actually for such a simple question we have seen dozens of methods to solving it.  And here is the key, by this point, we, the interview team, know which ones work and which ones don’t.  We know the caveats of each solution, and if you walk into my interview knowing how to solve this question and whip off an answer in five seconds, we will still have much to discuss.

This question is the heart of the interview.  As simple as it may seem watching someone solve it tells you a lot about how this person will work out if they are hired.  What am I looking for?

• Questions.  The way in which the question is asked is incomplete.  What do the sides represent?  Are they lengths of the sides?  Coordinates in a plane?  Can the candidate ask for clarification in a situation where all of the information isn't initially given?
• Ability to ask for help.  Assume they have asked the question, "What do the sides represent?" and you further go onto explain they are the lengths of the sides of the triangle.  Maybe the candidate doesn't remember the Pythagorean theorem.  I like to see the candidate ask for help.  At least if they are spinning their wheels for a minute or two and then 'come up for air' and ask for help it is better than dead silence for the next 20 minutes.  Likely we have all encountered areas where we needed to ask for help, I'm looking for people who know their limitations and are not afraid to ask.
• Coach-ability.  This is huge.  If you provide direction how well does the candidate take it?  Do they take it in stride?  Do they fight you on it?  Their reaction based on a suggestion will provide loads of insight into what it might be like to work with the candidate on a daily basis.
• Ability to take criticism.

To this point I have been silent on the subject of The Jerk.  During the whiteboard section of the interview is where The Jerk shines.  Likely the candidate will pound out an answer to the question above, its time for The Jerk to put the code through its paces.

First question from The Jerk: “Are you happy with the solution?”

Now to be clear, The Jerk shouldn’t be ‘a jerk’ when posing these questions.  However, ‘technical hard-ass’ might be more fitting.  The Jerk asks the tough questions, The Jerk is curt and to the point…not quite the ‘good cop, bad cop routine’, but something close.  What this does is allow The Lead and Number 2 to observe what happens when the candidate encounters an adversarial character.  How will they react?  Do they flip out yell expletives and storm out of the room?  Or, can they handle the pressure?

The Jerk also nails the candidate on other questions that are often not thought about:

• What happens if I run 0, 5, 5 through the application?
• What about -3, -4, -5?
• What about max int?

Or if the candidate solved the problem perfectly there is always:

“There is something wrong with your solution.”

How the candidate responds to this will likely make or break the interview.

• Fits of screaming and crying...probably a no hire
• Diplomatically explains to The Jerk that no, the function is correct and here is why...hire that person on the spot.

If someone in a situation like an interview can diplomatically explain why The Jerk is wrong and they are correct, in such a situation where there is a clear imbalance of power and they don’t resort to name calling, this is a very clear sign into how this person is going to work out.

If for some reason the candidate doesn’t grasp what a right triangle is, or doesn’t take direction, or sets the table on fire while doing the whiteboard question, this is where we would have them sit back down and wrap up the interview.  This is why we never say how many questions will be done at the whiteboard.

Our second question, “Build me a function that calculates n!”.

Again, allow The Jerk to drive the questioning, asking why they did their answer iteratively vs. recursively.  If the candidate nails the first question often times this question is used after the interview to separate the good from the best.

Any Questions for Us?

After the question(s) at the whiteboard we start to bring the interview to a close.  The Lead normally asks, “Do you have any questions for us?”  At this point one would hope the candidate has a few questions, what do you do here, what is it like to work here, etc, etc.  Open up and share as much as you can with the candidate without violating terms/agreements/etc.  These questions often roll into:

Talk About the Company

“Always be closing” or rather “Always be selling your company”…what you are about to relay to the candidate will stick with them as they walk out the door.  Does your company do really cool things?  Let them know!  Do you have monthly company meetings where food is provided?  Let them know!  Does everyone have an office?  Let them know!  Do you work on really cool cutting edge projects?  Let them know!

I would like to have every candidate walk out the doors going, “Wow, cool company.  Even if I don’t get an offer there I’m going to tell my friends how tough an interview it was, but how much fun it would have been to work there.”

The last thing you want to do is create any ill will on the part of the candidate as they leave to tell their friends and peers.  In such an interconnected world why spread a seed of ill will for no good reason other than an interview that didn’t result in a job offer?

The Walk

Thank the candidate for coming in when there are no more questions to be asked and walk them back to where you picked them up.  Give them a timeline of when you expect to make your decision, hand them a business card so they can ask any follow up questions if they think of any and bid them a good day.

Walk back to the conference room for the final vote.

The Final Vote

The final vote is simple; it’s a ‘hire’, ‘no hire’ vote.  Snap decision, and there is no ‘maybe’.  One ‘no hire’ in the group results in a ‘no hire’ result.  Each one of you had a different vantage point for the interview, and if you all can’t agree to hire the candidate they are likely not the best person for the job.  As I said, there is no ‘maybe’, or ‘maybe, but not for doing X’.  What if they are hired for another function, and that function goes away and the only thing for them to do is ‘do X’, now you’ve hired the wrong person, and you are stuck with them.

Where the ‘hire’, ‘no hire’ gets tricky is if you have three candidates who you would all hire, but you only have one position.  Right after the interview it is best to rank everyone for the position and keep the ranking updated after every interview.  At the end of the interview process you will have a nice list of candidates that you can then make offers to, and if one of them refuses you already know who you are going to hire next.

In Closing

There are a few items in technical interviews I hate with a passion.  Avoid adding these to your interviews at all cost:

• Brainteasers – An example - given 9 dots on a piece of paper connect them all with four straight lines.  Brainteasers are not good interview questions, the only thing they will tell you if someone gets one right is that they are good at brainteasers, they don’t tell you if they are good programmers.
• Fact questions - Any question that normally would be looked up by any given programmer isn't a great question.  Do you care if you candidate has memorized a bunch of useless facts about QBASIC and now they can regurgitate them?  I don't.
• Illegal questions - I am not a lawyer, but I'm sure your HR department can brief you on all the questions you cannot ask during an interview.  Understand these types of questions before conducting an interview.  I'm talking race, sex, religion, all the major mostly common sense items most people wouldn't ask.  Again, I am not a lawyer, so check with your HR department before proceeding.

I hope that using these guidelines will help you conduct your next technical interview and find a person who is smart, gets things done, but has passion for their job and career.