This post is advice for managers looking to hire good engineers. If you put a lot of value in the quality of the job interview, you might be selecting for the wrong kind of candidates.
I have worked with a lot of software developers, and needless to say, not all of them present themselves well to strangers. You know the standard stereotypes of the guy (or gal) who is comes off as being a bit awkward. Many times these people are not unlikable: they actually are friendly, take pride in their work, do a good job, and are easy to get along with. But at the same time they don’t have the witty come backs, they don’t always tune in exactly to what you are feeling, their interests may be unusual, and they give off an air of being lost in their own world. In short, they don’t sparkle.
Let’s avoid stereotypes which are always exaggerated, rarely insightful, and sometimes downright cruel. Comedy shows like “Silicon Valley” play up these eccentricities for entertainment. Still there is a pattern of behavior that anyone who has worked in a high tech startup has seen in real life. Some call it “Silicon Valley Syndrome” because high tech companies are attractive for people who like to nerd-out on complex challenges. We have all heard stories of the not-publicly-presentable genius who works miracles in all night stints living on pizza and Jolt cola. Those people are common, the only question is: how did they get the job?
Giving Good Interview
I conducted hundreds of interviews, and I love to interview sales candidates most. A sales person is hired to charm the customer, and that is what they are going to do in the interview. They are selling themselves to you, and so failure to charm you during an interview is a sign of insufficient skill. A good interview with a sales candidate leaves you feeling like you just made a new friend.
The engineering job is not about charming anyone. Sure, they have to get along with people, so naturally they must be polite. Until you know them, engineers often come across as reserved and withdrawn. They might in reality be very warm people, but they need more than 45 minutes to get comfortable, and the interview simply is not long enough. As an experienced hiring manager you already know this, and you are looking for quiet, reserved candidates who just know the facts and have the skills. You are going to compensate by ignoring aspects of the interview that are not part of the job set.
Can you Compensate Accurately?
Time to get brutally honest with yourself. Say you interview two engineers with similar skills, but one (A) is outgoing and charming while the other (B) withdrawn. How are you going to feel afterwards? Probably, you will come away with a much more comfortable feeling after the interview with A. You are going to feel that you understand them better. You will feel they are more trustworthy. After all, what is charm if not the ability to get people to trust you? Candidate B may have responded with better answers to the questions, but you just don’t quite trust them as much.
Can you ignore the fact that you feel more comfortable after the interview with A? B has similar skills, but at the end of the day you are going to trust your “gut” at some level. If you trust your gut, it means you are prioritizing some skills that useful in the interview, over skills that are useful for the job. The fact that you set up the interview scenario, it will be almost impossible to ignore how you felt during the interview.
Maybe ‘Giving Good Interview’ is Part of the Job?
Not likely. The critical skills for software engineering are:
- Ability to read incredibly boring documentation to gain a basic overall knowledge in a particular subject.
- Ability to form elaborate mental models of the software as it is running, in order to determine what the correct behavior should be.
- Extremely organized tracking of anomalous behavior in order to debug problems
- Ability to communicate about precise required behavior and completed accomplishments.
- Lots of Patience
Almost none of these translate to charming the person in the interview. I have worked with people who were exceedingly grumpy and yet excellent in working within a team. One at Netscape had the title of “Chief Curmudgeon” on his business card. These people are not unfriendly, they are just not charming, and it is important to know the difference.
An interview is a kind of test. “Can you give me a good gut feeling in 45 minutes or less?” That is the test. Sure, there is information passed back and forth, but it is impossible to ignore the gut feeling. Do you need engineers that can meet with a stranger and charm them in 45 minutes or less? Honestly, no you don’t.
There is even a danger. There are lots of engineers who are also good with talking to strangers. I could name engineers I worked with who were so good they could talk themselves into jobs they were not qualified for. These people actually lied during the interview, and they were good enough to get away with it. After joining the team, it took quite a while to figure out they actually could not do the work. Everyone liked them, so it took a major fiasco before the alarm bells went off. They simply were good at doing interviews, and people trusted them.
It would be far better to:
- Give a task to write a design specification for a hypothetical problem.
- Give a coding example of a simply problem that can be solved in less than an hour.
- Get them to demonstrate how one of the well known software development tools work.
- Get them to explain the difference between two well known pieces of technology.
- Ask them to read a manual and explain what it is about
- Show them a program and ask them to draw up a test plan which attempts to cover the features sufficiently without being overly long
- Ask them to identify the more efficient of two code samples.
Ideally, all this can be done remotely, in the comfort of their own working environment. (They might not have this at home so a quiet single office might need to be provided.) Reading the design spec, the coding spec, the test plan will give you a much better idea of their capabilities than any interview would.
Let me illustrate with another real life example. One developer I worked with came from a foreign country with an accent so heavy it was very hard to understand what he was saying at all. I had to ask him to repeat almost every sentence. But his code was like that of a genius. More surprisingly, he consistently wrote the best English language design specs, far better than any of the American-born developers. He was inherited from a different project where his co workers were raving about him, but I remember feeling very uncomfortable when I met him. (Thankfully, I trusted the others on the team who knew him.)
The point is that an interview is testing skills they don’t need on the job. You should ONLY look at the products of skills that they actually do need on the job. You should try as hard as possible to avoid asking them to do anything that they will not be doing on a daily basis. It is not because they can’t do those, but because we don’t want to bias our own judgements. You want to judge job skills directly against job skills of others. Pattern the selection process as an analog of an engineering daily life, and avoid if possible requiring skills outside that.
OK, you are still going to interview the engineer for a couple reasons. It takes a lot of effort to come up with hypothetical situations that can be completed in less than an hour and that has sufficient depth that the candidate is familiar with. Anyone can write a simple program to run a pet shop, but that does not really probe their ability to design a complex REST API. We are all busy, and who has the time to set that all up? When you have a good candidate in hand, and you need to assess quickly, it is a time saver to just ask them to come in and talk for an hour. You really can pick up a lot with such a conversation quickly and easily. And you ultimately do need to know if they can get along with others, at least at a basic level.
So the engineering interview is not going to vanish, but it really is critical to set up some sort of test of real job skills, so that you really get a feeling of what it is like to work with them, before you hire them, and to use those assessments of real job skills as the dominant factors in the decision to hire.
An interview is testing for the ability to charm strangers. Engineers don’t need that skill, and relying on gut feeling after such an interview is a perilous course of action.