Ask HN: Should we change the way we do software interviews? What's stopping us?

The things they ask you to code too... anyone who would ever let you commit that code to the codebase isn’t someone you’d want to work with.

I’ve been trying to cook up plausible examples but it’s a challenge.

I always ask them to read code and tell me what it does. 100% better than whiteboard coding because you can hear them working through it.

I would like to offer a partial list of practical ways to make software engineering interviews better.

1. As a candidate, if you are in a strong enough position to refuse the job, then refuse to do white board exercises with no resources. No one codes like this in real life so refuse to do it in an interview. Be willing to walk out. I just say "I'm a good programmer and your interview process is broken. If you want to hire good programmers it's your interview that needs to change. We can start that right now and talk shop as programmer to programmer about coding, or I can leave. I'm happy with either option but I'm not going to waste your time or my time with whiteboard exercises that don't find the best programmers. How often do you use composition over inheritance here? I've been learning a lot about that and it's really helping me write better code. Can I show you some of my recent code where I've been doing that and get your opinion on where it could be improved?" Remember that your job on the interview is not to follow their script. It's to prove to them that you are the best candidate for the job. Go off script and take control if they are bad at interviewing. If good programmers are regularly walking away from these types of interviews, the interview process will change.

2. Unless you've been trained to interview people, you are probably really bad at it. Think about how bad someone is at coding who never did it before and has no training. Interviewing people is no different: it is a skill that takes time and effort to learn. Get trained up, and practice with role playing with colleagues. As much training as you have time for. Educate yourself in your free time on a regular basis with articles about best practice. Adding more words won't make this sink in more, but I will end by saying I can't stress this point enough. You are bad at interviewing. You need to fix that before anything else if you want to hire good devs.

3. How are you measuring success as an interviewer? This is a really difficult thing to measure because how can you find out that your interview process is rejecting candidates who would make great employees? I'm not going to try to answer this here, but it's an excellent question to think about. One thing that might help is the next point.

4. Whatever your first impression is of the candidate, spend a good part of the interview trying to prove yourself wrong. Candidate seems like a perfect fit for the team and a great coder? Instead of relaxing because you're sure you already found the right person, see if you can figure out why they might be a bad fit or if their coding skills aren't as good as first impressions. Same for someone who seems weak at coding. Maybe they are just nervous. Can you make them relaxed enough so their awesome skills can come through? Maybe in both cases your first impressions will be proven correct. But if not you might have just found a diamond in the rough that other companies are skipping over.

I hope this very incomplete list is enough to get folks interested in following up on point 2.

London please. I'll be a customer.

> there is no right way to do software interviews.

In the context you presented this in, I agree with you. However, interviewing is a skill that must be learned or you are going to make loads of beginner mistakes. In that sense there are many right things you should be doing in an interview and whatever your company style is, you're going to want to use at least some of those best practices in your interviews if you want to find the best candidates in the shortest time.