Coding quizzes are touted as a staple of developer interviews, ostensibly to filter out the silver from the dross, sift the wheat from the chaff. For interviewers, coding quizzes represent a cheap, readily available assessment of prospective job-seekers’ programming abilities. And not only are they great for assessing the coder’s style, leading coding quiz sites like Hackerrank even save snapshots of the state of the code as it is written, making it great for insights into how the coder thinks as he codes.

However, for non-developers or the otherwise uninformed, it is tempting to treat the coding quiz as an assessment of the programmer in general. After all, a programmer’s bread-and-butter should be how to code, right? But as we will see here, there are various aspects of programming and software development that coding quizzes either cannot cover, or will simply fail at.

If you’re looking to use a coding quiz as part of your interview but don’t have programming experience of your own, my advice here basically is to get someone who’s experienced in reviewing code to look at it on your behalf.

To preface this article with my experience with the coding quiz, when I interviewed for a tech company, they gave me a Hackerrank test consisting of 2 questions. The first was for string manipulation (which was fairly straightforward), but the second question was a tough one, dealing with optimization of an algorithm. With limited time for the quiz, needless to say I scored poorly on that one.

After reviewing the results with my interviewer, however, I discovered that almost everyone else who interviewed before also scored equally poorly for that question in particular. Not only that, in the weeks after I was hired, only one person would get a full score for that quiz out of dozens of interviewees (he was also hired). Fundamentally during hiring discussions, the decision to hire or not was not based on the results of the quiz.

And with that in mind, let’s look at the first reason.

1: It follows the standardised test framework.

You see, the coding quiz in its commonly encountered form suffers from the same problem as any other standardised test, and the metric in this case is whether the test cases hardcoded into the quiz succeed. Like any standardised testing, they can be trained towards. Most test questions revolve around more generic stuff like string manipulation (and not the quantum physics kind) and algorithms, which is small enough of a subset to study/train for.

For example, that second coding quiz question I took? Given a list of points with x-y coordinates, find the 2 coordinates closest to each other. It’s easy enough for most programmers to answer, but the optimization is a little tricky to achieve. The fact that it is common, however, means that people can train to answer this type of question, and remember that one person who scored full marks for it? Yeah, he trained specifically for that question.

You may say that he was clever enough to prepare for it, but this is a feature/bug inherent to standardised testing, that it tends to be game-able this way. Don’t get me wrong; standardised testing has a long history of use as a benchmark for figuring out all sorts of aptitudes. But only if they test a good representation of the subject at hand and test it well, and that is by no means easy to achieve.

Whatever metric the test uses to measure aptitude will almost never be truly representative of the actual subject matter; it can’t be, because demonstrating said knowledge is usually too wide-ranging to cram into a single test session. Ask too many questions to try and cover everything, and the interviewee may tap out halfway through. Ask too few questions and your test coverage of the subject matter may have too many holes.

#developer #coding-interviews #code #software-development #interview