I don’t mean to call anyone out, but I want to talk about programming tests in hiring and contracting. Stop doing them.
This post originally appeared as a thread on my Twitter account. I’ve reposted it here for posterity with additional context.
I understand that people want to assess whether or not someone is capable of doing the job at hand. The problem is that every engineer, no matter how senior, is learning on the job, EVERY DAY. All of us lookup solutions on the internet, all the time.
Your assumption of what should be “baseline knowledge” for one person is based on your own experience. If you learned programming in college, a bubble sort algorithm is probably just muscle-memory by now; for the rest of us, it’s completely irrelevant knowledge.
It also has nothing to do with 99.9999% of jobs. Unless you’re working on some bleeding-edge optimization for a major, that sort of fiddly info is way less relevant that principles and practices. It’s just a great way of showing your biases towards “traditional” candidates.
The worst interview a company ever gave me was to implement a hashing algorithm. I’ve been writing code for 35 years, I’ve never had to do this manually. I failed. It also told me the company didn’t know what to ask me, I immediately withdrew my application.
Tech isn’t about algo knowledge. Bad news to my younger-self: it’s also not about passion. It’s about knowing how to solve problems. Instead of coding exercises here are a few ways to figure out if someone will be a match for the job you’ve got.
In short: don’t ask questions that have a single, expected answer. If you know what the answer is, you’ve created a knowledge-based test - and just like with authentication, you’ve created a bad one.
-
Ask them about a problem they’ve solved recently, have them outline the steps they went through.
-
Ask them about a piece of technology that has made their life easier in some way. Whether it’s a build tool or kitchen gadget, how does this relate to what we do?
-
Ask them what new tools they are excited about, and what makes their life as a developer better? (I specifically avoid saying “fun” here, because working for a paycheck not passion is a perfectly valid reason to be a technologist.)
If you want to hire senior developers:
-
Ask them about building for audiences that are not like them? How do we create solutions for inclusion?
-
Ask them about why they chose to not use a piece of technology. How did they evaluate it? Cost, maturity, stability, community?
-
Ask them what makes a good culture for a team. What makes a team productive and empowered?
-
h/t @justgrimes: Ask them to explain how the internet works. Details don’t matter, you want to see if they can read a room and communicate to the level of their audience.
-
My favorite EQ question is “what’s the last good thing you’ve read.” Book/blog/T&Cs/etc. I always add the answers to my reading list - but also high EQ people will usually reflect the question and ask you back. (Unless they’re nervous, so DON’T go on this alone!)
Here are a few other ideas I received on Twitter:
-
via @abbeysuekos: “I’m also starting to get into questions about how people work with those above them (managers/leaders/executives) and those below them (ICs). There are never enough ?s about how you treat people with less power than you… I love questions about projects that didn’t go well. Plenty of good candidates will struggle or even get defensive, and that’s a flag for me. Important to handle the framing carefully and create an explicit safe space, but when done well it’s golden.”
-
via @HimalMandalia: “Had an interesting experience with a tech test years ago. Turned out it was one I’d done already, so told them and said “how about instead I show you and talk through what I’m working on at my current place?” They agreed. So did just that. Got the job.”
Do you have other questions you use to help identify talented candidates, without jumping through programming test hoops? Tell me about it here!