Options Besides Whiteboard Coding for Technical Interviews

In my last post, I gave some brief advice on how to pass a technical interview with whiteboard coding problems. I am not a fan of the whiteboard coding interview. Whiteboard coding is a very specific skill that really doesn't translate into the job well (or at all). I know plenty of highly skilled professionals who cannot pass a whiteboard coding interview and a fair number of not-so-highly-skilled "professionals" who are absolute wizards when it comes to whiteboard coding. So what can we do to determine if our candidates can read and write code that is more relevant to the job they are interviewing for?

I am a software engineer, so my ideas tend to be geared towards those who spend most of their time writing code. That said, here are some ideas for interviews that are more relevant than whiteboard coding. Please feel free to comment with additional thoughts and/or suggestions.

• Interpreting Code: Provide the candidate with a function that is written in their language of choice (or at least in a language they will be required to use should they get the position). This function could be on paper or presented on a computer screen (even more realistic). For the most realistic experience, the candidate should have access to resources that they may use in real life to learn what they don't already know. (Google, for example, or StackOverflow). 

Now, well-written code that needs interpreting is not a frequent occurrence in a large code base (unfortunately), so this function should be written in a style that does not follow best practices, but does work. Unless the person is interviewing to work at the coder's Valhalla where all code is well written, this is much more realistic. The candidate must then determine what the code does.

• Refactoring Code: This could be done as a followup to the interpreting code question. Once the candidate has figured out what the code does then have them rewrite the code in a clean style, following the SOLID principles in the case of object-oriented programming, for example. I would recommend providing the candidate with an IDE (or at the very least a computer with a text editor) and just let them work on it for 10 or 15 minutes. 

Don't have them do the refactoring on the whiteboard; that would defeat the purpose of doing this instead of whiteboard coding. If you can't provide the candidate with a computer to use then have them lay out what classes and functions they might create (again, speaking in OOP since that's what I'm most familiar with), but don't make them implement it without a computer.

• Reviewing Code: Provide the candidate with a class or function and have them review the code verbally. The code might be functional or it might not be. It might even be functional, but not meeting requirements that you provide the candidate with. You really have a lot of flexibility with how you could lay a problem like this out.

• Add a Feature: This is another exercise that could follow a code interpretation question or a code refactoring question. In fact, you might just have this question immediately follow the code interpretation and see whether the candidate refactors as they go or not. 

If you haven't already, provide the candidate with existing code. It's up to the interviewer whether this is really clean code or not; I would suggest somewhere between really bad code and really clean code. Give the candidate the requirements for a simple feature to add to the existing code. Allow them to use an IDE to add that feature to the code. 

In this case, I would provide them with a working project in an IDE--if I don't have they're favorite available then the least I can do is have the project all set up for them. Expect them to write tests if that's what you have your developers do. Have them do all the steps required in adding a feature to your product(s).

The biggest weakness I see in the above suggestions is the time involved in preparing. If you want the candidate to be able to work in the language of their choice then you'll have to have code translated into several different languages. This might be fun, though, as you could dip your hand into several different languages in the process. Since the code doesn't have to be pretty, you might even create a better exercise in a language you don't know well than in one you do! One useful resource for such a thing is https://rosettacode.org/wiki/Rosetta_Code. (This is a site that I could just sit and play with all day.)

Regardless of whether you believe whiteboard coding is a good measure of a candidate or not, these ideas provide a very few additional options that you can use to switch up your interview questions or to use in a longer interview where you have time for more than one technical question. Please feel free to share your thoughts or additional ideas in the comments.