I’ve written about the technical interview before. I’ve written both for and against code interviews. And I’ve provided both C# and JavaScript questions to weed out fake programmers. But a little more experience under my belt has me rethinking what makes a good interview.
Now, you may wonder why I think I’m particularly qualified to speak about the interview process. Most people who have opinions about the interview process in particular have it from only one side. The one of being the guy looking for a job. And, most of you only interview when you need a job.
What makes me qualified is that, I help interview people looking for a job and I interview for lots of jobs. In my opinion, you should be interviewing for a job, even if you don’t need one, at least twice a year. I interview more frequently than that. In the last 6 months, I think I’ve interviewed at least 4 times.
So, let me start by telling you what the current interview process looks like, and why it doesn’t work. Then, I’ll move on to the few interviews that I believe captured the information everyone was looking for quickly and how you can move the conversation in this direction regardless of what side of the table you are sitting on.
The Oral Exam Interview
I was part of a phone interview recently where every question we asked, the person who was answering the questions answered every question in such exquisite detail we were left thinking, “This guy is either REALLY smart, or he was reading something.” We later gave him a coding interview where we were able to watch him solve the problem. This revealed that he must have been reading something because the code interview revealed that he didn’t have any idea what he was talking about. It wasn’t even a difficult interview.
What this tells me is that all interviews that ask specific technical questions can do is tell you that the person you are interviewing can hack the technical interview. Just like certifications, all you know is that they can take a test.
In fact, we’ve actually hired some people who were able to even make it through a coding interview only to find out they couldn’t code.
The obvious danger is that you could end up hiring someone who can’t really do the work because they were able to jump through your list of questions like some sort of trick pony.
But there is an opposite danger.
Just because someone can’t answer your questions, doesn’t mean they can’t do the work.
The Coding Interview
As I’ve already hinted, the coding interview is no better. Sometimes it will weed out the people who have no business interviewing, but it really tells you nothing other than, “have they used this technology before.” Unfortunately, I’m seeing a rise in this type of interview. It will take a number of consistent failures before we start to see a decline.
About 7 months ago, I was on the receiving end of a coding interview when I was asked to do some specific things while someone was watching. I failed the interview because the specific things I was asked to do, I had not done yet even though I had written a full application using the tools the test was around.
I’ve had other interviews where I was asked to code stuff that had no relation to the business I was being asked to interview for.
So once again, you are just as likely to weed out a good person as you are to weed out a bad person.
The Problem
In both cases, the problem is the same. You are asking questions that are way too specific. Someone who is quick with the search engines can find you the answer you are looking for if they can hide the fact that they are doing it. If you limit yourself to in person interviews, you limit who you can hire to people who live in the same geographic area.
Even a video interview can hide the fact that the person interviewing is looking up the answers. I know, I’ve seen it done.
Even if you do a face to face, the answers you are looking for might be wrong or out of date.
I was at an interview where I was asked how memory was managed in .NET. Since I taught .NET for about 3.5 years at a training company and had actually taught this specific information, I was easily able to give them the information they were looking for. But because I also listen to podcasts, I was also able to amend the information with the fact that how it works in Windows is only how it works in Windows. The spec doesn’t actually dictate how memory gets managed. At least not at the level I think they wanted answered.
But, what if they were looking for the answer that indicated that I knew how memory was managed under Windows and I gave the answer according to the spec? Fail!
A Better Way
One of the best interviews I ever had was when I was interviewing for a JavaScript position. The question I was asked at the beginning of the interview way, “I know nothing about JavaScript, explain JavaScript to me.” I started talking and occasionally, I would be asked to drill deeper into a subject. It was a hard interview because it required me to break something down I was very familiar with, think on my feet, and demonstrate that I was able to explain things. It also demonstrated how much of JavaScript I knew.
As I’ve thought about that interview and compared it to others I have been on, what I realize is that this demonstrated that the person who was interviewing me really wanted to know what did I know. In contrast, just about every oral exam interview I’ve been on has made me feel like the person interviewing me wanted to show me how much HE knew.
The Right Questions to Ask
So, if you want you can steal the question above. But the point is, we want to ask open ended questions.
“I see on your resume; you’ve worked with Angular. What problems did you face while using that framework?” or “I see you have experience using Git and SubVersion. What do you like and dislike about each?” or “Tell me about some of the issues your ran into with your last project.” In other words, ask very open ended questions around the technology you are interested in that invite them to demonstrate that they’ve really used the technology they say they have used.
What if You Are the One Being Interviewed?
So, you walk into an interview and you are asked an oral exam question. What do you do? Well, the first thing to do is to try to answer the stupid question (without reading of course.) And then, and this is the key part because it will change the course of the interview, tell a story.
Whatever they ask, the thing you want to do as soon as you possibly can, is to change the question into, “where have you used X in the past?” So, let’s take a JavaScript question. “What does it mean that JavaScript uses prototypal inheritance.” You answer the question, “prototypal inheritance means … in fact, knowing this became really important on one of my recent projects because we used it to do …” and you are off to the races. When you finish demonstrating that you know the answer and it has been important to your work in the past, you might consider asking, “I was wondering, how has that been important to your work here?” Remember, your goal is convincing the people interviewing you that you really can do the work. That hiring you compared to the other people they are going to interview is going to be 10 times less risky.
Turning it all around like this is an art. It takes practice. This is why I encourage developers I coach to interview frequently. Try stuff out. Experiment. When you get home, review what you were asked and think, “how could I answer that better the next time?” Because, many of the questions we get asked get asked by everyone.
If someone ask a question you don’t know the answer to, just say so. My standard answer is, “I haven’t done much with that, but I’ve been programming for X years and there is Google, and PluralSight, how hard can it be?” If you’ve never used it but have sniffed around the edges, say so. An attitude of “I can do this.” works a lot better than lying about it.
There are some other things you can do to hack the interview process, like sitting sideways, spreading your arms out, and other “hypnotic” tweaks. But the best hack is spinning stories around your answers to change the interview from an exam into something more of a conversation.