The dreaded coding / technical test

I've given, and taken, different flavours of coding/technical "test" which seem to fall into three main buckets

• Write some code on a computer
• Write some code on a whiteboard
• Talk through a problem and potential solutions to that problem with the interviewer(s)

I want to focus this post on the write some code on a computer flavour of technical test, which also comes in different flavours:

• Here's a problem that fits the context of the company doing the inteview: write code to fix it
• Here's some code with a bug, and bug report: fix it
• Here's an IDE, here's a scenario (e.g. write a basic address book): start writing it
• Here's a method (with code doc comments), it's empty, here are some unit tests that will pass when it returns the correct output: fill it in

There are positives and negatives to each flavour of write the code coding test, but I think I've settled on my favourite.

A problem that fits the context of the interviewing company

Now, unless you've encountered a very nefarious and sneaky interviewer (and I'm sure this is entirely urban legend!) who's going to take advantage of the code you write to further the business, it's likely the reason that this has been chosen as the test scenario is that there's a pretty good chance that the company have already solved the problem and possibly have solved it more than once during R&D. I've broken this one out from "fix a bug" as this is the "no extant code" scenario, possibly delivered with a defined interface to other parts of the system. An example of this sort of test might be something like:

One of the solutions we provide is webchat that customers can integrate into their websites. When a webchat completes, we need to send it to a 3rd party sentiment analysis solution that we resell to our customers.

Here's details of where we store chat data, here's where it needs to go and here's the format it needs to be in

Pretty daunting as things to solve go, but if it's made clear that you're not looking for a production ready solution - perhaps not so awful. If the output format for the data is XML, don't write code that builds up strings with concatenation or a StringBuilder (if we're talking C#, which I am), use something like XElement, there's no way you'll get all the escaping right that you should do - so don't try. Please.

Code with a bug, code the fix

This flavour of test will either come with, or without, accompanying unit tests. If it comes with tests, the first thing you should do is run them. Make sure they all pass and if they don't, work out why. It may be that one of them is there specifically to cover the bug that needs fixing, if there isn't one for that, write it.

As far as coding tests go, how easy this one is to get your head around is entirely dependent on the code that you've been given and its accompanying bug. I think it can be a tricky one to do well as you're almost entirely beholden to:

1. How clear the code that has the bug is - Is it a big mess of spaghetti code? Are the variable names clear so you can comprehend the code quickly? Are you pointed at the specific method where the fault lies?
2. Have you been given pre-existing unit tests - If you've got pre-existing unit tests, this helps you to be sure that a change you've made to the code doesn't break something else
3. The nature of the code you've got to fix - If the subject matter for the code is something you're not familiar with, or something fiendishly complicated, that's not going to help

Here's a scenario, write some code

This sort of test is one that I've given in the past and usually involved being given a couple of options, like (all with the baseline of "use whatever C# based tech you want, WinForms, WPF, WebForms, MVC, pick what works for you. You can store the data wherever you want, using whatever data storage/access solution you want):

1. Write a simple, single user, address book
2. Write a To Do List app that lets users add, remove, modify and mark as complete their To Do List items

In other words, something that gives the candidate an opportunity to put together a simple CRUD application but provides them with a couple of different choices for the type of data they'll be storing. The choice helps some candidates as it gives them the opportunity to pick one that they feel most comfortable with. This is usually a coding test where there's no expectation of a "fully finished product" at the end of the exercise, rather it's an opportunity to see some code they've written. The most important bit is talking through the code with them to find out why they've made the decisions they've made.

Fill in the empty method, here are some tests that validate it

I've saved this one until last, as hands down, it's my favourite. By giving the candidate a method to populate, along with some unit tests to validate their code against, you've given them a constrained framework to work within and also a way to check that what they're doing meets your requirements. Here's a brief(-ish!) example of what some of the code harness could look like:

public sealed class ReceiptCalculator
{
    /// <summary>
    /// This method takes the line items for the receipt, along with the tax bands and does the following:
    /// 1. Works out what the Tax value is for each band (the prices in the Line Items are INCLUDING tax)
    /// 2. Works out what the total value of the receipt is (the value of all items)
    /// 3. Works out what the total Tax value is for the receipt
    /// These values are placed into an instance of the Receipt class and returned
    /// </summary>
    /// <param name="lineItems">The items that have been purchased</param>
    /// <param name="taxBands">The tax bands that may be applicable</param>
    public Receipt Calculate(IEnumerable<LineItem> lineItems, IEnumerable<TaxBand> taxBands)
    {
        throw new NotImplementedException();
    }
}

public sealed class TaxBand
{
    public decimal TaxRate { get; set; }
    public int BandId { get; set; }
    public string Name { get; set; }
}

public sealed class LineItem
{
    public int Quantity { get; set; }
    public string Description { get; set; }
    public decimal UnitPrice { get; set; }
    public int TaxBandId { get; set; }
}

public sealed class Receipt
{
    public decimal Total { get; set; }
    public decimal TotalTax { get; set; }
    public Dictionary<int, decimal> TaxPerBand { get; set; }
    public IEnumerable<LineItem> LineItems { get; set; }
}

Yes it's contrived, but with a set of unit tests that are well named so that the candidate can use them as guides without having to pick apart their content, you're setting them up to be able to give you code that actually works.

No matter the test - talk to the candidate

Irrespective of which style of coding test you give the candidate, don't just ask them to do it then take the code away and say "thank you very much, we'll look at this later" (or words to that effect). Take time to talk to them, as you do in every other part of the interview process, find out why they made the decisions they did when constructing their code. It may well be that you look at their code and it makes no sense to you - but the candidate misinterpreted a requirement. In "the real world" this is less likely to happen as it's not "test conditions", so give them the opportunity to show you what they've done, why they've done it and why they thought it was the right choice.

Carrying out a coding / technical test can be hard, but if you do it right you can get a great insight into the way your candidate codes and the thought processes behind it - it's almost reasonable to say that the actual code they write is only 50% of the value of the test.