Engineering the hiring of engineers

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.

1 2 Page 2
Page 2 of 2

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.

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

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

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’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?

Copyright © 2020 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams