Written by Rodney BarnesOctober 07, 2019
Interviews are a gambit, for both parties involved. Both must trust in the process set up by the company and the hiring manager to select the candidate best suited for the job, but so often that process is flawed or, worse, completely misguided. I'll be covering what you can do as a candidate in this situation for another blog post later this month, but right now I'd like to address those on the other side of the desk.
I was listening to a podcast published by Rework and the folks at Basecamp, who discussed with Aja Hammerly, a developer advocacy manager at Google, about her blog post on interviewing, and their talk summed up a lot of what is wrong with current technical interviewing practices and confirmed what I think should be the goal of any job interview.
Hiring managers who set out to separate the proverbial wheat from the chaff by using the typical set of techniques - technical trivia questions, whiteboard solutions, and take-home projects - are undermining their efforts before a candidate's even stepped foot in the door. The problem, as Rework host Shaun Hildner points out, is that "the people doing the hiring are not looking for your strengths, but instead are trying to expose your weaknesses or get the better of you - or, even worse, prove how much they know."
Rooting out someone's weaknesses doesn't give you as accurate a picture of their abilities, and their suitability for the job, as does highlighting their strengths - and where the former is generally easy, it's the latter that proves the true challenge. How do you get someone to shine in a situation where they're already under pressure, and nervous, and more likely to stumble than stride?
Even considering that question is a good start. It's tempting to approach interviewing adversarially; you want to see the limits of what that person is capable of, to push them and test their boundaries. However that approach makes it too easy to have your ego get in the way of the entire reason you're going through this process in the first place.
"The goal is not to feel smart," says Aja in the podcast. "The goal is not to make the candidate feel dumb. The goal is not even to find the edges of the candidate's knowledge...The goal is to figure out what the candidate is awesome at and then figure out if that's what your team needs right now."
Hiring is hard. Especially in this field, where there are generally more jobs than developers suited for the work, and finding the right fit is both expensive and time-consuming. You don't need the very tool you're trying to use to make that fit working against you as well.
It's well worth listening to the entire podcast or at least reading the transcript, particularly if you've used some of the above techniques in your own interviews. For those who have had the pleasure of being the recipient of these sorts of questions, I'd like to leave you with Aja's encouraging message:
"I just wanted to tell folks that I know it’s hard and that things are getting better and that if a particular company knows their hiring process doesn’t work for you, it doesn’t mean that you are not a good developer and that you will never get hired anywhere. It just means that that particular company’s hiring process didn’t work for you, which probably means that company didn’t work for you."