Reader feedback on using code reviews in interviews

Reader feedback on using code reviews in interviews

Yesterday, I asked for reader stories about code reviews in interviews. I'm glad I did, since I've received a bunch of responses.

Matthew related to me a story about an interview he was on. The interviewer produced a chunk of code they dealt with every day from a former employee. Apparently this person had been "kicked out" of the organization. It was written in Perl and while it was syntactically valid, it didn't actually accomplish what they said it would.

His task was to make it actually do what the comments claimed. He turned it around and got the job. It turned out that finding every possible flaw and proposing fixes was a good career-building move for him. He added that it might be useful as a red flag, too: just find out whoever best suits the profile of writing crap code for this purpose.

David shared a story about interviewing for a database role. A bunch of SQL queries were presented, and he had to get at least 10 of the 15 multiple-choice questions correct in order to continue. Some of the questions wanted to know if a given statement was limited to one SQL engine or another or if it should work anywhere.

Finally, m.j. wrote in to describe her interview for a different sort of job: semantic modeling. Candidates are given a hardcopy version of an ontology diagram and must demonstrate they understand the model. She reports that she found a flaw in their diagram, and ultimately landed the job.

My thanks to those who have already written in for a post which isn't even 24 hours old yet. I'll keep my eyes out for more comments.

Reading these stories makes me realize something else this technique might detect: detail-oriented people. There's just something about being able to look at something and immediately have a problem jump out at you. It doesn't work every time, but when it does, it can look like magic to a casual observer.

I've been lucky enough in my career to have a few instances where this has happened. I'll never forget some of my drive-by troubleshooting successes. Being able to immediately unblock someone else who's been wedged on a problem is great stuff.

Regarding the "which flavor of SQL will accept this", I bet some of this could be done for people who claim to be hard-core shell scripters. Give them a script full of "bashisms" with a "#!/bin/sh" at the top and see if they catch it. This one is subtle since many systems have used bash as their /bin/sh at various points in time, and it can lull people into writing scripts that way.

A similar thing could be done for someone who claims to have tons of book knowledge of the different C specs. Drop a "//" comment in some supposedly-C code and see if they ask about C99. If they do, then you can probably have a great conversation about horrible compilers and the "bad old days". Dropping a variable called "new" into some supposedly-C++ code might be fun, too.

Finally, I understand that certain networking certifications basically show you a working network, then break it and give you a limited amount of time to fix it. That sounds like a pretty rough way to prove that you know every single stone to look under, but I guess it works. I haven't been through that, personally.