Whiteboard Coding Measures Penmanship While Nervous

Every time i go through the interview process i am reminded just how terrible tech interviews are. We ask questions that tell us if a candidate has read an algorithms book lately and assume it speaks to their ability to code well.

This approach isn't just flawed, it's uninviting. Interviews should encourage a candidate to want to work for your company. Instead, tech interviews can be belittling, devoid of fun and soul sucking. We, who brand ourselves problem-solvers, have a problem.

Let's return to the basics. Our interviews should achieve a few requirements without exception.

1. Identify traits the best developers we know share
2. Any/all coding takes place on the interviewees laptop with full internet (and google) access
3. Be an interview we would enjoy taking with another company
4. Every question has an explicit and well understood purpose

Interviews that maintain these ideals will identify quality candidates more easily. They will also help sell your company to your candidates. It is easy to forget, but good candidates don't have to work for you. You need to make them want to work for you, as well.

The best developers

Pretend you are starting a dev team for a new company and have the ability to hire any 5 developers you've worked with. Who would you take?

Take this list and use it to judge your interview process. Would all 5 of them crush your interview? Would you leave the interview, look at your team and say "that is who we are hiring" as soon as they left the building? If not, your interview is wrong.

This is the litmus test you should be using for all of your interviews. Identify the traits that make the best developers you know so good. Are they great problem solvers? Communicators? Do they have a knack for asking the right question or finding the answer on google surprisingly fast? Whatever those skills may be, design an interview to identify those traits.

Coding questions

The entirety of my interview process includes one coding problem. One! It is sent to candidates via email and they code it on their machine, in their environment. If they want to use google or stack overflow, they can do so. They are shielded from the fear i would notice and judge them for it.

Remember that the purpose of coding exercises is to identify how someone codes. Like any test, we should be eliminating variables to best determine the result. That means things like whiteboards and not giving someone access to google. Perhaps worse is making them code in an editor they are unfamiliar with. None of those exercises tell you how someone codes. The only thing whiteboard coding measures is penmanship while nervous.

When looking to design your coding problem(s), make them representative of the skills needed to work at your company. If you need algorithmic thinkers, be sure that is covered. If you care about test coverage or code architecture, be sure to ask a question of sufficient depth to gauge those competencies.

Finally, the best coding questions have different explicit and implicit depths. If you intentionally leave some of your requirements vague, but unambiguous, you will learn real fast which candidates ask questions and which make assumptions. The ability to recognize implicit problem depth is one of the most important things my coding question identifies for me.

Fun interviews

From the very first email my interviews are conversational. This is done to try and inject some humanity into a traditionally shitty process. It is also reflection of my personality. I want to design interviews that i would enjoy. We forget that interviews are 2-way streets. A candidate is trying to sell you on their abilities. You are trying to sell your company to them at the same time. We have all left interviews with companies thinking to ourselves, "you couldn't pay me enough to work there." A conversational interview can help avoid that.

This is another reason i avoid silly coding questions during the in-person interview. The goal is to create an environment that gives a clear view into a candidate's ability while maintaining an enjoyable process. I know no devs who enjoy whiteboard coding. So it's gone. I hate long interviews, so mine lasts just over an hour.

One other point on making enjoyable interviews is how you treat the candidates turn away. I try to reply to each of them individually. I let them know we have moved on, give them a positive aspect of their interview and one thing i think they could improve. I suppose i could try to argue that this helps improve the market perception of a company. In reality, i do it just because it is what i want companies to do for me.

Questions have a purpose

Much of this post comes down to increased empathy without sacrificing your ability to accurately scrutinize candidates. This necessitates gaining a more complete understanding over your questions and their goals. A good place to start is with a list of desired skills. List out every skill you want a hirable candidate to have. Categorize them into two groups: must haves and nice to haves. Be granular in this exercise. Expect to have 5-10 must haves and 3 or more nice to haves.

Once you have identified a list of skills that are required, create questions that cover each skill. Often, a single question will touch on a few of the skills required. This is a good thing. As above, some must-haves will be more important in daily operations. Those probably warrant being redundant question coverage. That and fewer questions means a shorter interview. Everyone wins.

Saving time

Interviewing has two distinct goals: repeatably identify the best candidates to hire and do so in as little time as possible. For engineers, being pulled out of the codebase to interview a candidate is one of the most distracting contexts shifts. If you calculated the expense of interviewing candidates solely by the opportunity cost of developers' time, it would be expensive.

Shave out unnecessary questions. Standardize your interview to a tee. Respect a candidate's time, too. If your interview(s) collectively take over half of a day, you are wasting everyone's time. A couple of hours is all it should take to identify if someone is a good fit.

If not, that says more about the interview than the candidates themselves.

tl;dr: These changes will help you identify great coders. They will also make those engineers want to work for you.