Making Onboarding Part of the Interviewing Process

Problem

For many, interviewing and onboarding are two distinctive and separate parts of the hiring experience. This approach makes onboarding difficult and lengthy while the risk of poor fit becomes omnipresent. If, on the other hand, the interviewing process is structured to include real-life exercises that would require intensive interaction with the team, onboarding will be not only smoother but faster too. People on the team will be already familiar with a new hire and their working style. In addition, when the team as a whole is involved in the evaluation as well, the risk of having a person who will not be able to sync with the rest of the team will be significantly reduced.

Actions taken

Once you create a solid pipeline that supplies you with a sufficient number of candidates who match your requirements, you are ready to start scheduling interviews. During the first introductory call, you should learn what motivates a candidate, what are their competencies and experience, what programming languages and tools they are knowledgeable about, etc. If you can’t establish a match during the initial call it is meaningless to proceed any further. However, HR people who are usually conducting these calls are often not trained to communicate technical matters with developers and are unable to assess their technical competencies. Therefore, I prefer the first call to be done by someone in a technical role because only people who can assess developers are developers themselves.

Evaluation should be based on exercises that resemble as much as possible real-life situations. I would usually come up with a use case and work together with a potential hire to solve it. The purpose of the evaluation should not only be to assess someone’s skills but to understand if you want to work with this person and the best way to assess that is to experience working together. For that reason, I would arrange for pair programming sessions on three different problems with three different persons.

The first one should be on algorithms. I understand that this is somewhat questionable because there are people who are not good at algorithms but do decent coding, but my experience tells me that people who are good at algorithms are good at everything else. Thus, not excelling at algorithms is not an eliminatory but rather signaling criterion.

The second session should focus on a programming language as a developer’s main tool. Programming is much broader than using any specific language but I prefer to assess how much a candidate mastered the basics of the language and its standard libraries. To evaluate that I would take a simple program with less than 100 lines of code that is working well and then I would ruin it by introducing common bugs and different examples of bad practice. A candidate would be asked to fix the code -- first to make it work (to fix the bugs) and then to improve the existing code. Improving the code is revelatory on multiple levels -- of their skills, the company culture they are used to, past experience in terms of developing the great code, etc. It also helps me assess where their bar for quality is and what in general quality means to them.

The third exercise is a platform exercise. We would take an existing application and spend an hour together working to implement a new feature. Simple, but brand new. I always do this through pair programming. If a person doesn’t know something they could always ask me or look for it online. While the first two exercises are quite academic this one focuses on the ability to ship working code fast.

This approach helps me evaluate hard and soft skills simultaneously because through pair programming these skills tend to become more interwoven. Instead of asking “how would you solve a problem” you will put them in the actual situation of solving the problem.

Finally, making the decision shouldn’t be on one person alone, especially because most candidates will fall somewhere in between. Having an automated process for making that decision is highly recommendable. I would ask everyone who interacted with a candidate to deliver to me a written evaluation with a clear yes or no at the end. They should score (1 to 10) candidates but will also have an opportunity to veto a potential hire. I would come up with an average score and that score should be above what we have established as our benchmark.

The whole interviewing and evaluation process is structured in such a manner that even before a new hire arrives, they are approved by their co-workers which makes onboarding much easier. Since a new person would spend time working with different people on the team during the interviewing, the team would have an understanding of a person’s skills and competencies before they would start working together.

Lessons learned

• In many places hiring means that a leader would make the decision without introducing a new person to the team. That will not only slow onboarding but may result in interpersonal conflicts and early churn.
• Dedicating enough time is crucial. This should not be done after business hours because candidates and evaluators could be exhausted and won’t be able to show their best. It also means that I have to take some of my developers off projects so that they can focus on evaluation.
• In my experience, through this process, I have only hired around 10 to 15% of the candidates. Exercises are not hard but half the candidate would lack some basic developer skills and the others would not fit well with the team.
• While raising the bar -- as I did -- makes it harder to find a sufficient number of candidates, it dramatically improves the efficiency of the team you build.
• This approach has a high conversion rate, the candidate rarely declines the job offer after this kind of recruitment process.
• Fast hiring is one of the mistakes many startups are making. You can’t just hire -- and hire fast -- because you need more people. If nothing else, thoughtful interviewing will make onboarding much easier.