Four interviewing techniques to evaluate a tech hire
Successful processes for interviews are remarkably rare in the technology industry, and that’s a shame. In fact, most job interviews are conducted on the premise that failure is an acceptable outcome.
This is tragic for everyone involved, and it’s not very smart, either. It leads to a very high rejection rate, and even with successful hires it tends to result in short employment tenures.
Personally, I incorporate four important techniques when I interview a tech job hire.
Determine what they’ve actually done
On the resume, the applicant claims to have debugged a message-oriented architecture. That’s great. Now tell me what that actually means: what was the problem, how did you solve it, what did you learn? In an interview I want a fuller picture of the candidate’s knowledge and capabilities, beyond what the resume bullet-points say.
Teach me something
This dovetails from the previous interviewing technique. Asking the candidate what they did to justify what’s on their resume makes them to explain technology to me. I want to see how they instruct others: are they clear about the requirements and the solution? Do they summarize by saying, “… and we fixed it.” How? I want them to show me, concretely.
If they join my team, someday they will be an expert resource. If they can’t teach anybody how to do what they do, they’re closing off their own information.
If they can’t trust me or the team with what they know, that says to me that I won’t be able to trust them. They’re information consumers, not information producers or participants in an information culture.
Teach them something
Similarly, I’ll identify an area in which the tech candidate has shallow knowledge, and then I’ll show them how it works and see what questions they have about it. Someone who screeches, “I don’t need to know that” or who rejects the authoritative knowledge of others is really telling me that they have pride issues, and that won’t work well in a team.
It’s perfectly all right if I “teach them” something they actually know better than I do! If I’m explaining relational theory to someone and they can correct me, not only do I learn, but I also see how they approach the value of their knowledge. If they teach me in a way in which I can happily learn, that’s great. If they teach me with a sneer – like, “How could you possibly not know this!?” — they’re telling me how they see their fellow team members, and that’s not a good look.
Use humor
When I interview a tech hire candidate, I use humor as much as I can. Dad jokes, terrible puns, anything within reasonable taste is fair game.
I once opened up an interview with a warning that I was going to use the worst Scottish accent in the world. Then I conducted the interview with my native (very non-Scottish) accent, which technically would qualify for a terrible Scottish accent. The person being interviewed laughed and said, “That’s not Scottish at all!” which I acknowledged was “the worst Scottish accent!” That got a laugh out of the interviewee — and established a bond through humor. It was a very comfortable interview after that.
Interviews can be stressful, but your goal should be to help potential hires relax. If they can’t, that’s generally a bad sign. If they can’t overcome fears during the interview, that will likely carry through their employment. Good programmers must be fearless in many ways.
Note that specific technical acumen really hasn’t factored into these interviewing techniques for a technical position. Honestly, I don’t really interview for specific skills. I look for people, not checkboxes.
If someone is able and willing to learn and work with others, they’ll learn whatever technical skills the position requires. You can teach technical skills. You can’t teach people how to be fun, inquisitive and get along with others, and that’s the secret sauce to a good interview.