Hiring our jugglers

Every now and then a rash of blog posts appear looking at the process of hiring good engineers. Some just lament the difficulty (it is hard!) and some claim a new silver bullet by doing something unusual. The markets we hire from in both Leeds and London are highly competitive and the best people usually have several companies vying for their attention. When you do find someone there is the difficult task of measuring whether they’ll actually be any good at the job.

Bizarrely, when it comes to hiring engineers few people seem to actually look at their hiring requirements and derive a selection process to fit. Odd when you consider the day job for almost all the engineers involved in recruitment is exactly about understanding requirements and designing a suitable solution.

Hiring engineers is hard

As a consultancy we need to find those engineers who are technically excellent, understand a broad range of approaches and be personable with it. They need to not only be able to understand and talk about the pros and cons of possible solutions, but also lead by example and actually “demonstrate by doing” in implementing their proposals.

“Do-ers who think and thinkers who do” as our strapline goes.

In order to find the right people, part of our process at Infinity Works involves a technical test. For developers the technical test is a take-home coding exercise and involves creating a simple application. We allow you to use your favorite IDE, libraries, and language. For platform engineers it’s a simple automation exercise and again you’re free to use your favorite tools and techniques. There are some deliberately ambiguous parts and you’re free to pick some sensible assumptions so long as you document what those are. In both cases the purpose is to demonstrate some real-world skills akin to what you’d actually use on the job.

If you haven’t read “Peopleware” I highly recommend it. It’s one of those works, like “The Mythical Man Month” who’s messages endure despite the apparent march of technology around them. The chapter opening for “How to Hire a Juggler” is still as relevant today as it was in 1987:

Circus Manager: How long have you been juggling?

Candidate: Oh, about six years.

Manager: Can you handle three balls, four balls, and five balls?

Candidate: Yes, yes, and yes.

Manager: Do you work with flaming objects?

Candidate: Sure.

Manager: … knives, axes, open cigar boxes, floppy hats?

Candidate: I can juggle anything.

Manager: Do you have a line of funny patter that goes with your juggling?

Candidate: It’s hilarious.

Manager: Well, that sounds fine. I guess you’re hired.

Candidate: Umm … Don’t you want to see me juggle?

Manager: Gee, I never thought of that.

When I began hiring engineers, asking developers to complete a coding test was a relatively new concept. Common practices at the time were still not far removed from the juggling interview above. If you were lucky the questions were augmented by writing pseudo-code on a whiteboard in the interview or trying to divine coding ability from abstract problems like “why are manhole covers round?” favoured by both Microsoft and Google. Neither (unsurprisingly) really told you much about people’s ability to do the job.

But producing actual code, that is the job

In absence of other influences how an engineer structures their code, applies their testing and gives consideration that someone else might have to read and maintain it tells you an enormous amount about their approach and abilities. In addition, a consultant needs (to a large degree) to be a generalist and understand a good breadth of technnologies. Seeing how people select an appropriate solution to the problem is also an important secondary measure of the test.

For this reason whenever I receive an email from a recruiter along the lines of “We have to move quickly on this one, can we skip the tech test and just get them in for an interview?” the answer is always a resounding no. We want to hire excellent engineers and be confident that they will do a good job from day one. For us, that is our most important requirement and that is why we ask for the technical test.

But if you’re (say) a product company then you probably have a different set of requirements. A stable product team focused on a single thing is clearly a different environment to a consultancy. Deep knowledge in a specific stack might be important, or cultural fit might be top priority knowing that you have a high-bandwidth ability to mentor people. As a startup you probably need people, like we do, who are excellent across a number of areas and can flex their role to cover a range of positions, but also who buy into the vision of what you’re building. Graduate recruitment needs to focus on raw aptitude and ability to learn.

Recently I saw a post on from a startup suggesting they had “the answer” to hiring and were just going to send their candidates a technical questionnaire. While that might help them find people who can reason about technology and are good at articulating themselves on paper, it seemed unlikely to find people who were actually good at coding. Though since they didn’t discuss what their requirement actually was maybe that was the right answer for them.

(As a side note: it’s entirely possible there is a strong correlation between ability to talk about coding and actually doing it, but my hiring experience over the past decade suggests that is not the case.)

All of these scenarios put a slightly different lense on the hiring process. Common practices like multiple technical interviews across a whole day (strongly selecting for deep technical skills, obviously), or taking the candidate for lunch (selecting for cultural fit) target different aspects. They also have very different cost and commitment implications for both sides – having the whole product team interview people is extremely expensive in terms of raw man-hours, but maybe that’s ok if that cost is demonstrably lower than the cost of a bad hire.

There are no silver bullets. Hiring good engineers is hard and what defines “good” for your process might not be quite the same as the next guy.

But at Infinity Works we want to see how you juggle.

Insights