Why You Should Never Consent to a Coding Test in an Interview
Software engineering interviews nowadays often involve some kind of coding test or programming exercise and I think that’s a very Bad Thing. Here’s why.
Lazy Tropes
Asking software engineers to perform a particular task such as writing an algorithm to generate factorials (a very common one) or to sort a [singly|doubly] linked list can be easily memorised beforehand and offers no insight into a candidate’s skill other than their strength of rote memorisation. You may as well ask the ASCII code of the character ‘A’.
The detailed solutions to many such exercises are widely available online in various reference materials and, in many cases, in books that contain both algorithmic and specific program language implementations to all of the common interview coding questions.
Whilst working at one company I was talking with a colleague about the detailed interview process they were working through with a major hedge fund. Everything technical they asked he had carefully memorised from a widely available interview questions and answers book that a current employee had passed on as a source to all interview questions.
Luckily, he was a skilled engineer, but had consented to go through this frankly monotonous and mundane exercise to secure the position. He shouldn’t have had to do that — not only was it a waste of his valuable time but it also gave the hiring company nothing in terms of ascertaining his ability.
He left a year later, in any case, tired of their low technical bar for hiring and continual ineffective project management practices…
Use of Memory
The same reasoning goes for coding an algorithm in a specific programming language. No software engineer operating in the real world would write a section of code without either some kind of syntax checking aid (such as an editor’s built-in code completion), without referring to some technical documentation, or without just copying a pre-implemented solution where applicable. There’s no sense in reinventing the wheel.
I would wager that much code running the world’s systems today originated as an answer on Stack Overflow.
In all practicality, working with the syntax of a particular programming language comes from use and familiarity. Whilst an interviewer may think that testing a candidate on the syntactical nuances of a particular language is a gauge of their understanding, I, for example, can state categorically that although I have been using the C language for nigh on thirty years that I still regularly get the syntax wrong.
In fact, as my software engineering career has evolved and I have become more familiar with the languages of my own interest, I regularly get confused between syntactical nuances of say, C and C++, or Objective-C. This isn’t because I’m a terrible software engineer (though some may disagree…) but because there’s only so much knowledge you can hold in your head and have direct recall of at any one time.
A good software engineer often doesn’t know the answer to a specific question off the top of their head, but will definitely know where to look to find the answer. Perhaps consider asking the best place to find such information as an interview question?
Common Tasks
Something I touched on briefly earlier on is the maxim of not reinventing the wheel. For example, if you’re working in C and need a serial port routine then you don’t have to rewrite one from scratch unless the situation specifically demands it. Perhaps you need a JSON parser, a very common requirement — unless you’re coding on a limited resource embedded board, on a satellite in geostationary orbit, or in Malbolg then perhaps you should just pull in a pre-written one from a library. Chances are it’s been in use for a long time, has been fully tested, and has detailed (and correct) documentation. Solid.
It’s unlikely in modern software engineering to come across a common task that hasn’t either already been automated in a pre-written library or whose implementation isn’t widely available in algorithmic form.
If you’re like me, and in the game primarily because of the love of the subject, then you’ll probably be actively seeking out those roles where you’re implementing things that have been implemented before. Seeking out strange, new worlds, new life, new civilisations, …
In fact, the concept of software engineers in the far future has more than once been likened to code archeologists where they primarily reuse existing code and spend relatively little time designing and coding new and novel algorithms.
Discussion Discussion Discussion
I do fully endorse finding out whether or not the person you’re interviewing ‘knows their stuff’ but using any of the above methods in, in my opinion, utterly worthless. Say it like it is.
For example, a simple discussion on the coding paradigms used in modern software engineering, whether a particular language would be a good choice for a specific implementation, or whether or not a particular software engineering methodology (I’m looking at you, agile) is relevant are far more rewarding and poignant subjects to discuss.
Lead the discussion to highlight general areas, see what insight the candidate has into new problems and perhaps alternative novel methods to tackle older ones. How do they see things evolving, how would they start to address something. Keep open ended, stay away from specifics and minutiae.
And the key there is, discuss. Ascertaining value is not just about ticking boxes and it continually surprises me that many companies that are considered ‘up and coming’ and ‘leaders in their field’ still fall back to outdated, monotonous, and utterly predictable hiring practices that show little value in gauging actual technical acumen.
It’s often said that the interviewee should be interviewing the company just as much as the company is interviewing them. I’m fully behind this one.
Being interviewed by someone with a list of precise technical questions is pretty much always red flag, particularly when they don’t wish to prolong discussion on any one point. It often shows that the interviewer may not fully understand what they’re asking and any answer that doesn’t precisely match up with what’s written on their script will be classified as incorrect.
The Bottom Line
Some companies have changed to better methods, others, well, fall well short of the mark. This is where I urge you, fellow software engineers, to not engage with companies that follow outdated hiring practices and insist on programming tests and exercises.
Especially prolonged ones!
I’ve heard stories of companies asking for projects to be completed on the candidate’s time, often taking several days.
Others have generic ‘aptitude tests’ for specific languages, multiple choice, where a hint of brain fog within the limited allotted time equals game over!
If you’re new in the game then perhaps you’re not in a position to turn down interviews and I fully understand this, but do see it as a learning experience. Go through the motions, get the experience, learn as much as you can, and if the job does disappoint then just move on. As you move on your confidence will grow along with your knowledge and experience. After all, the company benefits from you, so you must equally benefit from the company.
If you’re an older experienced sort, as I am, then hiring companies — just talk to me. I’ve been around, I’ve seen things and done things, the qualifications are all on the wall and on the C.V., and I resent being channelled down some generic hiring pipeline and repeatedly tested on my ability.
If you think you’re a decent employer and you can’t understand why seemingly excellent candidates keep pulling out then you should take a real long look at your hiring practices.
