This was first posted on DeepSig's company blog. It is reproduced here with some changes for
dev.to's more discussion-oriented venue.
I had my first interview for an engineering role in early 2005. I was in school, and looking for an internship for the upcoming summer. The founder & president invited me to his home to interview one Saturday morning over Spring Break. Over a cup of coffee, we discussed my background, my interests, and what working at his company would be like while his children played around us. I had no way of knowing at the time, but it was one of the best job interviews I would have in my career.
Since then, I’ve had wildly varying interview experiences. Luckily, I’ve had more that were like the first - a friendly discussion with someone I would be working with. In some, I felt like I was actually teaching a class to my interviewers. And then there were others where I stood at a whiteboard for four hours while getting grilled by successive teams of engineers who seemed to think that offering me breaks to get a drink of water would make things friendly. I even had one interviewer at [Big Tech Co.] who actually wouldn’t speak to me while I was at the whiteboard - he would answer questions only by looking up references on cplusplus.com and turning his laptop around to show me docs.
Since then, as a hiring manager, I’ve had the opportunity to experiment with different interview formats. We’ve tried using whiteboard interviews, but with firm rules about how they were conducted in an attempt to avoid the usual pitfalls and negativity. When we experimented with candidate technical presentations, we found that candidates who had given good presentations were highly correlated with candidates who received offers. I was really excited about this because it meant a higher success rate during on-sites, and for many positions we cut the on-site (i.e., whiteboard) interview entirely after a good presentation. But, this had its issues, too. We always asked candidates to use material they had already prepared, but we found that the vast majority of candidates - even ones who did have something already - would prepare something totally new to try and impress us. Candidates were spending a lot of personal time preparing to talk at us, when interviews should really be talking with us. And there was clearly a selection bias for candidates that were comfortable giving a technical presentation to our team and had time to prepare.
So, after thinking through our own experiences as candidates, interviewers, and hiring managers, we’ve decided to throw those methods out. No more whiteboard interviews, no technical presentations. The best interviews, in my opinion, were always the ones where it felt more like the candidate was interviewing the company than the other way around, and where both the company and the candidate got a sense of what it would be like to work together. Based on that, we’re rolling out a new hiring process, informed by a philosophy that we believe is both stronger and kinder.
Candidate-First Hiring is a philosophy that guides our hiring and interview processes. We discuss it at great length in our internal hiring training for employees, but generally try to summarize it with three main principles:
- A good hire is when what’s best for the candidate is what’s best for us.
- We hire to build and develop a great team.
- Every candidate should feel valued & respected as an individual.
When someone joins our team, we genuinely want that to be because that is the best move for them, and we want to be sure that they have all of the information needed to make that decision. This obviously includes items like understanding the compensation package and knowing who they will work for, but we also want to make sure they have an understanding of our culture, who their teammates will be, and what their workday will look like. Crucially, when we decide that a candidate is a good fit for a position, we want to make sure we communicate why openly and honestly. And when the candidate decides if we are or are not a good fit for them we want to know why, too!
We want every hire to be a positive development for the team, and we focus on hiring people that will make the company stronger. Simply hiring smart people isn’t a path to success, because our company isn’t organized to function by employees working in isolation. We are a small company, and everyone works together almost every day. Our company is designed to make a whole greater than the sum of its parts, and our approach to hiring reflects that.
Respecting candidates and valuing them as individuals sounds straight-forward, but there’s a lot about modern tech hiring that I would argue does not do these things. A lot of processes treat candidates like a numbers game, auto-screening based on years of experience and degrees, looking for a body to fill a seat rather than valuing each individual’s career path and accomplishments. Some hiring processes require candidates to spend an inordinate amount of time interviewing over several months or require them to do take-home work. Indeed, our previous process step of a technical presentation resulted in similar issues. These sorts of pipelines dramatically increase expense, not just for the company but especially for the candidate, and introduce more bias. Pragmatically, it is a privilege to be able to prepare for interviews in the evening or miss work for multiple on-sites.
With this philosophy in mind, there are three things we hire for:
- Role Fit - Will they be successful in the role in the timeline we need?
- Culture Fit - Are they a good fit for our team and company?
- Knowledge Fit - Will they have the requisite knowledge to be successful in the timeline we need?
Something that falls out of the philosophy described above is that there is no purpose in us trying to determine how “good” someone is at their chosen profession. Labels like “rockstars”, “A+-players”, and “high-performers” aren’t material to our position requirements. Even if it were possible to objectively and quantitatively determine that someone was the #1 engineer on the planet, that still would not be necessary or sufficient information to determine if they are a good hire. Further, trying to ascertain this fundamentally contradicts our philosophy to hiring.
Rather, we are focusing on the things that actually matter for our team and company to be successful. We aren’t hiring for people that “perform well at a whiteboard” or “can set aside time in the evening to study”. What we care about is their ability to succeed in the role, thrive as a member of our team and company, and contribute or learn what is required. Our interview process is designed to give both us and candidates enough opportunity to explore those items.
Based on the above, our interview process is three steps:
- Intro Call
- Talking Shop
- On-Site Interview
The primary goal of the Introductory Call is to establish if a candidate is potentially a good hire for the role. This, for example, includes if it’s the type of role they’re looking for, if they have the background to be successful, and if the logistics (e.g., timeline, location) work out. In short, it’s meant to sort out whether or not we’re potentially a good fit for each other right now, or might be further down the road.
The next step is Talking Shop, which really just means having a conversation. This can be done in-person if the candidate is local and prefers it, but it’s also easy to schedule over a video conference. The goal is to give the candidate an opportunity to talk about some of the things they’ve done and to meet one or two of the people that they would be working with. Have you ever met someone and after getting to know them a bit thought, “Wow, it would be fun to work together,”? That’s what we want this to feel like. This is not a test, and there are no technical pop-quizzes. It’s an opportunity to learn more about each other.
The last step is an On-Site Interview. In addition to grabbing a meal with some of the team (if their schedule allows) and meeting our senior leadership, this is our opportunity to learn a bit more about what it would be like to work together. We’ll share a technical challenge the team is currently facing, and work on it together. There is no solo-solving at the whiteboard or coding prompts. We want to know what it would be like to actually work with the candidate, and we suspect the candidate probably wants to know the same thing.
If after visiting us, we all agree that we’re a good match for each other, we’ll try our best to make that happen.
As mentioned before, this is a new process for us. We put it into action last month, and will be tracking various metrics over the next year to evaluate its success. We’ll also be asking candidates for feedback on their experience and what could be improved, and make adjustments as needed. Twelve months from now, we’ll post an update sharing some of these metrics.
We are also eager to share ideas, learn about things other companies are trying, and listen to others' experiences, both good and bad. Improving our hiring is not something we ever expect to be "done" doing, and our process has benefited tremendously from both our own experiences and others' stories, ideas, and suggestions - including a number of discussions we've had here on
dev.to. I'm happy to connect here, by e-mail, Twitter, or anything else that works