Tips on hiring for an engineering team
Over the years I have been involved in hiring for both the teams I have led and for other teams in the organisation. Despite having done tons of hiring interviews, I do not consider myself a great interviewer. Often I find myself less than 100% sure when deciding whether to pass the candidate to the next hiring stage or not. Following that here are some pointers on how to make better hiring decisions (even when you are not that great at interviewing).
For context, the hiring funnel I typically use is fairly standard: questionnaire → screening → coding home task → tech/product interview → founder/engineering lead interview
Create the team/role profile
(this is part of preparation before even starting the hiring process)
When hiring for a bigger organisation then this is typically simpler as you can focus on a narrower set of skills. Most likely you have some dedicated platform teams that complement the skills of the team you are hiring for.
However, when building the engineering team from scratch then it’s not just enough to say that you need X fullstack product engineers. In that case, I like to map out the ideal skill composition of the whole team.
Instead of hiring only generalist fullstack engineers who have all more or less similar profiles I prefer to look for more diverse skill sets. This means a few people who have frontend focus, a few who are stronger at backend, someone to lead on infrastructure and data engineering etc. Of course in a small team, everyone should be able to do multiple things but that doesn’t mean they should not have their unique area of strength.
Use puzzle-free questionnaire
A questionnaire is an excellent tool for filtering out unsuitable candidates with little effort. However, the questions should only be used to check for knowledge that is actually useful at work. Don’t test your candidates’ ability to be human compilers or know algorithm/data structure stuff they don’t need to get their job done.
For example, I don’t like questions that cover some kind of language nuance like all these Javascript == special cases. I prefer questions that are less fact-based and more indicative of their overall understanding of core concepts. If I’m looking for a candidate with good code design skills I might have a question that compares some aspects of functional programming and OO design.
Use home coding task instead of coding interview
I have to admit to having carried out lots of coding interviews through the years. In hindsight, these were rarely good investments regarding time spent/skills verified.
The coding interview environment is very different from the context of actual coding. Random things like not being familiar with the meeting room keyboard or missing refactoring support in the coding interview tool can significantly influence your evaluation.
At Wise, we did coding as part of the tech interview. We extended that interview to 90 minutes to have more time for coding but it still left only around 45mins for actual coding. Not much time to achieve anything interesting.
When building the engineering team at Clean Kitchen/Yummy we switched to using a home coding task. This enabled us to get a more in-depth understanding of candidates’ actual coding skills. It was a more pleasant experience for candidates. In addition, this way we could make the tech interview shorter.
When using the home task I follow these principles:
- keep the task simple — not more than a few hours to complete
One way to achieve that is to provide parts of the solution and ask the candidate to fill in only the missing parts. For example, if the solution requires additional data from another service or database then provide some API stubs that can be used to build upon.
- provide clear evaluation criteria
Being upfront about the evaluation criteria is even more important here than for coding interviews. For example, if I don’t say that I expect some automated tests as part of the solution then I should not deduct points for not having any tests.
- don’t allow any frameworks/libraries
For the backend coding task, I prefer not to allow any frameworks or libraries. I’m mostly interested in general code design skills, not the ability to hide behind a framework. For frontend, I tend to make an exception. If I need someone proficient in React then it makes sense to see how well they can use React. However, even then, I pay attention to library-agnostic things like naming and general code style.
- make the task related to your product/domain
Even though it needs to be very simplified, the coding task is still an opportunity to demo some concepts of your product/domain. Also, this makes it more interesting to solve than some kind of generic task that has no connection to your business.
- create a reference implementation of the home task
This serves two purposes. First, it enables you to test how long it takes to complete the task. If it takes you more than a few hours then most likely it will take candidates even more as they don’t have the context of the task in their head when starting. Second, it creates a reference point to compare against.
- ask a few questions related to the coding task during the tech interview
I have never had a case where a candidate asked someone else to do the home task (at least I’m not aware of it). However, asking them how they would update the solution if some requirement changed or asking to clarify some points about their solution gives a better understanding of their thinking process.
Consider building distributed team to hire internationally
A distributed team has many challenges but if you are OK to build your company that way then it provides clear benefits for hiring. It will allow access to more candidates with better matching profiles. All that while keeping compensation costs at a reasonable level.
At Yummy we decided to go for a fully distributed product team. This enabled us to hire 4 engineers in 7 weeks in 2021. I’m sure this is something we would not have achieved had we only tapped Estonia’s local talent pool.
