Dave Mangot

Dave Mangot

I partner with PE portco CTOs to deliver on the investment thesis by helping them change the culture of their existing org from halting to daily delivery so they can get the race going.

Engineering the hiring of engineers

This post was originally published on CIO.com on January 27th, 2020.

Current State

I’ve either been a team lead, or a manager for much of my career, and every time I was back in a role that required hiring, I always secretly prayed that the industry had gotten better at hiring since the last time I’d tried. It was 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 case you have managed to erase the experience from your memory, it goes like this: I have a 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 emails to people who may fit the profile, in the hopes that they will get lucky and find THAT person who just happens to be looking. Or we post the job 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 good faith in the intentions of the hiring process, as an engineer, it is a system that makes little sense. As an engineer, I know that the system can be better. 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 for car manufacturing, and should not accept it for people with whom we work 8 hours a day.

The Inputs

To begin with, we need to set up our system up with good inputs. By this, we mean better than random contacts from a recruiter. There are many different possibilities to gain these inputs. All good sales people will tell you that sales is about relationships. Well, recruiting is sales. It is about the candidate selling themselves to the company, and vice versa. In that case, we should leverage relationships to get good inputs.

Referrals

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 know** **the prospect already. The biggest mistake a company can make with referrals is to try and save money on the referral bonus. When it is common practice to pay an external recruiter a $25,000 fee to email random people on the Internet if one of them gets hired, it makes no sense to pay a $2,000 referral bonus to your own employee to bring in vetted talent with whom they’ve worked before when they’re hired. The recruiter has never even written a line of code with the candidate!

Internships

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 had the ability to extend offers to only the top engineers who had often been back for multiple internships as part of the program.

Bootcamps

Not all candidates will make themselves known through traditional methods for varying reasons. That doesn’t mean there are not 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 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 for social justice reasons, some to be able to attract top talent as that is 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 & inclusion is a very important part of having successful inputs and outputs in your hiring process.

Clarity

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 make sure in all cases you know what you’re looking for. That will greatly increase your chances of success as you bring candidates through the process.

The Process

Once we have a good candidate in mind, the entire purpose of the process is to build increasing confidence in our extension of an offer. That is, the further down the pipeline the candidate goes, the more confidence we have in extending an offer. We 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 the team.

Each company and culture will be different. The process I describe below is the result of years of hiring and the intent is to provoke thought and discussion about your hiring process. This approach is to apply the 1st way of DevOps (systems thinking) to the problem. We want to optimize the process from beginning to end in order to maximize the flow of work (candidates) through the system.

First Contact

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 is 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 will end up with more work than just doing the work yourself from the start.

Good Examples
  • Firefox, Mozilla, and Safari are all examples of what? (web browsers)
  • In programming, “for” and “while” are examples of what? (loops)
Bad Examples
  • What is the difference between a map and an array?
  • Explain how the Domain Name System works.

The latter examples require either specialized knowledge or nuanced understanding on the part of the recruiter. The Good Examples have straightforward answers that do not leave much room for interpretation. You may be saying to yourself that those questions seem **really **simple. They are, intentionally. 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, requiring no technical background whatsoever.

By the time it gets to the hiring manager, you are 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 grow. If you are a smaller company, you will usually talk about the ability to have a big impact, to learn many things from varied areas, and to grow towards 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 (people management). Talk about who they will have the opportunity to work with, tell them how they will be supported in their role. The process of changing jobs carries with it enough stress, that anything we 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 their opportunities and you are not just trying to fill a body into an open slot. There is typically a lot of flexibility in a position and you want employees who are active and engaged. This is much easier to do when people are working on things that they find appealing. An old boss once told me that “anyone can hold their nose and do something for two months”. What happens after two months?

Communicate

One of the biggest lessons I’ve learned while recruiting is to communicate. We’ve said many times that hiring engineers is partly 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. Because we’ve thoughtfully constructed our pipeline, we 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 this person early, that can only help to benefit your relationship if they become an employee. There are so many horror stories of companies that have “ghosted” candidates, only to reach out to them weeks later, which makes candidates feel like an afterthought at worst, and not a priority at best. It makes it unlikely that the candidate would ever consider or recommend working there.

The Coding Test

The coding test this early in the process? If we’re hiring engineers, they will need to write code. Even infrastructure engineers need to write code these days. If you are hiring engineers and do not have a coding test yet, now is the best time to start one, and I’m here to help you get going.

Guiding Principles

The test should be reflective of the actual work. Does the day to day job of the person you are hiring require them to regularly implement a bubble sort from scratch off the top of their head? If not, then do not 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 is a common part of the job, but don’t test some obscure piece of knowledge from your college computer science classes, this is not Trivia Night at the pub.

If the job does not involve coding on a whiteboard, neither should your test. I don’t believe there to be any whiteboard coding jobs out there, and if if I’m right and they do not exist, this practice needs to end. No professional 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 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 need to send the candidate a coding test that they can do at home in no more than 3 hours. That 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 that other employees at the company have met that bar. If the test is too easy, they will think that coding is not valued. If it is too hard, they will think that you are not really interested in their success in the job.

There are some exceptions! If you are interviewing the creator of X, you don’t need to ask them to code in X. If you are interviewing senior candidates, it is 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 for 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.

Onsite/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 indeed did the work, then this is an opportunity to find out how well the candidate understands what was written. I once had a test submitted by a candidate where one of my senior engineers pointed 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, line by line, 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. We failed them 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 is time for the candidate to meet with the various people with whom they will be working. These can be members of the team that they would join. These could be leaders of other teams with which they may work often. The goal of this stage of interviews 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” which 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. I always try and have these meetings on-site if possible. Even if a candidate is to 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 are going to have them participate in a series of interviews, there are a few things to keep in mind:

Limit yourself to a few people interviewing each candidate. It is not fair to a candidate to go up against a large panel of interviewers. You should have enough trust on your team between team members so that everyone’s presence at the same time is not necessary. 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 upon 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 use the bathroom, or check in with work or family. By demonstrating that we care about the well being of the candidate, we are showing them that we’re not the type of organization that expects them to work nights and weekends because we 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 are unable to complete all the interviews with a single onsite, consider whether remote interviewing is a possibility for any further interviews as the candidate may have more flexibility in that situation.

Culture Fit

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 & 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.

The Outputs

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 know that ultimately recruiting is a sales activity.

Make a fair offer. It’s not necessary to be Netflix and pay top of the market, but with the competitive landscape of today’s marketplace, 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 are 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, we need to go back and fix our 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 give thoughtful consideration to the ways they will bring their new teammate up to speed. They will need to make accomodations 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 we are clear and deliberate about the stages in our process, and show our prospects dignity and respect throughout a smooth flowing pipeline, we can hire the engineers we want to create high performing teams while other companies are left to flounder with delays, communication failures, and time spent on meaningless exercises. Which choice will you make?