Engineering is much more than just writing code – it’s about improving a system. By re-engineering our hiring processes, we can bring much-needed efficiency and results to the system.
I’ve either been a team lead or a manager for much of my career. But every time I go through the hiring process, I always secretly hope the industry has gotten better at it since the last time. It’s usually like Charlie Brown, Lucy and the football: I’d see lots of positive signs – like people discussing whiteboard coding – and was left flat on my back in pain after each encounter. I don’t believe this is intentional.
In my experience, it goes something like this: I have an (approved) role I need to fill, so I contact Human Resources and give them a list of requirements and desired skills. I then wait as the recruiters send dozens of cold InMails or regular emails to people who may fit the profile, in the hopes that they’ll get lucky and find that person who just happens to be looking. Or we post the opening on a job board somewhere and get flooded with resumes of folks who aren’t even in the right field, let alone being the right person for the job.
In spite of my faith in the intent of the hiring process, as an engineer, it’s a system that makes little sense. And as an engineer, I know the system can be improved. The inputs to the system should be more consistent. The outputs from the system of people we hire should not be highly variable. We would not accept highly variable results from, say, the car manufacturing process – and we should not accept it from a process that will result in people with whom we’ll work 8+ hours a day.
To begin with, we need to set up our system with good inputs. By this, we mean better than random contacts from a recruiter. There are many different possibilities to capture these inputs. For instance, any good salesperson will tell you that sales is about relationships. Well, recruiting is sales. It’s about the candidate selling themselves to the company, and vice versa. Therefore, we should leverage relationships to get good inputs. How?
Referrals are a great way to leverage relationships as they are literally the product of relationships! Your employees already know who is good in the industry, and who would want to come and work with them. They can do the job of selling the potential candidate on the company and the role much better than some random hiring manager because they already know the prospect.
The biggest mistake a company can make with referrals is to try and save money on the referral bonus. When it’s common practice to pay an external recruiter a $25,000 fee to email random people online if one of them gets hired, it makes no sense to pay a $2,000 referral bonus to your own employees to bring in vetted talent with whom they’ve worked before.
Internships are another great way of finding talent. Much like referrals, internships can be beneficial to both the intern and the company. The intern gets very valuable experience working on a real engineering team and the company has an opportunity to evaluate talent in real situations (as opposed to a typical interview process) with little risk. The interns will almost always make less money than a regular employee and all internships are time-boxed by school commitments and the conditions of the internship program. I’ve seen internship programs work so well that there was a seemingly endless supply of junior engineers available to join the company at the conclusion of their studies. The company also has the ability to extend offers to only the top engineers who had often been back for multiple internships as part of the program.
Not all candidates make themselves known through traditional methods for any number of reasons. That doesn’t mean there aren’t very good candidates out there who, when given an opportunity, can contribute in many ways and are often supported by a network behind them. There is such a shortage of qualified engineers available that not exploring non-traditional avenues would be foolish. Setting up a relationship with a bootcamp or an organization like Code2040, Techtonica, Hack the Hood or Year Up can give any organization access to talent that may otherwise go unnoticed and untapped.
Diversity and inclusion
Many of the organizations listed above are major proponents of diversity and inclusion in the tech industry. Some companies are interested in diversity and inclusion for social justice reasons, some to be able to attract top talent that can be very difficult to sign if no one at the company looks like your prospective candidate, and some because they want to build the best company they can. There is overwhelming evidence that diverse teams simply perform better on a number of vectors. Regardless of how many of the reasons are important to your organization, diversity and inclusion are a very important part of having successful inputs and outputs in your hiring process.
Regardless of your method for ensuring a consistent input to the system, it’s important to have clarity about what you would like each new employee to contribute to the team. Post the jobs on your company’s job board, announce the open positions during all-hands, talk to the members of the team where the new employee will join and, in all cases, make sure you know what you’re looking for. That will greatly increase your chances of success as you bring candidates through the process.
Once you have a good candidate in mind, the entire purpose of the process is to build increasing confidence in the extension of a job offer. In other words, the further down the pipeline the candidate goes, the more confidence you should have in extending an offer. You do not want to continue to spend time on candidates who will not get an offer. It’s disrespectful to the candidate and it’s disrespectful to your interviewing team.
Each company and culture will be different. The process I describe below is the result of years of hiring and I’m describing it to provoke thought and discussion about your own hiring process. In a nutshell, this process applies the First Way of DevOps (systems thinking) to the problem. You want to optimize the process from beginning to end in order to maximize the flow of work (candidates) through the system.
The first contact with a candidate who has agreed to enter the process can be handled by a recruiter or by the hiring manager. If it’s a recruiter, it can be to answer basic questions about compensation ranges, benefits, etc. It can also be a very basic screening if you are lucky enough to have more candidates in the pipeline than you, as the hiring manager, can realistically handle yourself.
If you give a recruiter questions for an initial tech screening, you need to be as blatantly specific as possible. If the recruiter is not technical and you leave any room for interpretation, you’ll end up with more work than if you just did it yourself from the start.
- Firefox, Mozilla, and Safari are all examples of what? (web browsers)
- In programming, “for” and “while” are examples of what? (loops)
- What is the difference between a map and an array?
- Explain how the Domain Name System works.
The bad examples require either specialized knowledge or nuanced understanding on the part of the recruiter. The good examples have straightforward answers that don’t leave much room for interpretation. You might think those questions seem really simple. They are, intentionally so. I’ve had positions open for senior engineers with over 10 years of experience where half the applicants were project managers with 2 years of experience. A simple question like “What does DNS stand for?” (Domain Name System) is more than enough for those candidates to be weeded out by a recruiter, and requires no technical background whatsoever.
By the time they get to the hiring manager, you’re trying to both evaluate if this is the right candidate as well as sell the candidate on the position (and by extension the company). If you are a larger company, you will usually talk about the benefits, the ability to focus on a specialty and growth opportunities. If you’re a smaller company, you’ll usually talk about the ability to have a big impact, to learn many things in a variety of areas, and to grow toward a leadership position within the company. [Note: this can be technical leadership. If we are hiring engineers, it is best not to try and sell them on a completely different job, such as people management.]
Talk about who they’ll have the opportunity to work with, tell them how they’ll be supported in their role. The process of changing jobs carries with it enough stress that anything you can do to make it less stressful and more informed will put your position closer to the top of their list.
When evaluating the candidate, this is the time to understand their background. One of the most important questions you can ask is “What would you like to be doing in your next job?” This shows the candidate that you care about their careers and you’re not just trying to put a body into an open slot. There is typically a lot of flexibility in a position, so you want employees who are active and engaged. This is much easier to do when people are working on things they find appealing. An old boss once told me that “anyone can hold their nose and do something for two months.” But what happens after two months?
One of the biggest lessons I’ve learned while recruiting is to communicate. We’ve said many times that hiring engineers is part sales. The best sales are built on relationships and communication is key in any relationship! I have had candidates tell me that the reason they picked the job I was offering was because I moved quickly and communicated clearly throughout the process.
The first contact is an excellent opportunity to explain the complete hiring process to the candidate. If you’ve thoughtfully constructed your pipeline, you know exactly what happens at each stage. As the candidate progresses from stage to stage, it’s important to keep them updated about where they are in the process.
Even if you don’t have an update, let them know “I don’t have an update for you, here’s where we are at the moment.” If you start to build a good communication pattern with a candidate early on, that can only help benefit your relationship if they become an employee. There are a lot of horror stories about companies that have “ghosted” candidates, only to reach out to them weeks or even months later. At best, that makes candidates feel like a low priority. At worst, it makes them feel like an afterthought, and it’s unlikely they’d ever consider or recommend working there.
The coding test
The coding test this early in the process? If you’re hiring engineers, they’ll need to write code. Even infrastructure engineers need to write code these days. If you’re hiring engineers and don’t have a coding test yet, now is the best time to develop one.
The coding test should be reflective of the actual work. Does the day-to-day job of the person you’re hiring require them to regularly implement a bubble sort from scratch off the top of their head? If not, don’t test for that ability. The object of the test is to assess the ability of the candidate to write clean, functional code that can be maintained over time. It is not a time to determine their ability to recall minutiae. Ask them to write tests, ask them to implement a procedure that’s a common part of the job…but don’t test some obscure piece of knowledge from your college computer science classes. It’s not Coding Trivia Night at the local pub.
If the job doesn’t involve coding on a whiteboard, neither should your test. I don’t believe there are any whiteboard coding jobs out there, and this practice needs to end. Now. No professional software engineer writes code without an IDE anymore. Unless your whiteboard has tab completion and syntax highlighting, asking someone to write code in a completely different modality tests nothing more than someone’s ability to write code under 100% artificial conditions. That time could be spent in much better ways, so save the dry erase markers for conceptual work, like architecture diagrams and keeping track of areas of a problem to be discussed. Not code.
If the job does not involve someone watching you code, neither should your test. If your company has a well-developed pair programming discipline, this is a great time to introduce your candidate to that practice! I once interviewed at a well-known company where part of the interview was to work with another engineer off a real task from their queue. I had to look things up, write some code, discuss my thoughts and work side-by-side with an engineer to solve the problem.