How to Hire Engineers as a non-Engineer

“There are things we know that we know. There are known unknowns. That is to say there are things that we now know we don’t know. But there are also unknown unknowns. There are things we do not know we don’t know” – Donald Rumsfeld, US Secretary of Defence

Over the last 12 months I’ve had seemingly countless conversations with founders and recruiters about how to hire engineers. If you are a technical founder, you probably started your company by building the early versions of the product with your own two hands, and you hired people when those hands were no longer enough. Recruiting for a field or task that you know how to perform yourself is hard enough, hiring for roles that are in a different field to your own, and doing it well – that’s a whole different ball game. I’m not a software engineer and have no formal (or informal) training in computer science. In the world of tech startups, especially early stage, that puts me somewhere on the spectrum of being illiterate in a library. It has been a very steep learning curve. Below is what I learnt so far.

Why are you hiring?

The first questions I always ask anyone that comes for recruitment advice is “Why are you hiring? What happens if you don’t hire right now?”. When you are not a developer yourself just starting out, there is an overwhelming temptation to get someone on board who is. Context is very important. Are you building something that is inherently very technology heavy? If you are and you don’t have an engineering co-founder, you have chosen a very tough path. Can you get away with getting a proof of concept without engineers? I have a few friends that are building a very exciting fashion-tech startup and they are yet to hire a developer. It’s amazing how much you can get done with tools like WordPress, Squarespace and Invisionapp and actually talking to your customers with designs and prototypes in hand.

What do you need to know?

I don’t code, but I spent several hours every week talking to developers about code, frameworks, build process, APIs, databases, servers, sysadmin and testing. I know how every piece of our product is put together, how it works and what the limits are. The most important thing to learn are the limits of your own abilities. This does not mean knowing that you can’t code! This means knowing exactly what you can’t code. When you know what you don’t know, it becomes a lot easier to find someone who does. What you don’t know differs wildly depending on what you are building.

A simple example – if you are building a web application should I hire a PHP, Python or Ruby developer? There are arguments for each, but to make them you need to have a much deeper picture of what you are trying to build. What did your competitors do? Was that a good idea at the time or is there better technology now? How much talent is there in my location for this programming language? What is important to me – speed, flexibility or reliability?

If you are a recruiter hiring engineers – you need to know the answers to all these questions! When I talk to in-house recruiters, the best can always tell me in intimate detail about the technology behind their product, why they use it, and where they are going next.

Where to start?

Talk to people. Find other engineers, other founders and ask for their thoughts on how they would build your product and who they would hire. You have your own skills – always offer to help first before asking for help. Talk to a lot of people. Ask for referrals, references, friends that don’t mind doing things on the side. Then start looking at contractors – a lot of very good engineers do self-employed contract work. It’s expensive, but it gets you started.

The simple truth is that a good engineer likes a good challenge. The more daring, novel and technically innovative your venture is, the easier it will be to attract bright, inquisitive minds to come with you on the journey. That doesn’t mean you have to be Elon Musk building the Hyperloop, but probably not Tinder for dogs either. We work with a lot of new and open-source technologies, and encourage our team to hack away and experiment with anything and everything. This has led to some very cool features we didn’t know we could build so fast.

What questions to ask?

So you managed to get some people interested. You’ve set up interviews. What now? You could go through the standard “tell me about yourself ….tell me about a time…what is your experience with…”, but what does that really tell you? Hiring is forward looking, and nowhere more so than with developers. Just because you programmed in Java for 5 years does not mean that you have done it recently, nor that you want to do it anymore. Developers have curious minds, they move on, their knowledge base evolves.

How about starting with:

• - What is the most interesting thing you have ever worked on? Why?
• - If you could work on anything in any company – what would it be?
• - What do you do in your spare time? Do you work on side projects?

One thing recruiters often get wrong is forgetting that hiring is a 2 way street. You have to sell the engineer just as much as they have to sell you. Don’t expect them to know everything about your company. Give them reasons to be excited.

Create a discussion:

• - We use X to do Y, what do you think of that?
• - The next features we plan to bring out is X, how would you build it?

Not only does this show you what they know, you can see how they think. Some of the best people we have hired instantly told me that they disagreed with some of the things we were doing, and explained how they would fix it.

If you are hiring for specific skills:

Some testing is required. Many people like to overstate their abilities, and if you are a very small team trying to build things fast you have less room for error. Have at least one technical interview, maybe ask for that favour from a friend. It doesn’t need to be so thorough it’s an insult, and it should come relatively early in the process. We do ours straight after the phone / skype screen. All you need to know is – can they hit the ground running?

The Last Question:

How do you test motivation? How do you know someone will actually be engaged? Can you make sure they will be as passionate about this as you are? In short – you can’t! But you can get a good proxy. The last question I always ask:

• - What do you want to work on here and why?

Before I ask, we let the candidate spend half a day with the team they would be working with with no specific instructions. They can ask anything, learn anything. The inquisitive mind will latch on, the gears start turning, they see opportunities. The great ones answer that question instantly.

Slow down, slow down some more.

Let’s jump forward a little bit. You have a prototype, interested customers, you raised a round. Time to hire lots of people and build the next unicorn! This is where most mistakes are made. This is how you ruin your culture, make bad hires, waste investor money, and ultimately fail. Have you noticed how the great success stories often manage to do so much with so few people? The most impressive founders I have met hire extremely slowly, they are very picky. Each new hire should be the best in the company at something. Hiring that person increases the overall knowledge pool. You can wait a very long time before you need to hire 2 of the same skill set.

The airport test

An old friend once told me that his final barometer on hiring was the airport test: imagine yourself stuck in an airport with your flight delayed by 6 hours and this person is flying with you. What do you imagine those 6 hours to be like? I doubt it’s their technical skills that your are thinking about. Every person adds to your company’s culture. If you have bright, driven individuals that love what they do and the people they work with – they will figure stuff out, and they will put in the hours to make sure they do. Someone who does not fit in, no matter how knowledgeable, will eventually leave. Or worse – whine, complain, spread negativity and poison the culture.

Hire people not skills.

Image Credit: Kelley Bozarth / Unsplash.com