Andy Toone

what’s in a technical test? the mark of an excellent engineer, we find

We’ve written before about the recruitment process at MetaBroadcast. We enjoy encountering new faces as we grow the team here and want potential candidates to get something positive from the experience, too. We tweaked the process so that candidates can get a good feel for the company, whether they’ve applied for a technical or non-technical role. It’s important for any candidate to not only have the chance to shine, but also to understand what drives us and what brings us to work with a smile.

Though only settling in myself, as part of the software team, I already help with formulating tests, evaluating them, and then, pairing with candidates and assessing these new developers on their day in. So if you apply for an engineer role here, I want you to have the best chance to show off your skills.

what’s in a technical test?

When talking about the technical test we typically ask developers to complete, it’s worth saying there are actually two parts to it. The first test is a couple of hours long, and given to a new candidate to complete in their own time. It helps us understand what level of experience and skill they have, how they think, and whom they should pair with on their day in. It also helps the candidate get a glimpse of what we do here.

If she does well, we ask her to spend a day with us where we can see how well we work together. More subtly, and across more hours, this is still a technical test. Working together involves solving problems together, understanding a set of requirements, picking up the tools we use every day and building something that works. From a technical point of view, we can see not only where the candidate is, but also how well she can learn and adapt when faced with new and exciting technologies. And she can see whether this is, indeed, something she would like doing on a daily basis.

So what are we looking for when we review these tests? How can you show us your best? We’re looking for the signs of an excellent engineer. That’s a very nebulous concept, and one of the reasons there are so many different recruitment processes in the industry. It’s actually very hard to measure someone’s ability to develop software and contribute to a team of developers. Our tests allow us to see some of the elements that come together in great engineers.


The first part of any project, and a vital skill that we’re looking for is the ability to decompose the problem. The only way to deal with large, complex systems is to break them down into small components that can be fully understood and reasoned about. Well written software should express how you broke the problem up. If you’re a Java developer, or write in another object oriented language, we’d expect to see that decomposition in the arrangement of packages and objects that you create.

Remember also that objects aren’t just about passing data around in an application. Decomposing behaviour allows us to build complex algorithms up from simpler actions. If simple objects can express their relationships with each other (am I smaller? bigger? do I come before? after?) or perform actions together (let us combine our values, transform or output them), then our complex algorithm can be expressed in simpler terms rather than having to deal with the intricacies of data housekeeping.


Once a problem is broken down, we’re in a position to write the parts that actually do something useful. There are some excellent books devoted solely to algorithms, some of which solve difficult problems with startling beauty. We’re not actually looking for the ability to regurgitate an obscure solution to a particular problem space though. What we do want to see is the ability to express your solution clearly. If we can’t understand what you’re doing to achieve your results, imagine the headache that code is going to give someone six months down the line when it needs altering to meet some new criteria.

If we can see the steps your code takes to solve a problem, then we can also reason about it. You might not happen to know or have worked out the most efficient algorithm, but understanding its characteristics shows a good grasp of software design. We deal with large and loosely interrelated data sets at MetaBroadcast so though we don’t want to get bogged down with premature optimisation, we do need to spot where problem areas are likely to exist. Being comfortable with big O notation is a great help here.


Well considered objects that encapsulate behaviour, nicely laid out code and clearly expressed algorithms will reassure us that you are able to develop useful, maintainable code. They also help us to feel that you’ll work well in a team where the exchange of ideas and solutions drives our daily routine. In that context, testing isn’t just about proving your software works correctly, but also demonstrating how it may be used.

We’d like to see tests that show understanding of the problem space—not just the expected input, but also edge cases that might cause issues. If you’re sorting large lists of data, what happens when there’s only one item, or no items at all? We’d also like to see tests that show how to set up and invoke your software. If it’s composed of separate units, can we use them separately and show that they work in isolation?

wrap it up

We don’t expect that everyone who comes to us will have the same level of experience. Nor do we expect them to have covered the exact combination of tools, techniques and processes that we use. Though the examples above relate to clearly demonstrable skills, they also only give us a flavour of your abilities.

The final thing we’ll be looking for—particularly if you come to visit us for a day—is the desire and passion to learn. It’s far better to see someone come across a new idea and run with it than to watch them trot out their standard solution by rote. In the latter case, being right is no good unless we can see that you know why a particular solution is right and what its limitations might be.

The goal in the whole recruitment process is therefore not only to discover excellent developers, but also people who’re keen and able to grow with us. As a fast moving company, MetaBroadcast is an exciting and rewarding place to work. The point of the technical test is to make sure we both get the most out of that relationship. We want you to do well, so hopefully this is a great starting point for you to join us.

blog comments powered by Disqus