Shit Applicants Write

kqr

, published 2019-04-17

Tags:

It’s an old, known fact that the majority of applicants to software development positions can’t code themselves out of a wet cardboard box. I never realised the extent of this until I started helping out with interviewing applicants at my current job.

Here are some of the better excerpts from applicant solutions to very simple coding tests, and what’s wrong with them¹¹ I seriously do not mean to offend with any of this – I want to give people a chance to see what sort of thing I might be looking for..

In several of these examples, it may seem like I’m nitpicking. That’s the opposite of what I’m doing. There are often a bunch of tiny flaws that would either be revealed by testing, a lint tool, or just style guidelines, and I’m going to ignore these entirely and focus on the code that seems to work but doesn’t quite sit right with me.

Unnecessary conditional

In[1]:

function range(from, to) {
  // This conditional is unnecessary and obscures
  // the actual structure of the operation.
  if (from === to) {
    return [];
  }
  const res = [];
  for (let i = from; i < to; i++) {
    res.push(i);
  }
  return res;
}

Why You Should Find It

Any conditional like that is an indication that your algorithm has an edge case that you needed to deal with separately. This is in turn an indication that either a) your algorithm isn’t general enough to handle all valid inputs, or b) your function accepts inputs that aren’t considered valid.

Before committing an algorithm that you know isn’t general enough, or a function that accepts invalid inputs, you should double-check that you can’t fix any of those issues.

Stray Side Effects

In[2]:

def sum35(number):
    result = 0
    # ------------->8------
    print("sum up to provided %s is %s", number, result)

Why You Should Find It

When you have a choice between printing the return value and actually returning it, 100% of the time should you return it. More generally: if someone uses your function and expects it to just compute something, and it does a bunch of other weird stuff on the side, that’s a bug report someone will have to deal with eventually.

And in this case, the specification even said the result was supposed to be returned.

Missing The Big Picture

When asked to find problems in a piece of code, you should not focus on syntax errors and whitespace placement if the code has a serious bug that causes it to throw an exception regardless of what parameters you give it. If there are huge issues with the behaviour of the code, get those out of the way first. Only then can you comment on style issues.

I don’t have a concrete code sample on this one, but it’s just as well because this is pretty much the error people make. All the others are, in one way or another, instances of this one.

Dictionary Of Indices

In[3]:

const weekdays = {
  1: "Monday",
  2: "Tuesday",
  3: "Wednesday",
  4: "Thursday",
  5: "Friday",
  6: "Saturday",
  7: "Sunday",
};
// How about...
// const weekdays = [
//     "Monday",
//     "Tuesday",
//     "Wednesday",
//     "Thursday",
//     "Friday",
//     "Saturday",
//     "Sunday"
// ]

Why You Should Find It

The technical term for this is isomorphism. Two things are isomorphic if you can write functions that convert back and forth between them without loss of information. Being able to recognised when things are isomorphic is an extremely valuable skill for finding the simplest possible algorithms that still accomplish what you want.