Joe McMahon

I've been experimenting with something in the interviews I've been doing most recently. Turns out it works quite well, so I'm sharing this in the hope that it will help you as much as it has me.

One of the most important things on a software team is code reading comprehension and communication: the ability to read code, whether yours or someone else's, and walk through it, explaining to someone else what it does. Sometimes you'll be reading your code and explaining it to someone else; sometimes you'll be reading someone else's code and explaining it to yourself, sometimes you'll be looking at something brand-new to everyone and trying to puzzle it out.

One way to test this is to ask the interviewee if they have any code on GitHub or BitBucket or anywhere else they're proud of and that they'd like to walk you through. This is valuable for two reasons: one, you get a chance to see what the interviewee thinks is their best code, and two, you get to see if they're any good at communicating what they know.

They might say, "well, I don't have any Perl code, but I have this other thing I wrote." This is even better, If they do a good job of explaining it! One candidate, explained some Arduino real-time code, monitoring USB connections to reverse engineer protocols in painstaking and magnificently precise detail. They did such a good job that I could have easily pitched in and worked on the code after a half-hour walkthrough. (We made an offer and they accepted, and we have hugely benefited from this person's talent.)

If they don't have anything available, the next best thing is to fall back on "what's your favorite CPAN module?" and then go through that. This can be highly instructive. If the interviewee says, "well, it's Moose, but that's going to be hard to explain without a lot of context," you learn that the interviewee does indeed have an instinct for complexity and how long it will take to do something complex. If they go ahead and succeed, it's even better yet!

If they pick Data::Dumper, and then realize that the code is pretty complex, but forge ahead and do a good job anyway despite its somewhat idiosyncratic way of dealing with things, you've learned that they're persistent, willing to work though difficult code, and don't fluster easily, in addition to their being fluent.

Understandably, not everyone is really good at this, nor do they have a pet module they feel familiar with. In those cases, I usually use my Acme::Geo::Whitwell::Name module as a sample thing to walk through, because it's a relatively small module which none the less uses a fair number of Perl features. Also, since not everyone is good at grokking code they've just now laid eyes on, it's sometimes necessary to do some hand-holding and "let's skip that for now and come back later"; in those cases, you just want to make sure that they get the flow of control, they understand the idioms they're looking at (or say, "I've not seen that before, what do these lines do?").

This technique is very useful in phone interviews where it would be tough on everyone to do code samples on the logical whiteboard. (You can of course do those with Google Docs and the like.) It's real strength is in the things it tells you other "this person has written some Perl." It gives you an idea of how well the interviewee is likely to do when handed a chunk of your code - or the whole codebase - and told, "I need you to find and fix this bug". Being able to read code and understand it well enough to communicate your understanding helps immensely with the most basic kinds of jobs it's always necessary to do when writing code: what does this do? what is is supposed to be doing? why is it not doing that?

This does not have to be a pressure technique. Your job is to walk through the code cooperatively, and help them over stuck places. If you hit something neither of you is comfortable with, you can move the conversation to, "so how would we write a test to figure out how this works? is it even possible to write a test? where should we look to see if this is tested?".

If they get stuck on something, like a complex regex that's not in /x format, or a hash slice, or something else new to them, be prepared to fill in information to see if they can take it from there. Note what they did and didn't know, and explain it - but also note where the gaps are in their knowledge - they may or may not be in places that matter; knowing every kind of zero-length assertion is great, but not everyone does. (Not knowing them at all is a point to be noted, especially if they're common in your codebase.) Ask "where should we go look to find out what that does?" and see if, once you've assisted them over the bump, they get back to smooth sailing again.

Overall, this has been a useful tool to me, and has resulted a couple of very good hires. Give it a try if you want to get away from the "write some code to do this in five minutes" kind of interview. (Of course that should still be covered; if you're the sole interviewer, you'll want to have at least a little coding happen.)

I'd love to hear what people think of this idea, and let me know if you try it.