Can Coding Interviews Be Improved?

Timed coding interviews have become a standard tool in the interview process. All of a sudden, companies expect that candidates will write functioning code on a whiteboard in an attempt to assess the skills of the candidate. No tools, documentation or internet lookup, or other reference materials are allowed. And, you're supposed to write the code without syntax errors while other people are watching you!

Why do companies use this approach? Because companies such as Amazon and Google use whiteboard interviews, and, therefore, it must be a good thing to request that candidates write code by hand.

At first, I thought that people were kidding when I heard about whiteboard code interviewing. To me, it was a throwback to an early part of my career where a colleague from Poland told me about how they didn't have computers. Instead, their professor had them write code on paper, which was then verified by the professor — the professor took the role of a compiler. You do what you need to do when you don't have an alternative.

Looking closer, I learnt that a whole many million-dollars industry (books, classes, and even full curriculum as described in the picture used for this article) has formed around coding interviews. In parallel, you'll find lots of information about what type of interview questions different companies ask on job sites, github, and so on. People are now spending lots of time and money studying for job interviews.

Remind you of something? A friend of mine makes the following observations:

Because the ability to cram for an interview is THE absolute decider for whether or not to hire an applicant. Like the SAT - make it a threshold and they'll game the threshold, without necessarily adding value.

In other words: people are making lots of money on teaching programmers how to pass these tests the same way as they study to pass standard achievement tests! Talk about defeating the intent of code interviewing, which correctly used provides both a gate-keeping function and the means to assess what role is a better fit for the candidate.

Worse, some companies that are now trying to use this coding interviews don't necessary understand how Amazon, Google, Big Data, and other high-tech companies use code interviews. This disconnect leads to situations where the interview is done by people that view the whole thing as a pass/fail situation. These companies don't understand that many don't complete the test when interviewing at the companies they try to mimic. Misused code interviewing is, therefore, unfair to both the candidate and the company that is trying to find new employees.

Now, imagine if you you hire a candidate that passes all your programming tests (party tricks, puzzles, and so on) just to find out that your new employee avoids using the compiler instead spending lots of time ensuring that the code is syntactically correct so that the first compile will be error free. Next, you learn that your new employee doesn't know how to search documentation for information and examples, doesn't know how to use an integrated development environment, and really doesn't know how to program beyond party tricks such as "print all permutations of a given string."

You'd not be happy at all! A human spending lots and lots of time finding typos that can be found by a compiler? Ludicrous! You fully expect your professional programmer to use a lot of tools and, most often, be able to jump between several different programming languages. The LAST thing you need is someone who wants to write code on paper or a whiteboard by hand.

I'm hoping that the example of a candidate that knows how to game the system but doesn't actually know how to program is extreme. Still, there's a risk that we'll get there as we see with standardized school testing. Surely, there must be better ways to do assess candidates' technical skills? Process improvement is always a good thing.

As a hiring manager, I support technical assessment as a necessary and useful part of interviewing when done right. But, I am also looking for ways to make technical assessments more relevant to the actual position and how we expect professional programmers to work in their day-to-day assignments.

My gut feel says that we should include the whole tool set in the interview since that allows us to understand how the candidate works when approaching problems. You'd want the candidate to get reference code, look at examples, read documentation, compile, write test cases, and so on. Right?

What else would you do to improve upon the technical part of the interview process? One approach could be to bring in issues that you've recently worked on since such issues are fresh in your mind and the interview might not only assess the candidate but give you new insights that you've not considered. A win-win situation.

I'm very interested in hearing your ideas and thoughts. I'm also interested in your views if you are a big supporter of whiteboard coding. So, please share your thoughts by commenting on this article as you see fit.