You're hiring the wrong people: 10 tips to find great developers

Hiring developers is hard. Really hard. I mean, you might think it's hard trying to hire, say, a commis chef for a restaurant...

Actually, that's much harder.

For a start, the working environment is unappealing. It is hot, physically stressful and actively dangerous.

The commis is probably about 17 years old, and has to do hours of detailed, precise prep work, followed by an intense burst of ultra-focussed team work. They maybe get a short break (or maybe not, if they didn't get all their prep finished in the morning), and then they do it all again.

They arrived at work at about 8am, and after they clean everything down, they maybe get to go home at 11pm, or later. And then they do it all again tomorrow. But now they are knackered before they start.

Contrast this with the perception they're given by the celeb chefs they see swanning around a prep kitchen in pristine whites on TV, and is it any wonder half of them give up and walk out after a few days. Leaving you in the proverbial, and back at the recruitment agency.

So, no, hiring developers is not as hard as that.

What makes it so difficult then?

"Obviously," we say, "it is because we're trying to find highly skilled people with great qualifications and amazing leadership skills, not just some spotty 17 year old who can barely be trusted with a knife."

Ok, that is how we make it difficult, but does it have to be?

We (probably) want to hire the wrong people

The software industry is awash with rock stars, ninjas, full-stack- and 10x- developers. They talk at conferences and on podcasts. They tell us all about the ins-and outs of new technology that we only heard about yesterday. And...

...we want them. We really want them. If only we had a few more Samurai Warriors we'd miraculously deliver by the deadlines to which we've committed. Because they are the 10x developers. And 10x developers can save the Earth.

So we look for them. It turns out that we can't hire the ones we've actually heard of, so we look at the next best thing. We go to local meet-ups and user groups and find the people who are talking about the Cool New Technologies and we try to hire them instead.

Unfortunately, most of them are asking for eye watering consulting rates, so we turn to the pile of CVs in our inbox.

They all look the same. Every single CV. Exactly the same. In fact, the same spelling mistakes have been introduced by the recruitment consultant who reformatted any personality out of the original document.

We pore through them like cryptanalysts, trying to draw a bit of meaning out of the jumble: some reason to reject it, or put it in the keep file. "This one occasionally goes to the theatre," or "that one's a drummer. The office band needs a drummer." We pick ten or twenty, more or less at random, and interview them.

The phone interview eliminates half of them. (The half that happen to be not very good on the phone, but hey, we've got to whittle down the pool somehow.)

You schedule the rest for a face-to-face.

Here's where it starts to go really wrong. We now try to force them into the mould of the mythical 10x developer.

Coding tests

We devise clever tests to draw out their powers of miracle working. We make them write SQL, JavaScript and UML diagrams on whiteboards to see if they understand the "full stack". Solve stupid puzzles to see if ... Well, these days it is to see if they are the kind of people who have searched on the internet for the kind of stupid puzzles we use.

As we're a bit more sophisticated than we used to be, we get them to pair with our existing devs, and see whether they 'contribute' in the amazingly stressful situation of trying to work closely with complete strangers while you know you are under scrutiny.

(Some developers at the more rock-starry end of the spectrum have come up with a cunning defence against exposing themselves to this interview technique: they demand payment, as if the morning they spent pairing was anything like a real morning's work, and not a net drain on the productivity of the team.)

And we end up hiring the people who are best at that sort of thing. The ones who can perform in front of a whiteboard. The ones who are good at reading people and reflecting a version of themselves back to the interviewer, or pair partner. And we declare them to be the potential 10x developers.

(Actually, they might be good on-site consultants with those skills, but we've no idea whether they are good developers or not.)

A quick aside - we had an interview candidate who was supremely good at this. Everyone he paired with thought he was great.

Quietly observing this at a distance, we noticed that he never offered a suggestion, just reinforced what his partner offered, with some clever hanging sentences and question openings to make it seem like he was initiating lines of discussion.

He had done very well in the large corporates he contracted at for 3 months at a time. In fact, he was developing a reputation as a bit of a rock star.

We didn't hire him.

A quick aside - we had an interview candidate who was supremely good at this. Everyone he paired with thought he was great.

Quietly observing this at a distance, we noticed that he never offered a suggestion, just reinforced what his partner offered, with some clever hanging sentences and question openings to make it seem like he was initiating lines of discussion.

He had done very well in the large corporates he contracted at for 3 months at a time. In fact, he was developing a reputation as a bit of a rock star.

We didn't hire him.

Hiring rock stars

It can be a similar story if we can afford to hire some of the podcasting rock stars. Although there are many exceptions, most are really, really good at working a room. Charismatic, able to fill a stage, write a great script, communicate the essence of a technology to a receptive audience.

This is a rare, and very bankable commodity.

Maybe 2/3 of their time is spent doing this. The other 1/3 is on short term contracts. They are also great at that. They jump in, assimilate the key facts, set the world to rights, and jump out again. But it is many, many years since they fought a project through from inception, to the first release, let alone into the long tail.

Is that what you're looking for?

Well. Maybe. Some of these guys can leap in, motivate the team, shift a big impediment, introduce new technology...

But that's not necessarily what you need. (Do you even know what you need?)

So who should we be trying to hire, and how do we find them? Let's go back to the drawing board, and think about teams, not individuals.

The Lean Kitchen

The most important thing to note is that the whole is always greater than the sum of the parts, for a team that is working well.

Let's look back at the kitchen. The kitchen brigade as we know it was documented (if not actually invented) by Escoffier, in the late 19th Century, and is an early example of industrial specialization. Each 'station' performs a specific function (e.g. Meat, Fish, Sauce, Pastry), and it is all brought together as a plated dish at the pass, before delivery to the customer. Plated meals were also a fairly novel concept at this time - 'family style' (or 'service a la francaise') was the done thing, with everything brought out at once.

The different specialisms work closely together, regularly delivering integrated results to a predictable cadence, at a well-managed level of quality. This is overseen by a highly experienced chef (the head chef or senior sous chef), who manages the pass as a kind of "quality gate", often doing the final finishing of the dish herself, before sending it to the front of house staff to deliver to the customer.

The whole team is rarely more than 8-10 people on a single service.

Designing dishes is generally done by the head chef, or the chef patron - often with the assistance of senior members of the brigade. Drawing on her experience, she conceives of the general form of the dish - key ingredients, flavour combinations and textures, and then, while the rest of the brigade are prepping, will try out various elements of the dish, until they are perfected. She might leap in and help out with the prep if there's something particularly skilled and time-consuming to do (some butchery, or fish prep for example).

Once the elements on the new dish are working individually, she'll work with the rest of the brigade to bring it together in a finished dish - perhaps tweaking some elements so that they work better, and making sure that the team can deliver their components reliably, and to a consistent level of quality. There's no point in creating an incredible dish that your team can't produce consistently.

Does this sound at all familiar? A multi-function team working closely together to deliver high quality end product to customers at a predictable cadence?

This kind of specialisation is actually an early form of the cellular manufacturing system developed by the Japanese automotive industry in the 1970s and 1980s - and a part of the philosophy that software engineers have embraced in the "Agile" and "Lean" movements. But, it has been quietly (and not-so-quietly) successful in the kitchen for well over a century.

Strong foundations

Another interesting aspect of the kitchen brigade is that, while some people have a natural aptitude or preference for some sections (e.g. Pastry or Fish), most of the basic skills are fully transferable, and the key difference is the level of experience of the team member.

Of course, it takes time to become experienced in the details of a section (a piece of fish doesn't react to heat in the same way as a piece of dough, for example), but if you understand the principles, and you are observant, listen carefully to the experienced team members, and are keen to learn, then you can build up those skills quite quickly. Strong foundational skills are what underpins this.

Hiring as teams

Let's apply those lessons to our technical hiring policy.

1. Any team should consist of no more than 8-10 people
2. Any team should be multi-functional including technical, UX, design, sales, marketing and customer representation.
3. Any team needs a good lead who can set policy, guide the design process, bring the various functions together, and act as a quality gate for the output. They must be able to muck in with practical help when required, but should be focused on the delivery process.
4. Any team needs 1 or two senior people who can support the lead. They should be able to act as a proxy for the lead in their absence, but are mainly focused on practical delivery.
5. Any team needs two or three people with 3-5 years experience in one area in depth who form the backbone of the delivery team. They should also be able to mentor the juniors.
6. Most of the work in software development is detailed, painstaking, repetitive and not actually all that complex. Any team needs two or three more juniors who can do a good chunk of that heavy lifting, freeing up the rest of the team members to focus on the more complex problems, while they gain experience. They will work closely with one of the more senior developers, ideally focusing on a single aspect of the process for a few months at a time, until they build up their experience.

10 types of 10x developers

How do 10x developers fit into that kind of structure? Well, real 10x developers are the ones who, at the level they are at, maximize the overall effectiveness of the team. That might come in a variety of areas.

1. Delivering the work they commit to, with a predictable cadence and quality
2. Slicing through the "hard problems" and sharing a (perhaps left-field) solution with the team
3. Understanding external stakeholders deeply, and bridging the communications gap to the team
4. Understanding the commercial framework deeply, and helping the team understand how that impacts on their decision making
5. Understanding the domain deeply, and making sure the rest of the team doesn't miss a crucial nuance.
6. Understanding the technical landscape deeply, and helping the team to find the best tools for the solution
7. Driving a problem from identification to solution
8. Nurturing a team, and helping it to work together effectively
9. Motivating a team and helping it to keep going throughout the project, through thick and thin
10. Understanding and monitoring the quality of the output of the team. Ensuring that only great work gets shipped.

(You may recognize this as a version of the kind of organizational inventories first put forward by Belbin in the early 1980s.)

So, when you are looking for new hires, you might map out the existing team dynamics on a set of radar diagrams, mixing these personal characteristics with some of the practical skills you are looking for.

Once you understand the shape of the existing team, you can create some example radar diagrams of the kind of people you'd like to hire into the team, in order to maximize their positive impact.

The scores on the diagram are related to level of experience, our capability. For a junior or mid-level person, you might be looking for a 1 or 2 score in the key areas, for a senior person, a 4-5.

Here's an example from our website that we use to communicate a bit about what our team does - it overlays 5 different personae on the radar diagram. This is a great way to look for areas that could be strengthened in the team.

The interview process

We now need to use the interview process to help us explore this space.

But what about the skills?

OK, the skills are important, but you can verify those through the CV, the code the candidate contributes to public repositories, the references from their previous employer(s) and 5 minutes talking to them about a project they enjoyed working on. It will quickly become apparent whether they can basically write code or not (and whether they have been doing so recently).

The degree to which they will need to learn the basics, and the particular tools and technologies you are using is, as always, dependent on their level of experience - not their aptitude.

For example, a 20 year polyglot veteran with practical experience of functional and object oriented techniques is not going to take very long to learn your particular libraries and language of preference. Their 10x impact is far more likely to be through one of the other 10 points above, and you wouldn't necessarily throw them out because they'd take a week to become as proficient in JavaScript as your current average team developer.

And what about "cultural fit"

Culture is really important. Introducing a disruptive element into a team that is humming along nicely can be very serious. Similarly, a disruptor might be exactly what your team needs to re-energize it and kick it back to life; but it is also a great idea to verify that the hire isn't going to get into a fist fight with their new colleagues.

A good way to do that is through the kind of pairing exercise we talked about earlier. Although it can give you some view on their technical capability, it is mainly about the culture. We have developers pair with our designers during the day, for example, so that they can get a feel for the way the whole team works.

The first interview

The hiring goal is to find people who will enhance the team's overall capabilities, and have a significant impact (maybe even "10x"), by removing impediments or adding a missing ingredient (which might simply be freeing up existing team members to use their strengths), rather than being a "10x hire" in and of themselves.

We use our radar diagrams as a focus for the interview. Rather than doing psychometric testing (which is time consuming, off-putting and more than a bit pseudo-scientific), we embrace the lack of science of in the process and ask interview candidates to select from the set of diagrams the one that they think most closely represents themselves.

Then, we use the conversation to drill into this selection, and look for the reasoning that underpins their choices - evidence from their career that supports the match, for example. If they change their mind, and pick a different persona, that's fine too - not everyone (especially early in their career) is good at this kind of introspection, and it is important that the candidate is made comfortable and doesn't feel that there is a "right" answer.

You can use your experience with recruiting people to see how well their self-description is evidenced by examples from their previous career. If you aren't very experienced, or you know you're not very good at it - find someone who is. The most "senior" person in the organization is not necessarily the best at dispassionately identifying talent.

Look at the balance of the team, and see who is going to have the greatest positive impact, for the best price (both financial, and in terms of the negative aspects of their fit).

Score

We find it is really useful for everyone who was involved in the process to score them on 3 or 4 axes (what you choose depends on the role, but we pick technical, commercial, personal), and write a paragraph of narrative feedback.

We (rewrite) these into feedback for the candidate. They've given their day up to us, and even written some code, perhaps, so it is only fair that we give them some proper, hopefully valuable feedback.

We've had a really positive response to this approach (even if it sometimes takes a few months for the value to become apparent!)

We also get the team to estimate the salary they think the candidate should be looking for. This is a really good proxy for the value the team think the candidate will add, and offers a reality check on the other scores.

We then make a hire/no hire decision on each candidate, file the 'nays' and pick our actual hire from the pool of 'yeas'.

The real interview

The real interview starts when they arrive for their first day at work. The first month, then three months are the time in which you find out what the real impact on the team is. The new hire will have to find their role and rhythm within the team, and will require help to do so.

As part of their regular reviews during this stage, talk them through their radar diagram, and that of the team, and work with them to help them to establish themselves in a role in the team. Set them soft goals alongside their regular operational work, and do the same for their colleagues, so that everyone has a framework for helping with this onboarding process.

No hire, three months in

Sometimes (quite frequently, in the first instance) you get the wrong person. This is really difficult, but you have to let them go no matter how much you like them. By all means, unless they turned out to be actively evil, use the data you've got about their capabilities and limitations, and give them a really great exit interview, and plenty of help to find a new position, better suited to their skills and experience, but you have to let them go.

This also means that your terms of employment have to be bullet-proof.

Final thoughts

A good hiring process requires natural aptitude, experience, a good process and a willingness to experiment, monitor, tweak and fail - on the part of the hirer. Just like everything else your team does. Some people are really good at it (and make a profession of it), but it is whole-team effort. Being a good line manager or project lead does not necessarily make you good at hiring. And you should hire for the team, not for individuals.

Finally, you should always be hiring.

It is really hard to ramp the hiring process up and down, and it takes a lot of time and effort to find the right people. If you've got a low-ceremony hiring process, and you filter people effectively before they do their first face-to-face interview, you can always be hiring. There will usually be a position to fill by the time you find the right person.