On Technical Interviewing
Bob was a stall mucker, a damned good one by all accounts of his peers. Now maybe Bob didn’t think so but he went about his job in a conscientious manner which made him better than 75% of the other stall muckers out there. The horses seemed to appreciate him, his stalls were always the cleanest in the barn and his boss took notice. One day, The Boss Man came to Bob and had the following conversation:
The Boss Man: “Bob, you are an excellent stall mucker. You always remove the hay and the manger and the food. 98% of the time you remove the horse too. The shavings are always clean and the food is replenished. I really appreciate your work.”
Bob: “Thanks, Boss. I enjoy it”
TBM: “I don’t know if you’ve heard but Calvin Borel can’t race in the 5th today at Churchill because he gained 10 pounds eating red velvet cake in downtown Louisville last night. So I’m going to make you a jockey.”
Bob: “Well I’m flattered boss but I don’t have any experience being a jockey. The last time I rode a horse was at summer camp when I was trying to impress Lascivious Luella Luckhart. I ended up getting bucked into the horse trough.”
TBM: “Fiddlesticks Bob, you’ll make a great jockey.”
Bob: “Well, thanks again boss but it seems like the things that make me good at my job don’t necessarily overlap much with being a jockey. Are you going to give me some training?”
TBM: “Heck no, the 5th race is in 3 hours. I’m going to put you in a sweat suit to lose a few pounds and send you on your way”
Bob: “…”
TBM: “I knew you’d agree Bob. Now get out there and give them hell!”
Later, Channel 5 carries footage of a huge thoroughbred horse storming through the streets of Louisville with Bob mightily trying to cling to life on the horse’s back. People wonder what possibly could have gone wrong? Both jobs had to do with horses, right?
Ahem. What does this possibly have to do with technical interviewing? Well, in my experience, this is the natural course of things as developers progress through their career: do a good job, get noticed doing a good job, get promoted to someone who is at least slightly in charge of hiring people and get told “Give ’em hell!”. Both jobs have something in common, that is, some level of technical expertise and understanding. But the expression of that expertise and understanding is manifested in fundamentally different ways.
A developer produces code that with any luck provides value to the business. He does this by making computers do what he wants them to do. He tends to have some predilection towards truth and correctness because the computer requires it. He has to know the language to speak to the computer. He has to understand the requirements. The questions the developer asks of the computer are naturally binary in nature and often can be answered “yes” or “no”. For a developer, the interaction with the computer is everything (even if he’s creating a single page application to show you the latest kitten pictures from the Web).
An interviewer has to take that expertise and understanding and figure out if another HUMAN BEING has the same or similar expertise and understanding. He doesn’t have a compiler or runtime to help him out so his ability to succeed rests wholly on the questions he asks of the interviewee. But here’s a problem. Yes-no questions make TERRIBLE interview questions. You will discover next to nothing asking these types of questions. Interviewing is a conversation with a stranger who is likely somewhere between anxious and terrified at what confronts him. A good interviewer has to navigate human emotions. On top of that, a good interviewer needs to think that hiring is a critically important act, that doing it poorly will result in catastrophe and mayhem in the same way a developer thinks an off by one error might one day end the world.
Yet in 14 years of doing this work, the overarching reaction I’ve seen from developers and technical interviewers alike is “Meh.” Interviewing is a burden. You’d think we’d start to ask questions regarding why that might be so. Perhaps it’s because the thought of having a conversation with a stranger gives lots of software engineers nightmares. The only training I’ve ever received regarding interviewing is “Don’t do anything that will make HR fire you.” Which only serves to further terrify me regarding my ability to even be a mediocre interviewer.
In recent times, interviewing has moved away from technical expertise and focused on cultural fit. This switches the focus even more from a developer’s excellence all things technological and asks him to decide if the person on the other end of the line or across the table has the same VALUES. Remember, the typical way we decide if a software developer is good is whether he can make a computer do the correct thing. It’s yes or no again. But now we’re asking him to do something far more subjective, to carry on a conversation with a stranger and see if they have the same values. It sounds like a recipe for disaster.
Here’s my current list of things that a good interviewer has: strong technical expertise, an ability to think on one’s feet, an ability to put a candidate at ease (because no one performs well when they think their life is on the line, metaphorically speaking), an ability to tell another human being “you just aren’t up to snuff” in a way that hopefully doesn’t make one sound like an asshole and an ability to carry on a social interaction all the while judging the other social interactant on a wide array of criterion. Of that list, only the first seems to naturally overlap with the skill set of an engineer. And in fact, several of those abilities are often in direct opposition to the skills of an engineer.
When you find an software developer who is also good at interviewing, it’s not because one caused the other. It’s because that person has multiple skill sets that slightly overlap in the same way a stall mucker has a slightly overlapping skill set with a jockey. Now if you’ll excuse me, I have to go track down a runaway race horse, er, prep for an interview.
P.S. This blog is 5 years old today. That’s as shocking to you as it is to me.