A Sane Technical Interview Process

There has been much discussion about how the interview process for software engineers is broken. Some senior engineers even refuse to do technical interviews. Here’s my opinion on some improvements that could be made to the process:

No Whiteboards

Obviously real-world programming is not done on a whiteboard. This practice is an inconvenience to the candidate for the benefit of the interviewer. Instead I propose letting the candidate solve problems on an actual computer, using a projector to share the results with the interviewer. This has the added benefit that the interviewer can sit beside or in front of the candidate, out of view. This eliminates some of the anxiety and distraction that comes from having somebody looking over your shoulder.

BYOK — Bring Your Own Keyboard

This one is related to muscle memory. Adjusting to a new keyboard (or a whiteboard) can take a few minutes and is likely to throw the candidate off a bit. Allowing them to bring their own keyboards will let them jump right into problem-solving.

Real-world problems

A common criticism of algorithmic challenges is that they don’t necessarily reflect the day-to-day work at a given company. Another might be that many of these problems are posted online and can be simply memorized. Instead, show candidates old examples of real problems your company has faced and solved.

Multiple Interviewers

This one is done already by some larger companies. Sometimes an interviewer might have an off day, or might have some bias towards a candidate for whatever reason. Some are even incompetent. It’s important to have each candidate evaluated by multiple people to hopefully help average out some of these errors. After all it is supposed to be the candidate being evaluated, not the interviewer.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.