

Coding tests - how do you decide if the result is "good code"? - andrewstuart

Say someone does a coding test as part of their recruitment process.  You look at the resulting code and decide if it is "good code" or "bad code".  What is the <i>exact</i> criteria to decide?  I'm asking here for tangible assessment criteria rather than wishy washy hunches, vague feeling, subjective hand wavy "yup that's good" or "no that's bad" decisions.<p>Imagine the coding test is an anagram solver.  To come up with the best solution, the programmer must realise that anagrams can be determined by sorting words and comparing them.  The ideal solution is one in which each word is added to an associative array using the sorted word as the array key.    Okay, so if someone does not come up with that insight and solution, does that make their code "bad", or make them any less of a programmer, who does not deserve to get the job?<p>Do coding tests based around puzzles or logic challenges obscure the purpose, testing for someone's ability to solve a puzzle rather than testing their ability to get stuff built with "good code"?<p>I put it to you that most coding test results are evaluated in a very airy-fairy way with no science or precision.<p>Is there a science of defining "good code"?
======
philbo
A method I like is to pick a few hypothetical change requests, either new
features or modifications to existing ones, and ask how straightforward making
those changes would be. This has the advantage of also giving the candidate
the opportunity to talk in greater depth about their code and any design
choices they made, hopefully providing some insight into how they go about
this kind of thing in the wild.

Edit to add: the point being that, on one level at least, good code is that
which is easy to change.

------
tjpick
there are plenty of metrics for complexity, efficiency etc, and you'd hope
it's idiomatic to the language used.

Your associative array example may not be the best. It just shows your own
bias. Depends on how it's implemented, someone could likely come up with a
different implementation that performs better.

