As managers we are responsible for hiring the best people for our team. We spent hours sifting through resumes, interviewing and training candidates. However, despite our best efforts, the hires don’t always work out and we are stuck thinking about what could be done better. What new questions to ask? What references to request? What puzzles to offer? While those steps are an important part of a hiring plan, many are not as important as spending long quality time with the candidate. Working together on problems in the context of the workplace is the best indicator of success.
Let’s review what approaches are usually taken and why they may not reveal all of the information about the candidate’s fit.
Do Less Of This
Puzzles - This is a very popular type of question that interviewers ask in the software industry interviews. Usually it is formatted as one-two sentences and leaves interviewees dumbfounded with how to answer. Technically, that is the point of the question, but I would argue not extremely relevant unless the puzzle is a reworded type of a problem that the employee will deal with on a daily basis. Otherwise, it is just a test whether someone is good at puzzles. Not every puzzle translates well into work problems and vice-versa.
Lots of interviews - Some of the teams I have worked with had a practice to take candidates through a series of two-hour long interviews. While occasionally this strategy surfaced good candidates, it also encouraged others to consider alternative job offers. Additionally, there was a noted outcome of hiring people who were good at sitting through long meetings. This trait is usually atypical of great software engineering candidates.
References - One of the holy grails of modern hiring is insisting for candidates to provide references of those they worked with previously. At first it seems like a reasonable step, but generally the conversations with references turn out to be quite biased with highlights about candidates' positive traits. This method also prioritizes candidates with great social networks, which are also atypical of the engineering candidates.
Team Interviews - This is probably one of the strangest methods of interviewing if you really think about it. Almost never do we have to encounter this type of interaction in a workplace, unless we are being interrogated by the police or lawyers. It is an unnatural environment for the candidates to be relaxed and provide confident answers. Especially if the questions are tricky and are not referencing something that the candidate worked on confidently before. This method might dissuade those who are great in one-on-ones, but shy in the group setting.
Overall, I’d argue that while we are getting our confidence up while practicing these methods, they are not the greatest proxies for letting us know if the candidate is the best for the job. Let me share what I think about other options and how taking them into consideration will enable you to make better hires.
Consider This Instead
Human Interfaces - It is probably a phrase you have heard before, but I want you to really consider it in the context of hiring - “Every person is unique”. The phrase means that the collection of our past experiences makes us unique individuals, which also implies that the relationship, aka Human Interface between two unique individuals will also be very unique. As we zoom out on the team level,we see that each combination of humans presents a lovely tangled infinite mess of human interfaces. Our goal should be to explore what those interfaces would be between each member of the new team. This will help ensure bonding while working together on future projects.
Context - The short summary of this is to make sure that every question and problem that new hires are asked is viewed through the lens of local company context. We are checking for a specific fit and not querying human wikipedias. There is no need to ask deep philosophical questions not typically discussed in the workplace, or grill the person on the hardware experiences if the day-to-day job involves only software.
Type of the problems - What types of problems are relevant to discuss during the interview? The best ones are the ones the new person will be doing day-to-day. It is pretty straightforward, but I have seen many times interviewees thread into conversations about what the candidate was best at, and not what the priorities of the company were.
System resources - while considering whether the candidate is technically and socially compatible don’t forget about considering company resources. The candidates were successful in the context of the previous company, and if those resources do not adequately map to the current setup and the candidate is not flexible enough to adjust, the hire can turn out to be a dud.
Cadence - Nine to five, five to nine, midnight cram, last minute sprint, when does your candidate prefer to accomplish their great work? Is this information reflected on the resume? You might end up hiring a great candidate but the new owl might not be able to work with the early birds on the rest of the team.
All of these are important factors to consider but they are a lot to keep in mind! Is there an easy way? Yes, but it is impractical. The best way to see if the candidate is a good match for your team is to hire them after a short interview, have them work in the context of your team, projects and environments. If they don’t work out, let them go. But, this method is incredibly inhumane.
What options are left to us? Approximate this experience as closely as possible!
Can you hire them for 5 days? 1 day? Consulting? Weekends? Explore ways how they can come work for you, while not working for you full-time just yet. It is very unorthodox, but the more you think about it the more it will make sense, that the best way for candidates to test out the working environment is to actually do the real work in the context of their new role. While perhaps painful to explain and get the candidates to agree, it is the least risky way.