A Better Technical Interview
A little over six months ago, I wrote an essay about how technical assessments are dumb. And that’s still true.
However, I think it might be useful to explore how I’ve conducted interviews with developers in the past and why I think the methods I’ve employed are better at building more technically proficient teams.
No Technical Assessments
I’ve made my stance on this perfectly clear. No technical interviews, no take home tests, no quizzes, no bringing someone into the office to fix your bugs, none of that.
What would I do instead?
You first need to consider the scale of the problem at hand. Most companies just need a few developers to build a simple web application. These applications aren’t very complex and don’t require complex algorithms or data storage models.
And no one’s life depends on the software the company builds. The most dangerous thing that might happen is that you mishandle customers’ financial information, which while still serious isn’t jeopardizing anyone’s personal safety. And even that competency is usually sourced to a third party, like Stripe or PayPal.
If this isn’t true for you and your company, then you’ll need to consider more rigorous interview processes, and you probably already knew that. But for 95% of software development jobs, neither the complexity nor the risk is very high.
Therefore, at most you need to consider whether a person is competent for the job they’re being asked to do and whether they’re easy to work with. And both of those things can be determined with a conversation.
What I usually do is separate the interview into two parts. The first part is an icebreaker. I’ll usually do a bit of research into the developer by looking at their LinkedIn, GitHub, or personal website, if they have one. From there, I’ll have a few questions about their life that I’m curious about, and the conversation usually flows from there.
This is important because not only am I determining whether I’ll be able to work with this person, but they’re also doing the exact same thing! Establishing an easy rapport is essential for a good interview, and I really want the people I’m interviewing to succeed. I’m not looking for a reason to disqualify them!
The next part is where we delve into more technical aspects. This takes the form of an informal design discussion, where I’ll ask the developer how to build an application quite similar to the one I’m currently building. I’ll usually ask this in one or two sentences, rather than a long, involved design scenario. After we talk for several minutes about their design, I’ll add a wrinkle or three that might necessitate a design change, better to reflect the shifting nature of development in the real world.
As there’s no parameters other than that, it’s usually up to the developer on where they take the discussion. I’ve seen some developers start with the database schema, others do some basic white boarding, and still others just talk the problem through in high level terms. This is all useful information, as I can begin to understand where exactly the developer’s interests lie.
And I can very quickly understand a developer’s skill level from this conversation. From the questions they ask me, from how they approach the problem, to how they design their solution.
Because the most important part of the developer’s job is thinking about the design to a solution. The next most important part is communicating that design to others.
But even determining whether they’re technically skilled or not falls second place to whether I want to work with them or not. You might think you only want the most technically skilled people to work at your organization, but that usually precludes hiring junior developers.
Most companies only see that they’ll need to invest a lot of time and energy into training junior developers. But that training is necessary in order to cultivate talent in your own company. And I feel like junior developers are necessary for a healthy organization.
Every time I’ve interviewed in this way, I’ve found better, more technically proficient developers. When I interviewed with a technical assessment at the core of the process, the developers I found were hit or miss.
There’s a couple of reasons for this, most of which I already detailed in my earlier essay. Technical assessments are pointless, they’re stressful, and they aren’t a useful measure of a developer’s technical skill.
But more importantly, if a developer can’t talk about software development in any sort of articulate way; if their mentality is more to plug and chug solutions or code without thinking; if they have no inherent curiosity.
Then all of this will be evident in the interview!
Anywho, I hope this has been somewhat helpful. I’d certainly like to see more and more companies stop using technical assessments in their own interview processes.