The Importance of Hiring

Hiring is the most important thing we do.

— Google

To build a great Engineering team, you have to hire great Engineers. Given that many of you will already have a team that you have built or inherited (or a bit of both), the details of Recruiting might not be vital to you at the moment. For those that are actively hiring, I will have an entire Blog Series in the near future about the process of Recruiting. This post will stay at a high level.

You need to build an Engineering group to fulfill the only objective of a software company, which is to produce valuable functionality as efficiently as possible. For this purpose, you need candidates that exhibit the following:

1. Communication – this is always my highest value criteria for hiring Engineers. Development is an activity that relies heavily on communication – between fellow Engineers, between Engineers and Product Owners (“the business”) and, ideally, with Customers as well. The best way to explain this is to imagine that if two people don’t comprehend the other, and suppose that each interaction they have results in a 20% decrease in the fidelity of the message. If we look at just a single round-trip comprised of a question (that is 80% understood) and an answer (that is also 80% understand), we can compute that, in only one loop, we are at 64% understanding [1]. You can imagine how quickly this degrades to approach zero. Keep in mind that I’m not suggesting that you should only hire native speakers in whatever jurisdiction you are in. I have hired Engineers for all over the world and for most of them, English (my native tongue) is a second, third or fourth language. Their English doesn’t need to be impeccable to communicate with accuracy. In the course of a short interview, you can assess very quickly if they understand your questions and you’ll definitely know if you understood their answers. I usually have a specific current employee who represents my minimum bar for communication and I assess each candidate based on that person [2].
2. Efficient Developer – the primary day-to-day task of an Engineer is to write code. If they can’t do that efficiently in their current favorite language (we’re speaking about programming languages now), I can’t have faith that they will be able to do that for me. The good news is that there are several sites that facilitate coding tests. These tests almost never give a false negative but are susceptible to false positives (since the candidate can have a friend help them out). To combat this, I do an additional coding test on-site for those that make it that far. One thing that I generally am less fussy about is whether they know the same programming language we are using. Good Engineers can pick up a similar language (e.g., Java if they are a C# developer) very quickly. You’re better to get a great Engineer that doesn’t know Java well than a mediocre one who is fluent in it.
3. Interest in the business – since we are trying to have them appreciate the delivery of valuable business functionality, I look for them to have demonstrated an interest in the business side in their past roles. In rare cases, they might have taken on a role on the business side (such as a Sales or Product Management role). They might have also worked in a Services or consulting role, which fosters exposure to, if not interest in, the business side. Most often, you’ll need to ask questions in an interview that will ferret out their understanding of the business they wrote software for.
4. Logical thinking – assuming that the candidate has decent communication skills, proven coding skills and some business acumen, the last piece of the puzzle is their thinking skills. This can be assessed in an interview situation with the right questions and scenarios (we’ll cover those in the Recruiting blog series).

With that high-level coverage of the Recruiting process, we’ll move into the more practical process of nurturing your Engineers.

This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker

Footnotes:

[1] For the mathematically-challenged, this is based on 0.8 x 0.8 = 0.64

[2] Obviously, I don’t tell that person or others that they are my standard.