A year and a half ago when I joined The Graide Network, I left a role managing and hiring an engineering team to be the first developer at a new startup. Our hope was that as the company grew, my role would shift away from individual contributor to team lead, and now it’s happening with our next full-time software engineering job opening.
I’ve had a lot of time to think and read about hiring since I last did it at Packback, and I wanted to make some significant changes to my process. In this blog post, I’ll outline some of my problems with the typical engineering interview process and how I’m now attempting to solve them by rethinking my hiring process at The Graide Network.
The Hiring Problem
Anyone who’s hired people will tell you that it’s hard. There are lots of constraints, no way to fairly compare two candidates, and good candidates for one team may be horrible for another. Because it’s so hard, the process has evolved to favor people who think like the interviewers, who know someone at the company, or who perform well in high-pressure interviews. It leaves people with non-traditional backgrounds struggling, often works against diverse candidates, and is nothing like the day-to-day work that most engineers do.
For example, a typical interview may require a phone screen with HR or a recruiter who tests for “soft skills.” Next, an engineering manager may screen for baseline technical skills, and then the candidate may be asked to complete an independent project or come into the office for a whiteboarding session. In either case, the interview is nothing like a typical day working as an engineer (although the “take-home” project may be the closest in some environments).
Soft skills are important, but “tell me about a time when…” questions favor people who are quick to make things up (I’ve always had to bend the truth to get my stories to fit the question at hand), and they don’t demonstrate real judgment or problem-solving skills. It’s impossible to assess someone’s character in a 30-minute phone screen, so at best, you can weed people out who are completely unreliable or have poor oral communication skills. Similarly, it’s very hard to judge a person’s technical ability in all things during a 1 hour tech screening. The field of web development (and software engineering in general) is so vast that nobody is going to match your requirements perfectly. You can ask them what technologies they’re familiar with and see if they can have a coherent conversation about technical topics, but you probably can’t bump up against the edges of all of their knowledge, especially if it doesn’t overlap completely with your own.
I used to assign a “take-home” project to candidates who passed my initial phone screening. My thinking was that this would allow them some room to flex their creative muscles, and it wasn’t time-constrained. Plus, it didn’t require my team to spend much time with candidates until they completed the project and the candidate could do the work at a time convenient to their schedule. The problem with this independent project is that it didn’t tell us anything about how a candidate would work in a group, so we still had to have another session with them and the rest of the team. We lost many good candidates because they didn’t invest time in the “right” parts of the project either. For example, if someone didn’t write tests or didn’t cover enough cases, they might not look as good as someone who did even if the project didn’t strictly require it. We also couldn’t really tell how long someone took on the project or if they had help from others, so it’s impossible to say whether or not we were even testing the candidate.
Finally, I’ve never done whiteboarding or live coding sessions with candidates, but a lot of people really hate them, and I think there’s a good reason for that. When in the real world is a programmer pushed in front of an audience to solve a problem with an obscure algorithm, no time for independent research, and no access to resources (a la the internet/Stack Overflow)? I would never do this job if that were my day-to-day. Testing programmers at something they aren’t actually expected to be good at and expecting to learn something about how they would work at your company is delusional, and I think these kind of interviews only serve to make the hiring team feel smarter and ensure better outcomes for engineers with traditional CS backgrounds.
Better Different Way
As I said above, I’m trying something different this time around, but I can’t tell you it’s better, worse, or equal to the approach I have used before. That said, I’ll walk you through my process and the reasons I’ve decided on it.
Step 1: An Informational Interview
Instead of setting up “phone screenings,” I’m treating our first call as a two-way informational interview. The candidates need to know whether or not a place like The Graide Network would be good for them just like I need to know if they’ve worked with none, some, or all of the same technologies we use. I don’t try to suss out deep technical knowledge, but if there’s something in there work history or resume that stands out, I’ll ask about it. I end the call by selling them on the role and seeing how interested they are in us versus any job that’s available.
Step 2: An In-Person Pairing Project
This is the meat of the interview, and it’s much more similar to what I do with team members in real life. We pick an open source project with a few issues we can make progress on in 2-3 hours, schedule a time to get together, and then pair program on the issues. This helps me assess their critical thinking ability (especially when they’re the navigator), their communication skills, the speed at which they pick up new things, and our ability to work closely together. Similarly, (I hope) it allows them to see whether or not they’d like to work next to me for the next few years. Finally, we’ll do more questions and answers if there is anything that I feel like wasn’t answered in the first informational session.
Step 3: Meeting the Founders
We’re a small startup, so it’s important that new hires make a good impression on our founders and that they can buy into the mission. I don’t believe that every single employee has to be insanely passionate about the business, but I do think that it adds a lot of mileage to early employees. The technical problems we’re solving will change often and sometimes they’ll be boring, but our mission and core team is likely to be pretty consistent for the next few years.
Behind the scenes, I am doing some other vetting as well (like checking their references and resume for inconsistencies), but that’s pretty much it. I always tell bootcamp grads and new managers that there’s no one way to hire, so I’m not naive enough to think that this new method will be perfect, but I hope it eliminates some of the biases and pain that the traditional interview process entails.
I look forward to hearing your feedback on Twitter. What would you do differently as a hiring manager?