Employees are your most valuable resource, and your success ultimately depends on theirs. It’s crucial to provide them with the right tools, a comfortable work environment, quality mentorship, and a clear, compelling vision that highlights the importance of their efforts. However, their ability to achieve both current and future goals also depends on their talent and skills.
I recently lead on the recruitment efforts at ChaseLabs and wanted to write this post to share some of my experiences and learnings from this undertaking. Many of the ideas in this post are inspired by McCuller’s (2012) book “How to Recruit and Hire Great Software Engineers: Building a Crack Development Team”., and rather than re-hash the structure of this book, I’ve opted instead to write up five (extremely opinionated) “lessons” I have learned about hiring software engineers.
Lesson One: Set Your Sights High
Do not hire anyone but the best. I made this mistake in my first start-up by hiring a part-time Fiverr engineer to do some basic work. Not only did their shoddy craftsmanship create more work for the other engineers and delay our launch, but the frequent bug fixes and diminished perceptions of quality from customers ended up costing us more.
I strongly encourage you to only target the top engineers in the market. Given how fraught with bias recruiting is, you’ll likely end up hiring someone that is below best anyway. If you set your sights low, you risk hiring someone abysmal that will end up hurting your business.
The fact of the matter is that most developers are not at all competent. Even those with several years of experience and a computer science degree often know only the basics needed for the job.
Lesson Two: Hire Friendly and Passionate Learners
What exactly makes a great software engineer? Li and Zhu (2015) sought to answer this by interviewing 59 experienced engineers at Microsoft. They found that great engineers are passionate about their work, continuously strive to improve, anticipate needs, can evaluate trade-offs at multiple levels of abstraction and are trusted and well-liked by their colleagues.
You want to hire individuals that aren’t satisfied with the status quo and constantly looking to improve themselves, their product and/or their surroundings. Such engineers typically also anticipate and build the tools you’ll need to solve the next set of goals. Your software will grow with them. Furthermore, “learner types” – as I am calling them – have the meta-cognitive skills to be able to rapidly acquire new skills, adapt to evolving technology and build new technologies to keep your products on the cutting edge.
Often you can tell when someone truly is a learner by their side projects and qualifications. Someone that knows several programming languages is also a good sign – though if they list too many on their CV, then it is likely that they don’t know any one language in any great depth. Finally, a good question to ask the candidate is what challenges they have faced. It’s easy to spot a bad answer: a bad answer, and indeed what most candidates give, discusses what they should know for the job anyway. A good answer will extend beyond the job specifications describing not only what they did to learn the skill but also the intricacies involved.
Finally, great engineers also positively impact teammates. This boils down to being a reasonable person, being a good leader, communicating effectively and being trustworthy. They create a safe environment where other engineers can learn and improve from mistakes and situations without negative consequences. They also create a sense of shared success for everyone involved, possibly involving personal compromises. They appreciate the collaborative process involved in software engineering and get everyone making decisions aligned to a shared goal.
Lesson Three: Don’t Ask Pointless Questions
Too often in interviews I’ve heard: “tell me about yourself” or “tell me about your recent projects” or other redundant questions. Answers to such questions are usually a rehash of their CV, and are accompanied litany of buzzwords that are distracting, irrelevant and take up valuable time. When interviewing, your goal is to find out whether the candidate can communicate clearly, whether they can code and whether they can create and think about algorithms. As I said before: most engineers are not at all competent. You want to give yourself as much opportunity to identify which candidates can merely talk the talk and which are actually good.
I recommend spending 90% of the interview asking technical questions. In fact, in the last round of interviews we did at ChaseLabs, the only non-technical questions, across two rounds of interviews, I asked were:
- What led you to your decision to apply for this role?
- What was the most challenging technology you had to learn to use for your work? How did you go about mastering it?
- Do you have any questions for me?
(For full transparency, these weren’t the only non-technical questions asked. Our CEO also met with the candidates to learn more about their personality and cultural fit).
Lesson Four: Hire The Right Style of Engineer
By the right style of engineer, I don’t mean a job title or skills – that is a given – but more a personality type. There are different attitudes and perspectives to software engineering and knowing and taking advantage of your team’s work styles will help you hire effectively. Here are a few different styles (taken from McCuller’s book) to help illustrate what I mean:
- Cautious Style: patient and carful, these engineers excel at thinking out and planning projects in details.
- Quick Style: fast and furious, will leap into action, building first and asking questions later. Great at building MVPs.
- Adventurous Style: innovative and curious, will try new techniques right in the middle of a project to learn about it and see if it helps.
- Perfectionist Style: insist on standards and a high level of code quality – will create thorough unit tests.
I’d like to stress that all these styles are good. None is “better” than the other, and the optimal team will have a good mix of each. When hiring, consider the stage of the company, the existing engineering teams and any upcoming projects and decide on the kind of engineer you’ll need.
Typically, working in a start-up you’ll want a creator type engineer – someone that works quickly and creatively. They will also form the core culture of the team, so communication skills are especially important. In more established organisations, with several thousand, possibly millions of customers, you may want to look for an optimiser type engineer that can design robust, data-intensive applications that meet your system’s demands.
Lesson Five: Create a Candidate Guide
Software interviews are a nerve-wracking and exhausting affair. They typically span multiple rounds over several weeks, and demand (if you’re doing them right) a high level of challenge.
Not only that but interviews are also the first opportunity you get to establish a favourable reputation with your potential employees. It is therefore crucial to treat all candidates with respect and dignity, making their experience as comfortable as possible. In short, treat candidates as if they were customers.
One way to help with this is by making the interview process as transparent as possible. Create a two-three-page guide that tells the candidates what they can expect at each stage of the interview process. The guide should seek to reduce confusion and answers pre-emptive questions that otherwise consume time. You should send candidates this guide either after they have submitted a CV or before your first interview.
Message me on LinkedIn you’d like to see what we sent out to candidates for our most recent round of interviews.