Offering Code Interview Advice

Let's set the scene: you're considering leaving, or have decided to leave, your current job. Maybe there is too much wrong with the current role, you are looking for a different challenge, or maybe you are relocating. Regardless, you have gone over the decision many times, and are now passively or actively seeking a change. You finally respond to one of those random LinkedIn InMails from a hipster recruiter seeking a Black Ops FinTech Developer (I genuinely received that request!), or hit apply on a role you stumble across on your first search from the excellent Reed app.

The precursor chat with the in/external recruitment agent is simple enough, and you proceed to an enjoyable first round telephone interview. The interviewer seems friendly and knowledgeable, the company is growing, they need people to guide them to even more prosperous times, and you'll learn throughout the journey; in summary, this sounds awesome and you'd start tomorrow if you could! The feedback from the recruitment agent is also positive, and they invite you to take a code test, which you verbally agree to with a little excitement and trepidation, and then the test arrives...

via GIPHY

Bearing in mind the emotional and time investment until this point, being subjected to one of these challenges may not only end your job application, but also your interest in that company at all in the future! So what are these tests, why are they despised, and what can be done? First, let's discuss:

The Tests

Outdated, Random Questions

The worst offender: a non-responsive website of questions last updated several years ago, relating to all sorts of random parts of the framework you use daily but have likely not touched in a while. I can't remember the last time I needed to update the Windows registry in C#, but I'm pretty sure a quick search will find the library... oh look, I'm out of time! Or, worse, the interview site has penalised me for using another tab to research my answer; when was the last time you didn't need to look something up?! I quit one of these tests after fifteen minutes, and vowed do exactly the same again: I explained the situation to the recruitment agent, who agreed.

Epic Problems

Any test that requires more than four hours of effort is unnecessary. Sure, it's great that I have plenty of time to complete the challenge, but if there is another interview that requires less effort, I'll tackle their problem first. Candidates have their own lives to lead, and have surprisingly little time to use solely on the problem you set, so make it succinct.

Time-Bound Algorithm Challenges

When was the last time your manager casually sauntered over to your desk and announced:

Please write a breadth-first binary tree search algorithm within the next twenty minutes.

I'll tell you when: never! They absolutely would not bring pre-canned unit tests, either. What's worse is that some of the inferior sites are plain wrong, such as throwing compilation errors that cannot be replicated locally nor using an online compiler, and unexplained unit test failures.

Don't get me wrong, code challenge sites such as HackerRank, which I have used very successfully to learn and explore languages and algorithms, are excellent for unearthing some talented coders, but "greenfield" development, particularly purely algorithmic, is anecdotally limited. Much of software engineering is combining various platforms and libraries into a coherent, maintainable structure, resolving problems, and — if you're unlucky — dealing with horrendous middle and change management.

Most frustratingly for this category of test: some of the best questions can actually be good fun. Those with flexible time constraints, that ask you to solve a problem and prove it with your own unit tests, around a reasonably-defined brief like one might receive from a client. With a more generous time-frame, such as one day, it is possible to recover from random problems with compilers and laptop meltdowns, and dedicate a little more of your precious evening time to solving an interesting challenge. Ultimately, I don't think a test without some element of human review is good enough, yet.

Code Reviews

Easily my favourite interview technique. Once set, there is little to no preparation required by either party, and great code reviews focus on a small code sample that brings up a surprising number of topics, bugs and questions. These are run very smoothly when that code sample has been:

• Reviewed in advance.
• Tested several times by different engineers.
• Adjusted based on feedback from both interviewers and interviewees.
• Accompanied by a potential answer, to compare and contrast with the original.

Take a look at this C# ASP.NET Core 2 example:

using System;
using System.Net;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;

namespace Test.Controllers
{
    [Route("api/[controller]")]
    public class ValuesController : Controller
    {
        private readonly Service _service = new Service();

        [HttpGet("{id}")]
        [ProducesResponseType(typeof(string), (int)HttpStatusCode.OK)]
        [ProducesResponseType(typeof(int), (int)HttpStatusCode.NotFound)]
        public async Task<IActionResult> Get(int id)
        {
            var result = await _service.Find(id);
            if (!string.IsNullOrWhiteSpace(result)) return Ok(result);
            return NotFound("Not found :(");
        }
    }
}

I guarantee that asking two people to articulate what the example does, and comparing their responses, will surprise you. Prompting someone to summarise, then explain line-by-line, what is happening and why, gives you plenty of scope to understand their basic knowledge, which you can explore further with follow-up questions. Asking what they would do to improve it can provoke interesting replies, which will vary based on experience, and how much the engineer cares for code quality and reuse.

A code review may not work for every interview scenario, and has its own limitations, particularly when the code sample has been leaked and there is no backup.

You've seen some of the problems. What can be done to improve interview tests in general?

The Advice

Avoid Overly-Restrictive Time Limits

I don't need to reiterate the rants above!

Ask Candidates to Write Their Own Unit Tests

You need to have practised Test-Driven Development, or better, Behaviour-Driven Development, to understand the effort required to craft genuinely useful tests. Asking candidates to create or explain some as part of your interview is a great way of ensuring that they haven't listed yet another skill, after writing only a couple of Gherkin scripts a while ago.

Be Flexible with Framework Versions

This may sound obvious, but: if your main deployment environments target a version of the runtime/language that has since been superseded, prepare to accept submissions that use more recent tech! It provides a great opportunity to see what features the candidate has used and why, and it gives you the confidence that they can help upgrade your older environments. If you use a third-party code review/challenge site, ensure that it provides modern sandboxes; who wants to join a company which advocates the use of ancient technology?

Respond Fairly and Quickly

When someone has taken the time to participate in a technical test, please ensure to respond in a timely fashion. If the submission is not up the standard you expect, send constructive feedback! Software development is a broad and challenging occupation, and experience varies wildly, so why not help another person improve? With a little thought, great feedback can soften the disappointment of failure, spur personal development, and nurture goodwill towards you and the company. Plus, you never know when you might meet that person again, particularly in smaller towns and cities.

Prefer Code Projects to Huge Challenges

If the take-home test you set for candidates is spiralling out of control, strip it back to focus them on absolute key skills, such as design patterns and unit tests, and instead spend a little time reviewing the other work that candidates can offer. If the code challenge response is good, and the candidate has some decent Git repositories, a blog, and other means of showcasing their effort to learn outside of their day job, what more do you really need?

Success Beats Absolute Job Requirements

Finally: who cares if your candidate barely wrote a line of Python in the last few years? If they've done so before, and have a track record of success, the chances are that they will pass your code challenge and could be a great fit for the role! Software engineers, particularly polyglots, will happily tackle any interesting challenge, so let them; don't filter them out in the hope that a candidate with the exact skills you think you need will come along any time soon.

In Summary

Software engineering candidate screening isn't broken, but it is hugely varied and in need of some review. Companies that refine their tests will reap the rewards, and learn much themselves along the way.