Hiring Process for Technical Roles
Background
I recently landed a new job, but it has been a long process. I've had multiple phone interviews, technical interviews, in-person interviews, and been assigned a variety of projects. The primary purpose of this blog post is to relay what I found to be the best interview/hiring practices and those that I found to be flawed in some manner or another.
Preliminary Considerations
Before I get to the actual components of hiring, I want to point out a few considerations hiring managers may want to think about.
- Unemployed Applicants vs. Employed Applicants - Unemployed applicants will, in most cases, have significantly larger amounts of spare time. This is primarily a consideration for things like technical challenges and/or multiple on-site interviews.
- Personal Lives of Applicants - Yes, you want someone who will be devoted to your company, I get it. Families, jobs, commutes, these all affect applicants and their availability. Again this is primarily an issue when it comes to technical challenges and on-site interviews.
- Applicant's Background - Let's say you are looking for an applicant with a great background in programming. Your first instinct might be to only consider people that have multiple great projects up on Github, i.e. people with large amounts of public facing work. However many tech workers are employed at companies which do proprietary work and therefore will not have much on display publicly. (I could start a rant here about how some people in tech think you should be working at all hours when you go home, but I'll save that for another day. )
- TIME TIME TIME TIME - The above considerations all have some anchor to the amount of time applicants have available. Its perfectly acceptable to have high standards for hiring, but if you don't normalize for the amount of free time your applicants have you are going to look past a large population of talented people and severely limit your talent pool.
The Process
I'm going to focus the rest of this post on components of the interview process. Everything from this point on will be referencing things that happen after application submission.
Phone Screening
Phone screening is normally a semi-pleasant and necessary part of the hiring process. A human resources person gets to make sure I'm not a bot or serial killer and lets me know about the job. In return I relay what I'm looking for. I didn't have any issues with this part of the process.
Technical Challenges or Projects
Now for some fun! I will start this by stating that I DO believe technical challenges are a great tool for hiring talent. However this tool is often used incorrectly, think chainsaw for heart surgery. In most cases after you pass the phone screening a technical challenge is assigned to the applicant. I'm first going to touch on what I see as the best practice here:
- Schedule the Challenge in Advance - I found this to be the single most important part of the challenge. I was working at the time, so being able to set up a time to work on the challenge was extremely important.
- Define a limited timespan - In general try to limit the challenge to a small project which will take a few hours. You are tryingt to get a sense of my competency, not a measure of how much free time I have.
- Open end the problem - Every time I would look at a data science listing it seemed to have more skills listed with it. If your job description is not oddly specific why would you make the problem you are giving the applicant specific? Let the applicant show you what they are good at by providing them with an open ended task. My best experience was the following: Here is a dataset, do something with it. 'Something' could be visualization, build a model, exploratory analysis, etc.
And the practices I find to be the most detrimental:
- Emailing the Challenge without Warning - I had this happen to me multiple times. How anyone expects to get good results from this is beyond me. If you are trying to hire someone who is unemployeed currently and/or a student, then maybe this will yeild some decent results?
- Defining extremely specific tasks - There is one exception to this. If the job listing you posted was very specific, then this does not apply. However if the listing posted was made to capture all data scientists, then maybe consider allowing the applicant to showcase their strength, you might be surprised.
- Project longer than 6 hours - Normalize for your applicants. You aren't going to get equivalent results for a 72 hour project from a working applicant as you would from an unemployed applicant. Limiting the window of the project will allow you to get a good feel for the person's aptitude without inducing a bias. If the role you are looking to fill requires something more long-term, then clearly communicate with the applicant and set up a schedule that works for both parties.
Interviews
In general I had good experiences with the interviews I had during my job search, but I do have a few notes.
Phone Interviews
In most experiences this has been a pleasant experience. If the phone interview is being used as a technical screen, keep the questions fairly general. I had one experience where I was grilled for an hour about different search and sort algorithms, linear algebra, data structures, and signal processing. I believe it was roughly 60 questions. If you want to hire a book or a computer, cool, otherwise maybe slow it down a bit.
Technical Interviews - In Person
Interview the person for the skills you are actually looking for. If I'm interviewing for a job that requires cleaning up data, A/B testing, and linear regression, why would you ask me to explain Dijkstra's algorithm on a white board? Luckily I didn't run into much of this during my search, but there are plenty of people that have.
I found the following to be good practices:
- Give the applicant a problem and watch how they solve it. I've been on both ends of the spectrum here. I've been interviewed with tools I knew how to use well and I felt really comfortable working through the problem. I've also been completely unfamiliar with the problem I was asked to solve, but I was able to display how I approach problems. Regardless of the applicants familiarity with the problem/tools, you can learn a great deal about the applicant using this approach.
- Let the applicant use their own equipment. It's great to provide a setup for the applicant, but if the applicant has their own equipment, let them use it.
In Person Interviews (Non-Technical)
To clarify, this would be the interview after all technical interviews/projects have been completed. I've honestly enjoyed every one of these I've had during this last search, so I don't have much to offer here. I learned about the company, they learned about me, everyone wins.
Closing Remarks
This post was based on my search and my work/life situation during my search. I'm sure people will see some of this differently as we all have different expectations as employers and applicants. My main point here is that if you want to be able to hire talented people don't create situations which filter them from your hiring pool or hinder their ability to display their strengths.