Adapting your company hiring process to your needs
If you've tried to hire software engineers recently, you probably noticed how hard it could be. We see the tech market is hotter than ever, and it's not news that the information technology field is growing fast. Companies are facing difficulty hiring senior developers, but I don't believe this is 100% related to the developers' shortage.
In this issue, I'll share what has worked for me and the companies I've worked for when you need to build your hiring process. I'm going to focus on the technical aspects of hiring. I won't cover how to avoid biases on candidate selection (although it should be a high priority within any hiring process), nor get into the engineering manager hiring process since I don't have much experience on hiring managers yet.
Software Engineering hiring process
Before you start thinking about hiring, you need to make sure you need a new person. The overall recruiting process is expensive, and it will take up a lot of your team's time. Discuss priorities first, hire if needed. I've seen companies expand their teams to solve a particular project, and they end up having nothing to work on a few months later. Therefore, guarantee you have sufficient work to occupy the new hire.
Assuming you've assured your need for adding a new member to the team, you must define the structure of your hiring process. The typical hiring process must evaluate an engineer's ability to deliver high-quality software, which can be achieved in many ways and varies a lot from team to team. Due to this nature, other software engineers must be involved in choosing the best methods to use in the company's process.
First, it's essential to list the skills you need from the candidate. This step is critical to both the hiring process and the job post you'll probably publish to every social media out there. With the skills in mind, you can evaluate those and be more accurate.
Quick tip on this. Try not to list technologies in an endless list since it's probably unnecessary to find someone that knows 100% of your tech stack, so concentrate on the most important ones. I prefer focusing on the skills that would complement the team rather than the skills the team already knows and use daily, but either works well.
Given what I said, it's easy to imagine that each company should create its own unique set of interviews to find the best person. But the software development industry has been using a set of standard processes for a couple of years. So I'm going to use the ones I've seen so we can explore how you can adapt what the industry already uses to best suit your specific needs.
Common hiring processes
Whiteboards
The first process is the one used by big tech companies. It looks like this:
- Computer science knowledge assessment
- System design interview
- Cultural fit
It starts with a set of computer science knowledge interviews, such as algorithms and data structures (the interview can happen over the phone, a video call, on-site). Usually, the interviewers give the candidate a problem, and they can choose any programming language to solve it. The idea behind this process is to identify the candidates' ability to solve challenging problems. And although it's crucial they get to a correct answer, I would say it is more important to analyze how they communicate their thought process. After all, the candidate will probably collaborate with other engineers if they join, so it is vital to pay attention to how they talk about/solve problems.
Then, it moves to the system design interview. The interviewers will likely state an architectural problem for the candidate, and discussions start there. The interviewer will evaluate the candidate from the questions' quality to specific technical skills. The focus of the interview will likely vary from team to team, but topics like separation of concerns, scalability, maintainability, performance are expected.
The last part of the process is the cultural fit. The candidate will be put on different occasions and questioned on how to handle those. It goes from preferred work style to team collaboration and even personal principles. For example, if the interviewer is a company manager, they would probably ask about your career expectations to look for a match.
Overall, this is one of the most common processes I've seen. Of course, the difficulty changes greatly depending on the company, but the structure is pretty much the same.
Take-home project
Startups generally use the second process I've mostly seen. It's not very different than the first one in terms of objectives (the engineering team wants to validate pretty much the same set of skills). Still, instead of using the standard whiteboard interview, it uses a take-home project.
The take-home project is a set of requirements the candidate needs to implement. Expectations can vary, but a working solution for the problem is required. In general, the project implemented by the candidate guides all the technical interviews. If it covers enough, the candidate can be asked to extend the project during the system design interview, where the interviewers can explore more complex topics.
Process customization
I've participated in adapting a few hiring processes in two different companies for various reasons. I'm going to go through them as examples.
From take-home to GitHub profile
In company A, we used a take-home project to guide the interviews. Candidates had to build a small micro-service that would hit two public APIs and combine their results. We had a document specifying the requirements and business rules of the exercise. Then, the candidates could choose the technology they want to solve it. But after a couple of months running this process, the team realized we were losing experienced candidates between the first HR interview and take-home project. They would receive the requirements in their emails and never answer back.
We managed to gather feedback on the process from a few candidates, and surprisingly they said the project was exhaustive but straightforward. It would simply take too much of their time. One specific candidate said we should browse through his Github profile to see that type of project. And after discussing this internally, the company decided to use what this candidate suggested going forward.
For the more experienced engineers with a good portfolio, instead of sending a take-home project, we had two engineering team members analyzing his profile to check basic coding skills. After this short process, the candidate would go directly to the next phase, a system design interview.
Of course, without the project to guide it, the team had to develop a specific problem statement to cover what the company needed during that interview. But they were based on the company's real problems, so it wasn't hard to put it together or train the interviewers to use it. And although this strategy worked for experienced engineers, we couldn't apply it to less experienced ones because we wouldn't have enough data on their coding skills.
Specifics skills assessment
I moved teams within company A and kept using the same hiring process as the team grew. It turned out it wasn't working. This team used different technologies for each project. We had new challenges every quarter, which required a new set of technologies. It was a unique team and finding someone who would fit well in this environment was challenging. We needed someone adaptable, comfortable with ambiguity, and a fast learner.
In this scenario, the team decided to use take-home projects as part of the hiring process. But this time, we tried something different. Instead of building a micro-service as we were previously doing, the candidate had to build a small library that would read data from a file system and output it in different formats. It was a small task that would probably take 2 hours to solve.
We then changed the system design interview. It wasn't a system design exercise but rather a live implementation one. The candidates needed to extend the project and make the library read data from a database instead of the file system. We usually tried to choose one the candidate had never worked with, but we only had their resumes and previous interviews as inputs.
In this exercise, we could see how the candidate would react to new technology, what kind of question they would ask, and how they would solve the first error. It was an exciting approach, and I was surprised to find great engineers with it.
Hackerrank for the rescue
Reviewing take-home projects can be time-consuming, especially if your company is starting to grow and putting more effort into the hiring front, which was what was happening with company B.
The process was a typical take-home project followed by a system design interview, and finally, the culture fit one with an engineering manager. The project had a medium size, candidates had seven days to work on it, reviews usually took 2 to 3 hours, and we always had two engineers reviewing each project.
Eventually, we spent many hours weekly reviewing candidates' projects, which delayed strategic goals. The engineering team decided then to switch the take-home project with a Hackerrank exercise. First, it was a coding problem to make sure the candidate could code (it would be considered an easy one in platforms like Leetcode), followed by a set of questions about software engineering practices, databases, and distributed systems.
A few weeks after the switch, we saw the number of dropouts decrease, and feedbacks about the process were better. Consequently, the change increased the number of candidates moving to the system design interview, which then increased the responsibility of the interview. So, on the other hand, the interviewers needed to cover more topics to be sure about hiring the candidate. In addition, the interviewers had to guide candidates to demonstrate the skills that project reviewers could previously assert during the take-home project phase.
Early age startups
Let's say you are responsible for hiring software engineers for a startup. The company is likely to be working on the MVP (validating the product) or with an initial validated product but only have a few customers.
In this case, I wouldn't use the big tech hiring process. Usually, computer science knowledge is not that important in an early startup. You don't need to worry about algorithmic performance when you are not in the scale phase.
I would instead find someone passionate about the product or who has product-building skills, like conducting a user research interview. With that said, I'd use a set of interviews to assess behavior rather than specific technical knowledge.
Note that I'm not saying you don't need to validate the candidates' technical knowledge. You probably need someone that can solve problems by themselves, and I believe the tech side helps considerably. However, you could give more points to candidates with skills according to your needs.
Selling yourself
Remember, during the interviews, you are not only evaluating a candidate's skills, but you are also selling the company (or even the team they will be joining). You must convince them it is a good idea to join. Be transparent about the company, and obviously, don't lie to candidates. If they enter, and the company doesn't meet their expectations, people will leave because if they are good, they can probably join almost any company they want to. A few suggestions on what to cover when selling yourself:
- What will they be responsible for?
- What projects will they be working on?
- Who are the people on their team? Are they experienced? Can the candidate learn and grow with them?
- Why do you think the candidate will be an excellent addition to the team based on their skills?
Bottom line
Maybe you are not hiring because you don't have the proper process. If you think you can improve it somehow, give it a try. You don't need to change everything overnight. Start small. Test your ideas with a small group of candidates before adapting officially. And always ask for feedback from past candidates.
Be aware that there is no silver bullet hiring process. If you are somehow responsible for recruiting in your company, you should review your current process from time to time to improve and adapt it to your everyday needs. You shouldn't copy other companies hiring processes just because they are successful.