Jeremy Burns

The tech test we do has worked really well. It starts off with a simple base and as the candidate completes it we can add layers of increasing complexity. It's a really good test and is very revealing without being too intense and stressful. It can be run in most coding languages.

This might not make much sense when written down here. Happy to walk through it individually if that helps.

Preparation and set up

We ask the candidate to bring a laptop to the face to face interview. At a suitable time (typical 20-30 minutes in) we hook them up to a big screen. We tell them this in advance so it is not a shock and they can mentally prepare. Importantly, we don't give them details of the test as it's essential they do not prepare in advance; we want to see them work it out.

Connect them to GuestNet so they can use Google, Stack Overflow, any reference site and so on. Seeing what they look up is revealing.

The task

Make it clear that they should approach the task as if it were their normal work. Explain the task verbally rather than in writing (this is important):

We'd like you to build a module that can schedule commands and execute them on request. It will have an external interface you can use to pass it a function and its arguments. The number of arguments passed in each time might vary. You can do this multiple times and the module will store each one in turn. It is important that the module does not execute them as they are stored. After you have stored as many functions and arguments as you like, you can call a second interface to execute the stored functions in turn, applying the arguments passed in for that function. The module will then return a list of the results. Assume this is going to be production-ready code and approach it just as you would when working day to day. There is no need for code control and we'll tell you if you go off track. Feel free to use the internet in any way you like.

Summary of requirements

Although all the information is in there, it's deliberately a bit vague. There are just three requirements really:

1. The module exposes an interface that accepts a function (as a first class citizen, defined outside of this module) and some arguments. In other words, the function is passed in as a function, not a reference to a function inside the module, e.g.
   1. sum (a, b, c), which adds a + b + c
   2. subtract (a, b) which subtracts b - a
   3. multiply (a, b) which multiplies a * b
   4. concat (a, b, c) which joins a to b to c
2. The module stores them but does not execute them (this is the scheduling part)
3. The module exposes another interface that loops through the stored functions and executes each against its arguments, returning a list of results, e.g.
   1. sum(1, 2) and subtract(2, 1) are passed in, we'd expect [3, 1] as a result

The ideal approach

The ideal candidate approaches it something like this:

• Admits that they don't understand the requirements and asks for them to be repeated
• Listens and asks clarifying questions rather than jumping to conclusions
• At some point opens notepad and writes a bullet list of the requirements as he/she understands them - but checks as he/she does so
• When they are written correctly and they have checked with the interviewer, then opens an IDE and creates a project. They also include a test framework like Jest.
  • This part should not take too long and it should be efficient, clearly demonstrating that he/she knows how to start a new project. We've seen people struggle at this point or take ages, adding unnecessary complexity.
  • We make it clear that there is no need for code control.
  • We infer that it should be 'production ready', indicating the requirement for some tests (without explicitly asking for tests).
• Then writes some BDD tests, runs them (and gets red because there is no code)