cover

If you are in a fast growing tech startup, you’re probably actively interviewing and hiring engineers to scale teams.

My question to you is, what hiring strategy are you using when interviewing engineering warriors?

This post explores some intriguing concepts that are formed behind hiring processes for engineers and how these concepts shape processes to increase your probability of hiring that one good engineer.

I have spoken with more than a hundred engineering leaders in tech companies about how they hire. I’ve asked them to share their thoughts with me on the most important factors that they look for when hiring a good engineer.

This is what I found.

1. Technical Fit vs Cultural Fit

“An engineer’s technical fit can be around 80% for our ‘on the job’ requirement. It can be difficult to find a 100% fit, and for those engineers who have some gaps, it’s personally motivating for me to have this opportunity to help the engineer achieve, and close the gaps”

- From a 15 years experienced senior leader in tech who has managed teams of up to 30

It would surely be on everyone’s wish list to hire that engineer who has a perfect technical fit, but most of the time we don’t get so lucky. Certain factors play a part in this equation, e.g. your team’s location in a place where the pool of candidates could be of lower quality, the nature of your product may mean that you may not need such a perfect 100% technical fit, or because you are lean and you don’t have the luxury to wait.

However, there are many different reasons to why an engineer who isn’t a perfect technical fit may be right for your team. One of the most important factors to assess when you cannot find the right technical fit is love. Does the engineer really love what s/he does? Do they try to do more than others and really push themselves harder? Do they want to work with the team and would they feel empowered?

“The fit I’m looking for includes having an appetite for risk taking and innovation. The people to hire should be someone who brings good ideas, someone who is also good at execution, who wants to challenge the status quo … and this person is incredibly hard to find!

- From an Engineering leader for backend teams in an on-demand, media streaming platform

Ultimately a good engineer is someone who is excited by things they do not know and is willing to learn. These engineers typically have the ability to:

  • Step forward without letting overthinking and over-analysis bite you… to not get distracted and mired by obstacles.
  • Iterate code, fast (bias for action that is scalable and proves to be so, over time, as opposed to quick-fixes).
  • Produce nice, clean, readable and debuggable code.
  • (Sometimes) take a deep breath and see the full picture.

So which is better, technical ability or cultural fit? In reality it’s about finding the best balance for you and your team.

2. Finding the “Smartest” Engineer

“I ask them if they have participated in hackathons and examine their CV closely to see what kind of career moves they have made. Were those decisions progressive? Did they look for opportunities to learn and grow? I check how they would solve problems and reach solutions.”

- Acting CTO in an autonomous vehicle startup

Many confident managers and leaders make it their goal to hire the smartest people they can.

A good question to ask yourself at the end of the process can be: For this person who is being hired, are they raising or lowering the average bar? In this scenario the goal is to make the team better. Really smart engineers are able to turn $1 million-worth complex problems into $100K simple ones. When this happens, whether or not the problem is able to be solved becomes far less important.

To be an expert in everything is not required. In order to make your team better you need engineers to be smart in different ways.

3. Finding the “Knowing-Asking-Learning” Engineer

“I look for candidates with deep understanding of the tools, technologies or problems that s/he has worked on before. I look for passion and ability to learn, as technology is changing at a greater pace than ever before, we need candidates who can and will keep expanding their knowledge. I look for candidates who can bring something different to the table so that the team can have a diversity of skill set, experiences, points of view and backgrounds.”

- Engineering leader of teams operating in Systems Reliability, Databases and Data Engineering, in an Asian ‘unicorn’ technology startup

This engineer has a deep understanding of knowing how it’s done and exactly why it should be done in this way. When they do not know, these good engineers will ask why, and keep asking why. You see they want to learn why people use particular technologies and why particular algorithms are being used for this solution in order to understand how deeply this solution has been thought through.

If you hire based only on what an engineer knows right now you ask questions like these:

  1. How long have you been coding in Ruby/Python/Golang/Javascript?
  2. Explain how XMLFilter works in Java?
  3. What is the default size of a Java HashMap?

In order to get better insights then you should consider following up with this:

  1. Tell me why you did this.
  2. Then keep exploring the ‘why’ angle!

Sure, this takes a bit more effort on your part, but you will actually be assessing their aptitude and future potential of the engineer.

The Recipe So Far

quote

So, we explored concepts of hiring these archetypes:

  • Technical fit vs Cultural fit
  • The Smartest Engineer
  • The Knowing-Asking-Learning Engineer

Experience + coding ability + knowledge + ‘more than knowledge’ + love + … could this be the equation ?

The Real Magic in the Recipe

Getting good engineers into your team is critical to your success. It also takes time, and effort, and teamwork, and having a good plan.

The good engineer you hire eventually, ends up being 5x or 10x more productive in your existing environment.

It is important to start off with the right concepts, if your first few hires are not good engineers, you may eventually end up with a team of 100 no-good engineers.

Good engineers are able to debug problems better, think of solutions better, understand a programme faster and assess potential impact and implications faster. They also will be likely to write bug-free code, consistently.

Overall, they will help us to figure out how to make others on their team better engineers.

Programming = Problem Solving.

Yes.

And now it is decision making time. 😊

Names of people interviewed are omitted to retain confidentiality.