Interview Performance Does Not Equal Job Performance

Interview Performance Does Not Equal Job Performance

2021-11-14

Interview Performance Does Not Equal Job Performance

This is a conversation I had when I was interviewing a few years ago:

Interviewer: “Yeah, a lot of candidates actually have trouble with this problem because it never shows up in the software we write.”

Me: “…so why is it part of the interview?”

Silence

interview image

There is so much content out there right now about what candidates can do to “stand out” and “perform” well on interviews.

What there isn’t enough of is content for interviewers to conduct better interviews. That’s arguably way WAY more important.

The biggest reason for that is in a supposed talent shortage, most interviews are still conducted in a way that evaluates interview performance and not job performance. The latter is the whole point of interviews. The former is irrelevant.

There is the added bonus that a lot of really smart people struggle to get jobs because they can’t play the interview game. If you focus on making sure your interviews evaluate actual job performance, then you’ll hire great candidates that other companies are rejecting. Win-win for you and the candidate.

I spent years with my peers working on ways to improve the interview process. We’re still working on improving because we treat conducting interviews as important a skill as building software.

One of the most critical things was implied with the quote at the beginning of this post: Make sure your interview question is actually relevant to the work.

I once greenlit a candidate who aced our interview process. The problem was we were copying everyone else and used an algorithm heavy interview. This candidate was brilliant in that area. Unfortunately, he wasn’t able to really do what we needed him to do. We needed someone who knew database schemas. We needed someone who knew how to do system design. We needed someone who could come up with creative solutions while working with other stakeholders at the company.

The problem was not the candidate we hired. The problem was we hired someone for the wrong job.

For every position since then, I always craft an interview question that is either a problem we have solved or need to solve at a company. I modify the question to fit a 1-2 hour technical interview (I have only recently gotten it down to 1 hour). If a candidate does well on the problem, then they would have done well with the actual projects we have.

This criteria hasn’t failed me since.

One important note in evaluating performance in this is to NOT treat your solution as the “correct” solution. Every developer is shaped by their experiences. They worry about the things that have burned them in the past and that shapes their solutions. The important part of the question is not the end solution, but why they make certain choices in their solution. Do they have good reasons or are they just picking blindly?

A really important note is nervous candidates. I have definitely made the mistake of going “Oof, I thought this candidate was going to be good, but they were too nervous to really show me what they were capable of. No hire.”

I know bigger companies have a more rigid process, but if you have the flexibility: give the candidate a redo.

I have not given redos very often. I don’t give them to every candidate that seems nervous in the interview. But there are situations where I will offer a candidate another technical interview round. Maybe they really impressed me in a phone screen and their technical interview was just a huge disconnect. Maybe I fumbled conducting the interview which threw the candidate off their game. Maybe they demonstrated some flashes of brilliance even though the overall interview was bad. Maybe all of the above.

Software developers are not performing sales. Confidence in high pressure situations is not required to do the job. If you think there is a good chance a candidate could do well given another chance, then please give them that chance.

These are some of the bigger things I’ve learned about conducting interviews. If you’d like to share some of the things you’ve learned or would like to discuss some other things I’ve learned, you can contact me @PBeekums