If collaboration is part of your work culture, it should be part of your interview. Photo by Kaleidico on Unsplash
Whenever I’ve faced a challenging problem at work, I’ve had help. Help can come in many forms:
-
When putting together a complex system, I talk to domain experts who know about each part of the system. I’ve never had someone say they don’t want to help me.
-
Before implementing a non-trivial design, I’ve documented the proposed approach and requested feedback. Even before getting to that step, I often whiteboarded potential designs with someone else on the team to make sure I understand the problem adequately.
-
Even for individual code changes, I go through a code review process where others point out issues they see in my code. From ideation to publishing my change, automated tooling and human review go into making sure the change meets the bar we set for ourselves.
The reality is that we bring out our best work when we collaborate. No one is out to attack my proposals, so the criticism is constructive. The goal is to produce something better than one person could on their own.
So why do so many interviews measure the ability to work on your own? In an effort to weed out candidates who don’t meet the bar, interviews tend to be antagonistic, a battle between the candidate and the interviewer, to see who comes out on top.
If our best work happens collaboratively, the interview should also happen collaboratively. As an interviewer, you need to set the candidate up for success, which you can do in the following ways:
-
Gear the interview to the candidate’s strengths, instead of trying to test their weaknesses. Take into account their experiences, and ask them questions based on what they know best. Your goal is to see the candidate at their best.
-
Explain what’s expected right off the bat, so the candidate can meet the requirements. After all, how can they deliver their best work if they don’t know what they are expected to produce in the first place?
-
Help the candidate with the small stuff. Normally, developers have many safeguards that prevent bad code code from getting to production. In the interview, you are their safeguard, so respectfully point out smaller errors (or let them slide) so the candidate can get to the really important parts.
All of this doubles for less experienced candidates, who you expect to be mentoring on the job anyway. For them, you probably want to help them even with the big stuff. The evaluation criteria is much on how they respond to your collaboration than on the specific pieces of knowledge they have.
I’ll go over these and other ways to help the candidate succeed in future editions. In fact, I’ve already talked about clear expectations in a previous post.
As an added benefit, this process allows both you and the candidate to understand what it’s like to work with each other. This is good for you as an interviewer, because if the candidate passes the interview, you’ll be working with them in the future. But this is also great for the candidate: an antagonistic interview may be an indicator of an antagonistic work culture.