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.

Passing a Technical Interview

For many programmers, the technical interview is the hardest part to get past when searching for a new job. It's not that they don't know how to code, they do. It's also not that they don't know how to solve problems, they do. But the coding interview is a special animal that requires a special skill to pass. There is a large amount of debate about how useful a coding interview can be in determining the best candidate for a job. This post is not intended to go into that debate (though you're welcome to make any observations about the merits of coding interviews in the comments if you like). Here are some links you can take a look at if you want to see what people are saying:

• Why Technical Interviews Work (And Why They Don't)
• The Technical Interview Is Dead (And No One Should Mourn)
• Why we don't have technical interviews for technical roles at Buffer
• Programmers are confessing their coding sins to protest a broken job interview process
• The Rise And Looming Fall Of The Engineering Whiteboard Interview
• Is It Time to Kill the Whiteboard Interview?

You might notice that a fair number of these links are to articles about how the whiteboard interview is ineffective or failing. This isn't because of my bias; it's because there are a lot of articles out there questioning the efficacy of whiteboard coding interviews. Yet, in spite of the number of articles predicting the downfall of such interviews, they are still very much in the mainstream. It is very difficult to find a tech company that doesn't expect whiteboard coding (or, if over the phone, coding in a shared web environment where the interviewer can watch the interviewee's every keystroke) from each of its software developer candidates.

The lesson here is that if you are going to get a software development job then it is very likely that you'll need to pass at least one coding interview. Some companies will even do one or two coding interviews over the phone, then have you come on site and do three or four more on the whiteboard. This makes the ability to get through these interviews an important skill for landing a job, if not for actually doing the job. What follows are some tips (in no particular order) for how to get through a coding interview.

• Talk to the interviewer. The theory behind a coding interview is that the interviewer gets to see not only if you can write code or not, but also how you go about solving a problem. If you do all of your thinking inside your head then not only is the room (or phone line) filled with awkward silence, but the interviewer has no idea whatsoever what you're thinking or how you're working through the problem.

• Ask questions. Some interviewers will deliberately leave important information out of the question they ask you in order to determine whether you can identify the missing information and know to ask for it. Do not make assumptions about what they must have meant! This is a major tripping point for a lot of people, as the tendency is to dive into coding using assumptions that they don't even realize they've made. Instead, treat the interviewer as a collaborator and work with them in coming up with a solution.

• Write a few examples on the board before beginning to code. This not only helps clear up any misunderstandings that there may be about what the problem is asking for, but it also gives you something to test your code against as you go along.

• Practice a LOT before the interview. There are a lot of ways for you to get practice in, some free, some not. https://codefights.com/ allows you to test your skills against other people. https://www.meetup.com/ probably has meetups in your area in which people get together to practice coding interviews. There are also classes or coaching sessions, such as Technical Interview Mastery Workshop, put on by Blossom Career. (Full disclosure: Blossom Career is my wife's company and I help teach the workshop. There is a fee for this workshop that helps cover the cost of renting space for it.) The point here is to get a lot of practice, whether via one on one coaching, group coaching, practicing with others, or simply practicing on your own. (If you don't have a whiteboard, you can practice by writing your code on paper.) Make sure that you practice explaining what you're doing as well as solving the problems/writing the code.

One final note on this topic for you: there are lots of books out there that offer sample interview questions for you to practice with. By far the best book I have seen is Cracking the Coding Interview by Gayle Laakmann McDowell. This book not only contains sample questions and solutions, but it also contains chapters with excellent advice on getting through the interviewing process. I highly recommend this book. (I have no affiliation with the author or publisher of this book, I just think it is an excellent resource for you.)