Interviewing by Teaching

I've been trialling a new technique in interviews recently, and the results so far have been good so it feels worth sharing.

Essentially it's a refinement of the "try to make the interview as much like the real work environment as possible" approach I've written about previously. As well as do some work together, I look for an opportunity to teach the candidate something along the way. This is entirely in spirit, as in a good environment one team member learning something from another will happen frequently - anything from a spike into new language features to the salient points from a particularly interesting conference talk.

Initially this was a way to make candidates who clearly weren't going to pass still have a positive experience, and feel like the process wasn't a waste of their time. Or of mine: there's not an entirely altruistic motive here as teaching someone new stuff is a lot more fun for me than struggling through a technical exercise clearly beyond their skill level.

After a few iterations of this, I realised this simple process of making me not bored and candidates not having a horrible experience had unexpectedly useful output. In some cases it was even converting a "close no" into a "yes", or a "close yes" into a "no". Seeing how people reacted to the interview being forgotten and a new technical concept explained was giving me better insight than any number of questions or even the practical exercise.

Good candidates would really engage with it. I think there's a little bit of a two way street here; if you're doing this right, the person on the other side of the table is grateful that rather than being left to flounder, they're being shown the answer and how to get to it. The best people are even applying the new knowledge and reasoning about how it can be extended once we move on. This is great because that's exactly the kind of person I want to work with - we can sit together exploring something for half an hour and they immediately get it.

On the flip side, it helps you filter out some bad behaviour too. "Bad" in this instance isn't necessarily failing to learn or apply the new techniques - that could be down to my own failings as a teacher. It's more in the reaction. Bad candidates give you aggressive responses: "that's not useful", "I've already got my way of doing it", "this is no different to (thing that is different in about a million obvious ways)". I've found this particularly helpful weeding out competent but arrogant candidates: a favourite is taking someone's freshly-minted classical OO code and working through how it could be implemented equivalently with monads or map/reduce.

This is a good point to talk about disagreement in the context of "engagement" versus "aggression". I have had some very good discussions with candidates who fundamentally disagreed with my suggested approach. A particularly good one was that functional approaches could have a tendency to create accidental "hot spots" - highly abstracted functions which participate in so many different logic paths that working on them is akin to trying to solve a Rubik's Cube in the dark. With tweezers.

(Again, these are discussions that will need to take place in the real world. Unless you want a team that's half framework magpies and half still refusing to move on from Java 7.)

I suspect there's more to be refined, and I'm yet to figure out how to deal with a candidate who knows so much more than me in every area there is genuinely nothing I can teach them (other than hire them!) But so far both the results and the feedback even from unsuccessful candidates have been encouraging.