There is no shortage of advice out there about how to recruit and hire the best developers. Everyone has their own process, from traditional metrics like resumes and years of experience, to logic puzzles and take home multi-day coding tests.
I’ve been interviewing developers and designers for nearly 15 years and have been focusing and refining my own process for a while. At this point, I’ve reached a new pinnacle of minimalism. I’ve boiled my technical interview down to a single question:
What’s your story?
To be fair, the question is bigger than that. What I’m really asking candidates is how they became interested in programming, how they arrived at where they are today, and where they want to go next. I want them to tell me about their journey.
I ask this one question and then sit back and listen as they unpack sometimes decades of experiences into a single hour. Everyone’s story is unique and I’ve found that the journey and how they choose to talk about it is more telling than any other interview question.
What I’m looking for is a demonstrated pattern of behavior over the course of their lives that shows:
- Intellectual Curiosity — They become interested in things around them.
- Intelligence — They are sharp enough to become proficient in the things they are interested in.
- Drive — They have enough grit to actually accomplish something meaningful with the things they became proficient in.
In our profession, technologies come and go all the time. A good developer is pretty much always doing something they’ve never done before. Learning new things and applying them is the job, and therefore that’s the skill that needs to be evaluated.
This is pretty different than the way most people go about evaluating developers. Most interviewers focus on the current skills inventory: which technologies you know and how many years of experience you have. Analyzing the current state like this isn’t nearly as useful as assessing future potential. After all, you’re not hiring a person from last year, you’re hiring who they will be next year.
The pattern of behavior I described above is the best indicator that someone will continue learning, growing, and accomplishing as a developer because they’re hard wired to do so. I know I’m not going to have to push them to learn new skills, worry that something is too hard, or hound them to deliver on projects. All I have to do is provide sufficient challenge and opportunity and wait for them to rise to it—they can’t help it.
Another benefit is that people can’t really fake out this question. People can look up the difference between call() and apply() or get their buddy to do the take home code test, but they can’t Google how to be someone else. Their life is their life and there’s no way around that. Sure, they can lie and embellish, but that’s pretty easy to sniff out if you ask a couple of follow up questions that dig into an experience.
The question also gives you a good understanding of what kind of teammate this person will be. Condensing 100,000 hours into 1 takes a lot of prioritization. How they choose to prioritize those experiences is a reflection of their value system. Do they talk about the experiences where they learned the most? Do they talk about team accomplishments? Do they talk about finding growth opportunities? Or do they talk about being treated unfairly, bad teammates, or organizations?
Honestly, none of these ideas are new and this interview style isn’t specific to technology. People that demonstrate this pattern of behavior make for good employees in just about every other industry too.
For some reason though, hiring developers has always had this shroud of mystery about it, like hunting for unicorns or finding Big Foot. Over the years, interviewers have concocted all sorts of byzantine mechanisms in attempts to lure and trap these mythical creatures.
In the end though, developers aren’t unicorns, or ninjas, or gurus. They’re just people. The best way to hire good developers is to hire good people.