Historically, interviews have always been about the company. It has always been a way for an organization to evaluate candidates. And no denying, that is the purpose of the interviews, this is why any company would fund the interviews. And this is why the interviews are so boring to go through as a candidate, this is why I as a candidate would be unsure if I wish to join your organization, unsure if you are offering what I am looking for. What if there was a way to change this!?

Guiding Principles

A few months ago, we tried something that seemed to tick. Folks that went through our process were happier, looking forward to the next rounds, were almost always sure that they wanted to join us because they liked the team. Here is what we did, we made the interviews all about the candidate!

We identified some basic principles as guiding principles for the interview process and modeled the entire workflow around them. At every stage, if we wondered how to go about something, these are what we referred to:

1. There are plenty of companies the candidate could choose to interview with; we are privileged they chose us. We need to respect and appreciate that.
2. It’s impossible to judge a person in 60 minutes, let’s not attempt that. Acknowledge that every person’s current knowledge is a result of what they have worked on in the past. It is disrespectful and impractical to expect them to know everything about every technology we use! And what matters to us, is their attitude towards the work, their skill in identifying and solving practical problems; and nothing reflects this more than their depth of understanding of their work so far.
3. Interviews are two-way interactions. As much as it is about us evaluating the candidate, it is about the candidate evaluating us.

With these set, here is what our interview process looked like.

Coding Round

We are coders, and coding is what we are hiring for. This is the minimum requirement of the role; the ability to write clean, readable, maintainable, expressive code with tests to verify completeness and correctness; just the way we expect ourselves to write at work. This is a non-negotiable requirement, we have had to let go of candidates who asked to be excluded from the coding round. We aren’t very concerned about the language of choice of the candidate, as much as the quality of that code. Also, this is not a code-golf round, this is not about competitive programming, it’s about communicating with your team members clearly and effectively what you intend a computer to do. And the coding question is about setting the minimum skill level of the candidate, at the same time indicating to the candidate the minimum skill level of the team!

I am not going to get into how the coding question should be structured, I have written about it in the past.

Live Coding Round

Not every person demonstrated every skill we expected from them in the coding round, some were very far, and some were very close. At times, some submissions were so close and we felt that with little hint the candidate will be able to do better. At other times, we just suspected later in the interview that the candidate was probably not the author of the code they submitted!

And so, this round got added to our workflow. The purpose of the round is simple, give the candidate the experience of what it is going to be like when they join us. Work with them for 30-60 minutes and see how they work with you. Help the candidate to make improvements to the code by providing guidance and hints, see how they respond; just do what we do at work as a team. Again, to clarify, the ability of the interviewer to make suggestions does not automatically make them better programmers, it just identifies the importance of practice; interviewers have been doing this with multiple candidates, have seen a variety of implementations from lots of candidates and so gradually got better at this problem, is all; and our interviewers know this.

Panel Interviews

When we focus on the candidate and acknowledge that the candidate will not know the exact stuff we do; we also need to consider the aspects that a single person would usually miss in the interview. We can no longer rely on the opinions of one person, about the other. When we want to embrace the diversity of experience the candidate brings, we should evaluate them from diverse angles. We switched to panel interviews and ensured that the panel is from diverse backgrounds, this ensured that no one perspective wins. The panel submits their opinions and then discusses to agree about the result of the interview.

But this posed a different problem, candidates might find it scary, intimidating to see multiple folks joining the call! What better way to address the potential discomfort than addressing the discomfort. We needed to make sure that the interviews are perceived as discussions and not an interrogation! So we started the interviews by clearly explaining our approach, including why we have so many people on the call. Not just that, we also explained our guiding principles and clarified that we expect the candidate to interview us, rather encouraged it. We asked them to evaluate us, to evaluate every person on the call as their future team members. We asked them to ensure that they would like to work with this team, to verify that we are up to the mark as per their standards! We made sure the environment was friendly, welcoming and the candidate understood our process. And keeping with our promise, we made sure to ask the candidate to lead the discussion at least a quarter of the scheduled time, so they get enough opportunity to evaluate us.

This wasn’t easy for the interviewers, we had to train and coach the interviewers to be prepared to be interviewed! This further ensured that interviewers understood it’s the candidate’s choice, and they have no authority or power over the candidate, helping us avoid some of the common mistakes people do by mistreating the person they are interviewing.

One of our recent hires told us “I felt lucky this was an online interview for me, imagine if this was an offline interview, you are nervously sitting in a room and you see 4 people walk towards you, you would want to nope out of there! But it was all well once the discussion started, everyone was friendly, they explained the process and it made sense. It was clear to me that they valued me as a person and to me, that mattered the most”.

Discuss What Matters

Further to the process, we also need to define what matters to the team or org the most. This sets the topic of the interviews and makes sure we use the limited time we have in interviews focusing on what matters most. The most important hands-on skill was already proven by the time we all got together for the panel rounds. We intended to keep the discussion free-flowing, and our guiding principle already set the core skill we were looking for, “depth of understanding of their work so far”. So instead of defining an allow list, we defined a block list of sorts, describing the type of questions that we considered out of bounds in our interviews.

There are very few things on this list, but two of the types of banned questions I would like to mention here are the questions you find in ‘interview question banks’ and all ‘write x algorithm’ questions. These two types of questions were in direct contradiction with our guiding principle!

Anything you find in the typical interview question banks (StringBuilder vs StringBuffer, Application container vs web container, and the likes) demonstrate knowledge of technology, but do not cover the implementation; and this knowledge/dept was already covered in the coding question.

Every programmer should understand algorithmic complexity, should know all the basic sorting, searching, graph traversal algorithms and what they do well and where they fall short, there is no denying this. But asking people to recite these algorithms feels waste of time, besides, I would not want them to write these by hand in production either, I would want them to use an appropriate library instead, not rebuild it. Rolling out our own implementations of standard algorithms is not production-worthy code and reflects little on their ability to be effective members of the team. That being said what was not banned was discussions on complexity, optimization, the applicability of these algorithms in practice.

Wrapping Up

We have seen considerable change in the experience the candidates have after this change in our approach, at least is what the folks are telling us. We also seem to find good folks that work with our team well. Of course, your mileage will vary, but what is the downside of treating others as humans!?