My Interview Experience and What You Can Learn From It
Photo by Daniele Levis Pelusi on Unsplash
I’m going to come out and say it. Developers are awful at conducting interviews, and it’s not even their fault. Expecting anyone to conduct interviews without any training or direction about what should be done inevitably yields poor results.
These days developers are often asked (without supervision) to conduct technical interviews “since only someone technical can judge a technical candidate” (source: My old CTO), but in some companies, they screen candidates, run behavioral interviews and make hiring decisions. Which are all invariably awful, since they’re run by people who couldn’t care less.
This shouldn’t be all that controversial (but I’m sure the haterz will come out in the comments). This is because software engineers aren’t recruiters, HR and they didn’t sign up for this.
My Experience of Interview Apathy
Over the years, I’ve witnessed some truly spectacular displays of apathy in technical interviews. Here are some of the examples that stick out in my memory:
The Silent Treatment
An interviewer stared at me like I was an idiot, but offered nothing as we simply sat there when I couldn’t answer a technical question. We shared a long, awkward silence while I debated if I should offer him a cup of coffee to wake him up.
The Trivial Pursuit Round
“What are final, finally, and finalize in Java?” Why not just ask me to define vowels while you’re at it? It’s like quizzing a surgeon on whether they know what a heart is.
Overeager Hints
You know those quick-fire interviews where you need to get the exact answer written on the interviewer’s cheat sheet? Yeah, that but in this case, I barely had time to process the question before the interviewer started spoon-feeding me the answer. They even interrupted me at some points to tell me what the answer was.
Chair-Swivel Enthusiasts
I’ve seen stories where during an interview a developer turns their chair around, leaned on the armrest, and spends the whole interview admiring the wall.
That hasn’t happened to me. Yet during interviews I’ve experienced a wide variety of disengagement from interviewers. Some don’t ask any questions, leaving the “doing” an interview to a colleague. Some (most) don’t read my resume before the interview (asking how many years of experience I have when it’s literally at the top of the resume). Most don’t seem to know the answers to their own questions and lack any depth of knowledge at all.
The Root Cause:
I’m going to call it. Nobody wants to be there.
Developers don’t care about interviews because it’s not their job. Managers think they can shove interviewing onto developers like it’s just another Jira ticket, and developers feel like they can’t say no to the request.
It’s one thing quickly looking over a pull request and saying “LGTM”, and quite another to conduct a competent interview. To do the latter takes effort and practice, and for anyone to assume it can be done in between Agile ceremonies is a rather large mistake.
Furthermore developers lack any incentive to create a great interview experience. No bonus is offered, no recognition of the effort involved and seldom any feedback loop to allow people to improve. It’s just a case of “We need more bodies on the team” at best, and at worst “I went through an awful process, it’s a rite of passage, so I’ll do the same to applicants”.
What Managers Don’t Get
Interviewers are difficult. Let me ask you this: when’s the last time you saw a developer who wanted to handle:
Legal matters?
Socializing with people?
Phone calls?
Eliciting the best work from fellow developers?
Corporate paperwork?
So when an interview combines these in an intense and stressful session it’s unsurprising things go wrong. It’s not a developers expertise, it’s not their passion, and it’s certainly not in their job description.
If a manager asks you to complete a poorly defined task with no success criteria and no motivation for doing it, does it get done?
I remember a time I had to interview and asked the hiring manager should be interviewing for skills, potential or experience and got told “yes”. I mean, really.
What Developers Don’t Get
On the flip side, developers also don’t realize they can just say no. Seriously, it’s an option. Next time you’re ambushed with an interview request, try one of these responses:
Time
“I need time to prepare. Interviews require thoughtful questions tailored to the candidate’s experience and resume. If you wanted me to do this, you should have told me when it was scheduled.”
Translation: I’m not winging this.
When You Just Can’t Be Bothered
“I’ve been in interviews with developers who hated every second of it, and I refuse to inflict that on another person. Interviewing isn’t my responsibility, and frankly, I don’t care enough to do it justice.”
Translation: Don’t make me spread my misery.
A Better Approach
If you want developers to care about interviews, you need to make it worth their time. That means:
Training them on how to conduct effective interviews (because “winging it” doesn’t cut it).
Explaining why hiring the right person helps them directly.
Giving them veto power over poorly planned interviews.
Giving them time to prepare, and time to write up the results of the interview.
If you give developers these things you can expect a better output from them, and you can measure that and give them feedback. You might even make their performance part of the review cycle and see how they get better over time, because recruitment is so important to the fabric of any company.
Conclusion
Honestly, who can blame developers for phoning in their interviews, as it’s “just another task” thrown over the wall at them. If we want to engage with seriously interviewing software developers and want to get the best in our open roles we need to work for it.
Like anything in life, if you want good results you need to invest time and energy. Isn’t that obvious?