Reading Time: 7 minutes
When I took over as CTO at SupplyHub, I also took charge of hiring additional software engineers as well as managing our existing team. To bring structure to our hiring process, I’ve made use of methods that have brought us great additions to the team, while allowing us to stay focused on our daily engineering tasks.
This article summarizes our current approach for hiring developers. With growth, SupplyHub’s hiring process is most likely going to change in the future. But our current approach for acquiring new talent works well for us now, as it gives us a better assessment on their skill set and how the candidate would perform in the actual work environment. The biggest win for the candidate is that it shows them what kind of environment and on what type of services and problems they would be working on.
In an effort to standardize our hiring process, I use these rules:
- Set a high bar for quality
- Assess candidates objectively
- Give candidates a reason to join
You can find more about these points in Chapter 5 of Work Rules! by Laszlo Bock, which we are focusing on from a company standpoint.
At this point in time, we’re requiring that new hires be productive as soon as they join the team, yet we still want to help candidates become better software engineers. We want our candidates to feel like they were treated fair by making them self-aware of their performance.
The Hiring Process
Round 0: Weigh In
This is an optional step that consists of “selling” a potential candidate to the company. This step usually consists of a phone call between our CEO and a candidate with multiple offers to explain where our company’s at and where we’re going.
If you’re after entrepreneur-minded talent, you would want to invest in a conversation between the company’s visionary and the candidate.
Round 1: Challenge
Our code challenges are public. Anybody can take them at any time. Sometimes recruiters really want us to talk to their candidates first (see round 0), but there’s no way around doing at least one of our code challenges.
We came up with several code challenges that are closely related to what we’re doing at SupplyHub. Usually a candidate is asked to complete just one of the code challenges, though occasionally we do ask for more.
The challenges are of a difficulty level that makes them too hard to finish in a reasonable amount of time for the skill levels we can’t support at our company right now. After an initial solution of this challenge, our engineering team interacts with the candidate for the first time.
Granted, coming up with a good code challenge will take some time, but the payoff is enormous. For example, let’s talk about one of the challenges that we require front-end developers to do.
We provide the challenger with a description of a functionality (i.e., product search) to accomplish. Currently, daily tasks for a front-end developer at SupplyHub involve consuming a RESTful API. Therefore, we provide an API endpoint and documentation to the challenger. We supplement key points on functionality with a visual example on how a complete solution could look. There’s also a bonus point section, which unfortunately rarely gets any attention. It’s not mandatory for the code challenge, but we expect the candidate to at least recognize what we think is important to list in this section.
Having candidates do the challenge as a first step in the hiring process has many benefits. For developers that are also tasked with hiring decisions, it’s a huge time saver. For example, I don’t look at resumes before the candidate has completed the challenge. Aside from being able to work on more pressing tasks, not looking at resumes can prevent biases. Everybody should get a shot at becoming a team member.
Of course, we still want to see resumes after we’ve seen a successful completion of the code challenge, but the resume itself does not play a role in making a hiring decision. It’s solely for informational purposes for the on-site interview, to be able to ask a little bit about the candidate’s background and what they like to do best.
Round 2: Phone Interview
Before we had the code challenges in place, I was responsible for holding technical phone interviews. Without the candidate first passing a code challenge, the phone interviews were time consuming and unfortunately all too often a waste of time for both me and the candidate. Candidates that made their current skills sound much better than they were in reality and passed the resume screening would fail miserably.
After we started requiring candidates to do a code challenge on their own time, we stopped doing these phone interviews for a time. However, we brought them back as one non-local candidate passed the coding challenge with flying colors but were put on the spot in the on-site coding part, which is described in the next section.
Usually the candidate has a solution ready within 15 minutes. Even if it’s the most incoherent (non)solution I’ve ever seen, I’ll give the candidate time to explain what they were trying to do or why they chose that solution. It’s also a great time to talk about technology and the good things about the company I’m working for. At this point, it’s more of a friendly chat between developers.
Round 3: On-Site
The on-site interview now looks vastly different compared to when we first were interviewing people. If the candidate wasn’t cheating during the previous phases, the two hours on-site are usually the nicest for the candidates. As the CTO, I greet the candidate, and we talk in our “cigar room.” It’s a quiet room with nice couches and a relaxed atmosphere, designed to make the candidate comfortable. (It also has a picture of a cigar on the wall, hence the name.)
Anywhere between half an hour to a full hour, I’ll get to know the candidate and answer questions about the company, the work, or myself. There could be a technical discussion or none whatsoever. The purpose of this chat is to get the candidate comfortable and also get a feel for whether or not the candidate’s personal goals will fit into the daily business of the company.
Finally, I’ll introduce the candidate to our team and hand them over to one of our mid-level or senior engineers to walk through the coding challenges to be solved on a computer with the candidate’s favorite code editor installed.
For the positions we are currently hiring (front-end developers), the first challenge consists of creating a reusable web component/directive that consumes an API end-point. The candidate can choose between Angular, React, Polymer, or Vanilla JS to accomplish the task. The candidate can consult documentation and ask questions of our engineer.
Should the candidate solve this task, they then get the chance to work on an older version of our production code. With a couple of simpler tasks, we can observe the candidate’s abilities to work with an existing code base and find their way around. Since we’re looking for people who can get started immediately with smaller tasks, this step is very important to us.
While the candidate is still working with our engineer on solving some challenges, I’m letting the CEO know that we’ve got a real candidate here, and we’d like for him to meet with the candidate. Meeting with the CEO is a really good sign. While our candidate is in this final interview, I look over the code that the candidate has produced and get the feedback of the engineer who oversaw the challenge.
If all involved parties give their okay, then the CEO will make an offer to the candidate.
Of course, no two companies are alike, which means every company has different hiring needs and process. Where do your methods differ? What steps do you include, take out, rearrange? Be sure to tell us about them in the comments.