Interviewing is difficult – maybe even broken. We expect to make a decision that could cost hundreds of thousands of dollars on just a few data points: a description of previous positions, a list of skills, and a few short conversations. In just a few hours, we need to not only evaluate a candidate for the position they applied for, but also consider other positions at the company that might be a better fit.
Over my past year at fuboTV, I’ve conducted several dozen interviews. I’ve made many mistakes during the process that probably impacted my review of the candidate, resulting in a pass when they should have failed or vice versa. But over this time we’ve also hired some amazing people who we might have passed on if we strictly followed the strictly objective hiring practices of FAANG companies.
I wanted to use this article to share some of my mistakes and lessons along the way.
Our old process:
We relied heavily on third party recruiters whose goals did not align with our company’s.
Third party recruiters have only one goal: get a candidate hired and collect the fee. Recruiters know the difficulty of evaluating candidates during an interview, so their goal is not necessarily to find the best person for the job, but to find the person most likely to pass the interview. Before each stage of the interview, my recruiter would schedule a session to coach me through the process, even offering to show me questions previous candidates received from the company. This adds more noise to an already ambiguous process.
We emphasized CS knowledge for positions that might not need it
The interview process when I joined fuboTV was very similar to the Google process: whether the candidate is interviewing for a front-end or back-end position, a full day of whiteboard questions focused on algorithms and data structures. We use these questions because they can be helpful in evaluating a candidate’s critical thinking skills, their ability to communicate their thoughts, and even the cleanliness of their code. However, I believe our industry has over-optimized the technical interview and these types of questions have lost their merit.
All savvy candidates are aware of the pervasiveness of algorithm questions. Often there are just one or two data structures that turn the problem into a trivial series of loops or conditionals. A candidate that finds the interview question beforehand (on Glassdoor, where there is an “interview questions” section for each company”) has a huge advantage over an equally-skilled candidate who has never seen the problem before.
Algorithm questions seldom measure a candidate’s aptitude in day-to-day tasks. I don’t think I’ve ever had to derive the stable marriage algorithm or implement a topological sort in the ReactJS apps I maintain each day.
Our process now:
Look for passion
Candidates begin the process with a brief conversation with one of our internal recruiters. We want the candidate to show enthusiasm for technology and the company, and probe for some experience that fits a current need. Our recruiters don’t ask any technical questions; we have faith in the rest of our interview process.
Tech screen – Read their resume together, find out what they really did
We chat with the candidate during a one-hour technical screen over Skype or Hangouts. This interview should validate the candidate’s resume, digging through the resume-speak and learning about what their previous role was, how they contributed, and how that experience is relevant to this current application.
We ask broad questions about the items on a candidate’s resume, and when we detect some excitement in their response, we dig deeper to figure out why they found a project interesting and gauge their level of involvement on the project. This part is open-ended and has led to some wonderful conversations unrelated to the position, but demonstrated a love of learning and technology that definitely helped the candidate during reviews.
We sometimes ask relatively simple algorithm problems to get a baseline of a candidate’s coding and critical thinking skills. We try to talk through the problem with the candidate, and give a lot of flexibility in our review of this part, since they can easily search for these problems if encountered on the job.
Onsite – Make sure they have what it takes to do the job
We bring the candidate to the office for 3-5 hours of interviews with employees in various roles, including the candidate’s potential technical manager, project manager, designers, and anyone else who may regularly interact with the candidate if they join. Ideally this day will be a mix of culture interviews and additional technical assessments.
Our technical interviews are still quite algorithm-y, but we’re trying to make the process more like a candidate’s day-to-day responsibilities. Some possibilities include pair programming with the candidate or asking them to review a simulated pull request.
The final decision is not just technical
The goal of all of these interviews is to paint as complete of a picture of the candidate as possible. We want to make sure a candidate can perform the job duties, but also make sure they don’t negatively impact the culture we’ve worked so hard to build.