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.
If you do not have a well-developed pair programming discipline, then you should send the candidate a coding test that they can do at home in no more than 3 hours, which is a very long amount of time to ask someone to dedicate independently to your interview. The test should be straightforward with clear instructions that are continually improved over time based on feedback from candidates. At the end of the test, the candidate should feel like they were genuinely tested, so they know other employees at the company have met that bar. If the test is too easy, they’ll think coding is not valued at your company. If it’s too hard, they’ll think you’re not really interested in their success in the job.
There are some exceptions, of course. If you’re interviewing the creator of X, you don’t need to ask them to code in X. If you’re interviewing senior candidates, it’s completely acceptable to skip having them write any code. If your candidate has an extensive catalog of code in GitHub or elsewhere, ask them to recommend a particular piece of code they believe is representative of their style and ability.
Asking a senior engineer with lots of code in the public domain to jump through hoops just to check off boxes of your process is insulting to the candidate and ignores the purpose of the coding test. If they are actually a senior candidate, they will also be in high demand in the market. If they even agree to do the test, you are wasting time that could be spent on downstream stages in your hiring pipeline.
What if they cheat?
Many people raise the objection that if they allow a candidate to take the test home they will “cheat” (as if looking things up on Stack Overflow is cheating), or get someone else to write the code for them and then submit it as their own. You can certainly have a candidate sign something attesting to the fact that they performed the test within the rules. However, the coding test does not end when the test is submitted or graded.
Whether it is code they wrote as part of your test, or code they identified as their own from another source, the next part of the interview process is to review the coding test with the candidate. This most likely happens during the onsite or online interviews.
During the onsite or online (for remote candidates) we are still trying to move the candidate through the pipeline and gain confidence they will get an offer at the end of the process.
Coding test review
The first interview after the coding test can be onsite or online depending on the culture of your company. The important part of this review is to pick a piece of code to be reviewed together by the candidate and an engineer who is well versed in that language and its techniques.
If the candidate did not write the code, or does not understand the code, this should reveal itself under scrutiny. If the candidate did indeed do the work, then this is an opportunity to find out how well the candidate understands what they’ve written.
I once had a test submitted by a candidate where one of my senior engineers pointed to a method and said, “they didn’t write that method, it’s completely different than all the other code.” When pressed to explain each line of the method, the candidate was evasive and standoff-ish. After being asked repeatedly if they’d written the code and to explain what they’d been thinking in their choice of variable names, etc., they relented and said they’d copied and pasted from Stack Overflow.
That candidate failed, not because they lied about the authorship of the code, not because they copied and pasted it from somewhere else, but because they were willing to submit code they did not understand as their own. There are few things more frightening to an engineering manager than to discover their engineers are shipping code to production when they don’t actually understand how it works!
One-on-one and team interviews
After the coding test is accepted (because otherwise the process ends), then it’s time for the candidate to meet with the various people with whom they will be working. These can be members of the team they would join as well as leaders of other teams with which they may often work. The goal of this stage of the interview process is to allow the respective parties to get to know each other, to find out if this is a person with whom they would want to work.
They are trying to determine things like:
- What is it like to work with this person?
- Are they capable?
- How do they approach problems?
- How do they discuss solutions?
- How willing are they to learn?
- What is their learning style?
- What makes them feel supported? Heard?
- How do they resolve conflicts?
- How familiar are they already with a certain topic?
- What related experiences do they have?
You will notice that most of these questions are not standard engineering questions. They are to assess people’s talent and their interpersonal skills. All engineers work in socio-technical systems and ignoring one in favor of another can leave us with “brilliant jerks,” who are always a bigger drag on the organization than anything they can contribute.
These interviews can take as long as you feel is necessary to assess a candidate. If possible, you should try and have these meetings on-site. Even if a candidate will be working remotely, it’s always good for them to put faces to names (unless you have a completely distributed company). This is also a good signal to the candidate that the company is willing to invest in them and are not simply trying to find cheap labor in another market. This can only strengthen the relationship, even if the candidate can’t actually make the trip.
If you’re going to have candidates participate in a series of interviews, there are a few things to keep in mind.
Limit yourself to a just few people interviewing each prospect. It’s not fair to a candidate to go up against a large panel of interviewers. You should have enough trust on your team so that everyone’s presence is not necessary every time. Interviewing is an incredibly stressful and draining experience where the candidate is trying to perform at the top of their game for hours at a time. Going into an environment where they feel ganged up on does not make for a better interview or a more relaxed candidate.
Because it is so draining, allow time for breaks! These are humans we’re talking about, not machines. Everyone appreciates the opportunity to allow the glucose back into their brain, or to use the bathroom, or to check in with work or family. By demonstrating that you care about the well-being of the candidate, you show them that you’re not the type of organization that expects them to work nights and weekends because you don’t know how to plan properly.
Three or four hours (including lunch) is as many interviews as you can realistically do in a day. After that, the candidate is unlikely to be able to put their best foot forward. They have often taken some time off work and it may look strange for them to be away for so long, or they may have other responsibilities. If you’re unable to complete all the interviews with a single onsite, consider whether remote interviewing is a possibility for any further sessions as the candidate may have more flexibility in that situation.
One interview that is often thrown into the onsite/online interviews is one for “culture fit.” Do not do this! Interviewing with the goal of culture fit is a fast way to a homogeneous team. As with the diversity and inclusion discussion above, if you want a less-creative team that underperforms compared to their more diverse peers, then I can’t recommend the culture fit interview enough. Instead, make sure your candidates and your team are able to communicate well with one another, and you will have a team with diverse skills, backgrounds and talents that other teams will be chasing.
You’ve gone through all the interviews. Either no one has raised any red flags, or everyone is enthusiastically supporting hiring the candidate (different companies have different standards as to how consensus is reached). Now it’s time to make the offer. We’ve already established that recruiting is a sales-like activity.
Make a fair offer. It’s not always necessary to pay top dollar, but with the competitive landscape of today’s market, expecting people to take less than their worth for the privilege of working at your company is folly. To try and lowball someone at this point is just telling them that they’re not really valued, unlike all the other activities that reinforced their importance during the interview process.
The compensation consideration conversation should have begun early in the process so at this point there should be no surprises. Surprises at this point are like exceptions in the process we’ve engineered, so if they do happen, you need to go back and fix your process to prevent exceptions at this late phase from happening in the future.
Encourage any new employee to take time off between jobs if possible. It’s a poor beginning to have a new employee show up burned out on the first day. If they can’t afford to take any time off, try and arrange a small signing bonus to cover the time. The financial cost of the bonus is much less than PTO would cost the company, and less than the loss of productivity from an employee who is not ready to start a new job.
Lastly, do not leave the onboarding of the new employee to chance. The team should have a clear plan for at least the first two months in which they consider the ways they will bring their new teammate up to speed. They will need to make accommodations for the learning style of the new employee, but they already learned about those factors during the interview process. When the new employee arrives in a deliberate, supportive environment, it will help to establish the psychological safety from which we get our highest performing teams.
When hiring new employees, often our process is a haphazard series of handoffs as a candidate is identified and shuffled from one department to another, after which they are often left forgotten, disappointed or disheartened about the role they would have in the new organization based on their treatment in the hiring process.
Instead, if you are clear and deliberate about the stages in your process, and show your prospects dignity and respect throughout a smooth-flowing pipeline, you can hire the engineers you want to create high-performing teams, while other companies are left to flounder with delays, communication failures and time spent on meaningless exercises.
What choice will you make?