I never liked technical interviews

I never liked technical interviews. When I was a young developer, certain interviews made me feel so bad that I developed interviewingophobia – unconditional fear of all interviews. Instead of enjoying technical interviews and learning from senior colleagues, I tried to survive. Survive like prey, surrounded by all-knowing hyenas.

Building an interview process is like creating a product. If you create a product that people don’t like, you won’t get any users. Today, companies build products that people are afraid to use yet still expect candidates to line up for an interview. Something is wrong here.

The problem is that we design the interview process from the wrong end. We make the process convenient for interviewers, not the candidates. But the product that doesn’t take user interests into account cannot be successful. Users vote with their feet.

Instead of fixing a broken process, companies pay recruiters and hope that they will generate more traffic. It’s like pushing a shitty product uphill and paying for ads, instead of building a great product and enjoying organic growth, thanks to recommendations and word of mouth.

To attract the best talent, we must put the interviewee at the center of the process. It’s OK to make interview convenient to the interviewee at the expense of our convenience. The interview must provide so much value to the candidate, that no matter what interview outcome, the benefits should always outweigh the costs.

People often ask me:

How do I assess technical skills of a candidate? Should we do pair programming, a whiteboard challenge, or a homework assignment?

The answer is – it depends. What makes one candidate happy, makes another candidate miserable. Provide options and let the candidate choose:

I enjoy pair programming and can teach you a trick or two, but I can’t pair with people I don’t know well. I failed pair programming interview many times due to The Hawthorne Effect:

The Hawthorne Effect is a type of reactivity in which individuals modify an aspect of their behavior in response to their awareness of being observed and assessed.

When I am observed and assessed, adrenaline level goes up and my rational thinking turns off, leaving me with fight-or-flight mode on:

Some candidates, when assessed, can’t solve a basic coding puzzle. When the interviewer notices the issue, simplifies the task and reduces the expectations, performance declines even more. I am part of the club.

After the rejection, we have this “I could have done better” feeling. Then, in our comfortable environment, we open a laptop and solve the puzzle quickly. But no one cares because it’s too late. If someone asked, we would prefer a homework assignment.

But homework assignments are not for everyone either. No matter how hard you try, some candidates never accept homework. The most common reason is that, in the past, the candidate has never received any feedback. Pro-tip: if you ask a candidate to complete a homework, you must perform a detailed code review with recommendations and send it back to the candidate.

So, the candidate is not comfortable with a homework. The candidate is trying to break the hiring process! What a non-conformist! What a lazy person! He is not good enough to work in our agile software shop!

Rejected.

Some companies don’t practice what they preach. A good, agile company would provide options, such as pair programming, or ask a candidate what he or she prefers. How you interview people reveals how you work.

Personalization is the key to great interview. We must start building an interview process that works best for a candidate, even at the expense of our convenience. Every human is unique and our interview processes must reflect this.

To make interview valuable and convenient for a candidate, prioritise:

• Teaching over asking.
• Conversation over pre-defined questions.
• Personalization over tools and processes.
• Candidate experience over your convenience.

Job applicants will follow.