Pre-screening developer candidates
Part of my job as the Head of Engineering for a growing team is identifying developer and engineering candidates. This takes a lot of time, and can often be a painful practice. It often requires me to identify candidates for jobs I have little technical expertise with. I’ve cultivated some methods to help identify the right people, and I give them to you here so you can maybe learn from my experience.
If you do the three steps below, you’ll make your life a hell of a lot easier in the long run. If you have a robust hiring process, I would say take from these ideas and add them on the very top of your list, before any of the intense HR stuff.
Treat the whole thing like a funnel. Kind of.
Harkening back to my days as a startuptrepreneur, all we talked about was the funnel all the time. Getting (potential) customers into the funnel. Optimizing our funnel. Crying after work because of our funnel. Well, treat the whole hiring process similar to that. Except, instead of hoping your funnel has 100% conversion, you want to narrow down your output as much as possible.
It’s important to have a clear funnel. Mine looks more or less like:
Online Posting -> Emailing back and forth -> Coffee meeting 1 -> Coffee meeting 2 -> Take-home assessment -> In-person assessment review -> Second interview -> Offer or no offer.
That reads like a lot of things, but when you’re doing this whole process simultaneously with 10 or 15 or 20 people, it’s actually easier. The process is longer with less effort spent on each step. Otherwise, you’d have fewer steps but much more time spent on each one. This way I can run many in parallel at varying stages with less overhead.
Never ever skip the in-person pre-screen
This is maybe the most important step. This is where I will chuck people out of the funnel right away. Have a cup of coffee or a lunch with the candidate. Just talk. This is not a formal interview, and there should never be more than two people at the table who are not the candidate. Best if it’s just you (or whoever they will report to). In this step I really just shoot the shit, talk about the work life, talk a little about the work, and really get an idea of what they are like.
This is not a technical interview. That comes later. I want to know if they can communicate with me. I want to know if I can sit down and talk to them and enjoy myself. Do I get any weird vibes? Do they keep checking their phone? Can they talk with passion about their current work or work experience? If this doesn’t go well, maybe schedule a second one, or part ways.
Personal anecdote: This is where older and more experienced engineers almost always shine in a way the younger ones don’t. They are calmer, and perhaps a little jaded. They have war stories and can talk about crazy old technology and colleagues. That brings up another point: if they bitch and complain too much they are probably not a good fit. You want developers who can take the bad with the good and keep rolling.
Give a take home assessment, not a whiteboard test
No one likes whiteboarding tests. They are terrible. What we do is very, very simple but very, very powerful: Write a codebase with a suite of tests. Strip out the working code, leave the tests. Provide them the codebase with the instruction “make the tests pass.” Boom.
They complete that at home, at their leisure. They probably google things, they make mistakes and fix them, they work comfortably and confidently. Hell, maybe someone even helps them. So what? They’d do the same thing on the job. What happens next covers our ass anyway.
They come in and defend their work in front of the larger team. We sit around a conference room table, bring up the code on the Apple TV, and one of the Sr. Engineers walks through it, asking questions. It’s another conversation. Can they talk about the code? Can they concede if a better solution is presented? Are they opinionated but factual?
This is the last big step before we start to make a decision. Any strong objections will disqualify the candidate.
So, that’s it
That sounds like a lot of things to do, and it kind of is. But, like I said before, you flatten out the process and spend less time on each step. Each meeting should be an hour or so. You want to have time to get comfortable and get into the flow. Let multiple people handle different parts. Get their honest feedback. This is a person who will become part of your work family. You want interesting, thoughtful, caring, clever people on your team.
What do you think about this process? What would you change? I learn more about the “right” way every day.
