Interviews Are About the Future Not The Past

Mar 18, 2015 14:12 · 1498 words · 8 minute read

##Most Interviews Are Horrible It’s almost a cliché to point out how a lot of common business practices are carried on out of sense of familiarity or tradition without any thought about what they are trying to accomplish

Job interviews are one of the worst.

I’ve interviewed many people and have been interviewed many times to the point that the pattern is so easy I could repeat it in my sleep:

Interviewer: How long have you performed [job x]?

Candidate: I have performed [job x] for [time].

Interviewer: We are often busy. If you were in [a challenging situation], how would you respond?

Candiate: I would respond in a [very appropriate way]. When I’m around, all situations will be handled [appropriately].

Most interviews proceed this way. Good candidates, or at least candidates that have experience, know a few tricks. Tell stories. Relate the answer to the company and so on. They spend all the time on a few past issues or generic situations where there is clearly a right answer (or stupid ‘interview’ questions like what are your 3 weaknesses) and move on after a simple answer.

When I ran a department I decided that was a waste of time. My positions were entry level, so most people would not have relevant experiences, so instead I focused on how they handled problems. I figured the way a person approaches a problem is far more important than the problem itself or even the result.

Over time, I developed that philosophy that interviews are about the future, not the past. So I don’t settle for simple answers, but instead dig into the candidates reasoning and process.

##Discovering Traits in Applicants Interviews too often focus on the past. Maybe this makes sense with certain professions where the problems occur over and over again. And there is certainly a lot of value to past experiences. However, that value will only manifest itself if the candidate is reflective and uses the experience to inform their future actions. There’s an old saying in programming about how some people have 10 years of experience and some have 1 year of experience ten times.

The challenge, then, is not just to learn about the experience an applicant has had (presumably a lot of this is evident from their resume and code samples), but to figure out what they did with that experience.

###Concrete Examples The best way to determine history is to ask for examples. Instead of asking how they would help a new developer learn a system. Ask “Tell me a time when you mentored a new developer even informally.” Sure people can inflate their experience, or answer in a self serving way (it is an interview after all) or even lie, but the chance of getting the truth is much higher.

This seems easy enough. Yet people are surprisingly reluctant to be concrete. I was in an interview with a potential engineering manager and I asked for a time when he resolved a conflict between management needs (getting a product out quickly) and engineering needs (having well-tested, well crafted code).

He responded “Yes, I’ve had situations like that. I usually try to talk with both parties…” After he finished, I said that was great, but I wanted a concrete example. He started talking again using a concrete situation for a moment, but then going abstract. I gave up on him.

Why are concrete examples so important? It’s because life is messy. In hypothetical scenarios we all get both sides to agree, we all convince the under-performing employee to buck up, and we all tweak the process to get products out on time. In real life, one or both sides loses something, people are grumpy when given criticism and process changes often lead to slower turnaround. Every decision has choices, trade offs, and consequences. That’s what I want to know about. We can solve the imaginary problems when we reflect on how we will do it differently in the future.

###Pry The most common question I ask in interviews is “why” and the second most common is “what did you learn from that.” Any answer to an interview question is, at best, a surface summary. To take the previous example, if a candidate answered they mentored a new developer by giving them an easy project and then checking the code after it was finished, I would say “why did you wait until they were finished?”. Maybe the candidate would say they were busy and this was the only time that they had. Maybe they would say they think working through a problem through the end teaches independence and problem solving. Maybe it was because they gave them a really small problem and would give harder and harder problems moving forward. I don’t know. The problem is we don’t ask.

The secret to understanding a candidate is to understand their motivations and their process. We spend so much time on a candidates history, but history is fairly unimportant. To repeat, when we hire someone, we are hiring their future. Instead of spending time on the problems they solved, we need to understand how they solved them and why. The second most common question I ask is “what did you learn from that”. When candidates reflect back on their experience, they inadvertently highlight the priorities in their career. If a candidate built a new UI for their product, I may ask what they learned from the process. They may talk about how changing requirements caused them to modify how they worked with other departments on new issues or maybe they learned some technical trick or skill that they applied later. Every project is imperfect and every insight will color all future tasks.

###Pain Points The last thing I always try to do is find out how candidates deal with adversity. For managers, I often ask what’s the hardest decision they’ve had to make. For everyone including non-managers, I ask for an idea or project they tried to implement that did not work out. I don’t believe in the strange Silicon Valley habit of fetishizing failure, but no one has a perfect track record and I want to know how they dealt with problems.

Here’s the secret. Saying, “I decided it wasn’t worth pursuing” is an acceptable answer (provided they explain why they reached that decision). In fact, the worst thing I can hear is someone being over aggressive in pushing through their agenda. There’s a whole post I can write about how people confuse being an asshole for being confident or assertive, but for now I will just say that pushing through a solution that destroys a team, department, or company is a horrible decision. My favorite answer is when a candidate talks about how they realized a plan wasn’t going to work, so they reassessed the situation and tried again.

##Filling a Niche After all this, a pretty good image of the candidate should emerge. Many will seem confused by the process (particularly after the third “why”), but it so much easier to understand how someone will fit into an existing group after this is all finished. The hard part is deciding if they are a good fit. I’m not talking about a fit in the sense of whether they will be fun to have lunch with, but whether they will fit the niche of the team. Good teams are like ecosystems, they need diversity. A candidate that is a perfectionist about code quality may be a good fit on a team that needs someone to keep them honest, but may be a horrible fit on a team that has great code, but can’t meet deadlines. Sometimes the hardest part is trying to figure out which niche needs to be filled. The questions should be built to decide if a candidate will fit that role.

In one of my previous positions, I was hiring my replacement at a university water ecology department. I had set up a digital repository for publication produced the department, so the technical challenge was all but completed. The real challenge at that point was gaining buy-in to the system and training people how to use it and convincing them that they would benefit by using it. In this case, many of my questions revolved around developing training and working with a range of individuals. The best person ended up being a former science teacher. She had both the science background to gain trust for the members of the department and had experience, well, teaching. She had led projects that met with skepticism from her peers and she learned from that skepticism how best to sell ideas to colleagues.

I wasn’t surprised when she led several well attended seminars on the system. I knew she would do something to integrate the system into the work flow of the staff. I merely had no idea how she would do that, but I knew she’d find a way and that was all that mattered.