A little while ago, someone asked me what I looked for when hiring an engineer. While so far I’m batting .400, having hired some of the best and brightest engineering talent into my teams, this got me thinking about what drives my decisions to bring someone in vs. not.
I will talk to anyone
Where my peers look at previous work history, and only look at folks that have worked at Amazon, or Google, but not Microsoft, I’ll talk with anyone, except maybe Microsoft folks (kidding of course). I also don’t care if you’re fresh out of school, or which school for that matter. Yes, a graduate degree from a top school helps you get your foot in the door, but not much. In fact, from my experience, a graduate degree from MIT or any other school is a poor predictor of employee performance. I’m not saying that the NLP degree you just spent the last three years getting meant nothing. I’m sure you learned a lot. It just doesn’t tell me anything about your actual ability to do the job, and will not carry you very far in the interview process.
Use questions that will show intelligence, and collaboration
As much as I hate logic questions, I find them necessary. We ask several algorithm questions of increasing difficulty at the board together with the interviewer. The difficulty of these questions starts off fairly easy to get the candidate to relax and calm their nerves, and ends at nearly impossible. These questions help to show several things. They show a grasp of foundational CS concepts and the ability of the candidate to build solutions by applying these building blocks even when they don’t know the approach initially. They show the style in which people write their code. Unless you are hiring for an entry level position, or it is known that they don’t know the language and you don’t care, it’s important to ask that the interviewee write their solutions in the language of your preference. A person’s coding style can say a lot about how they approach a problem. Most importantly, however, these exercises show the candidate’s ability to collaborate with their peers. As the questions increase in difficulty, it is crucial that this person can express where they are stuck, and to be able to ask for help. Knowing your limitations and asking for help early is something I value intensely. It is incredibly frustrating when you find out late in a project that your people didn’t understand something, so they made assumptions rather than being open about their lack of understanding. Usually those assumptions are wrong and will bite everyone involved, but had they asked, any number of folks could have helped. If they do not ask for help, or give up, the interview is over.
Use questions that will show them doing their day job
If it’s a UI person, have them implement some UI component that you regularly use. If it’s a db person, have them write you a query that comes up often. These questions must be answered quickly and simply, and should not stump the candidate. If the candidate can not do these efficiently, the interview is over.
Make solutions test driven
If they cannot red-green-refactor. The interview is over.
Re-interview your existing team
When you finalize your list of questions, use them to interview your existing team. Not only will this help you iron out your interview questions, it will also give you a baseline against which to measure your incoming talent.
Using these criteria as a starting point should get you mostly there, provided you make sure you always use the same questions on each candidate. Much too often I see the interviewer go into a room to try to stump the candidate with a new question that they just came up with. This takes all of teeth out of it and prevents you from measuring your candidates against the same criteria and from making an objective decision vis-a-vis everyone else you brought in.
The less objective stuff
The rest is left to the crappy job your intuition does at making hiring decisions. If you think this person is a serial killer, you might sleep better at night not hiring them, in the nicest possible way. If you don’t like them, you probably shouldn’t hire them. For better or for worse, you’re hiring a family member, someone that you should care about, and care about their future, hopefully for a very long time.