And a Bad Way to Interview

I'm seriously considering Full Time Employment mainly because one of my clients wants to convert me to FTE and I love working with the client. But, I want to understand what opportunities are available. So, I've been doing a fair bit of interviewing.

Most of the interviews have at least some component of "whiteboard coding." "Whiteboard coding" is where the interviewer presents a problem and asks the interviewee to write code that solves the problem or implements to algorithm on a whiteboard.

Let's step back and look at the purpose of and constraints around interviewing.

The purpose of the interview process is for both sides of the hiring relationship to determine if the party on the other side is worth a long term, high dollar commitment... will the candidate deliver more value to the employer than the total cost of the employee? Interviewing goes both ways. And especially in tech, solid technical people are far scarcer than good tech jobs.

The constraint is basically one of time. There's very, very little time spent interviewing compared to the length of employment.

So, it behooves both sides of the interview to optimize the use of time in order to extrapolate from the limited information to an expected long term relationship.

For me, the interviewee, the most important factors in the interview relate to determining if I'm a team player because my highest value is helping large groups of engineers succeed. I listen for questions that get to the heart of how I can help others succeed. If the interviewer focuses on my ability to do raw coding, then they are making really poor use of the limited time we have to learn about each other.

And even for the most junior coders, the ability to write raw code or to know obscure CS algorithms is mostly useless. Even the most junior coder is going to spend 40%-70% of her day interacting with others and that's the most important thing to measure.

The Lunch Discussion

My personal favorite mechanism for interviewing tech candidates is to talk about a problem I'm working on and learning what thoughts and advice the candidate has related to my current challenge.

Why?

Because this is exactly what I'm going to be doing with the candidate if they join a team I'm on. We're going to talk through issues we're facing that day. We're going to do it at lunch. We're going to do it in meetings. We're going to interact and learn from each other in order to come to a better result than we would have individually.

How the person interacts in trying to help me is a good indication of their thought process, their ability to interact, their confidence in themselves, their willingness to explore ideas, etc.

Setting aside half an hour to work with a candidate on a real problem that I'm facing creates a situation like many situations I'll have with a co-worker.

Whiteboard Coding isn't Coding

Writing code on a whiteboard isn't the way I code. It isn't the way anybody I know codes.

Some people are planners... they spend a lot of time planning their object hierarchies or type relationships. Once they start actually writing code, the design is done. These people are less likely to succeed writing code on a whiteboard because it's not their natural style.

Some people are explorers. They use Test Driven Development to define the expected outcome and then explore with the implementation until it matches the tests. REPL users are a variant.

We all use IDEs that give use tooling and feedback as we're coding. Yeah, Sublime Text may give less feedback to than IntelliJ, but we use and are used to tooling that helps us.

Whiteboard coding has nothing in common with normal, day-to-day coding.

Whiteboard coding is a bad use of the limited time the parties have together because it tests none of the things that a candidate does on a daily, weekly, or annual basis.

Whiteboard Coding Pathologies

Yet, whiteboard coding is rampant in the tech world. At the end of the day, I think there are a number of pathologies that lead to its continued use.

Poorly Trained Interviewers

If the interviewers have not been trained on how to do an interview and how to evaluate a candidate, whiteboard interviews are a good way to give engineers a way to fill the interview time and have a proxy for evaluating the candidate.

But at the end of the day, tech companies are punting on training their engineers how to interview. Tech companies are substituting a bad approximation of "is the candidate technically skilled" that requires less investment in their existing staff.

The issue from my perspective is that any company that is using whiteboard interviews as a material part of the recruiting process, then the quality of engineers I'll be working with will be weaker than if the company invested in better recruiting techniques. This is a negative.

Proxy for Executing Code in One's Head

There is a class of programmers who execute code in their head. They basically understand how the CPU works and can execute code in their head.

There is a class of problems for which this mode of coding is super-useful and correspondingly super-limited. The class of problems are typically solved with small, modular programs that are built and maintained by a small number of developers. Much of Unix is like this.

So, if you're hiring folks to write stuff that's executed on Unix, short lived, and small enough that the code fits in a person's head, then whiteboarding a good proxy.

However, very little of what any of the computing landscape fits into this category.

The priesthood mentality that prizes neckbeards that code in their caves calls for this type of developer. Would you want to be part of an organization that prizes cave-dwellers?

But It's Good for the Candidate

If you're a candidate, then you are making as much of a choice as the interviewers are. Here are some pathologies that you can identify:

• "You chose Java for this example, but you should have chosen C." Yeah... if the language choice was important, the interviewer should have made that clear. What the interviewer is telling me is, "if we work together, I'm going to give you incomplete requirements and then blame you when the project doesn't meet the unwritten part of the requirements that I had in my head."
• "You missed an opportunity to make the code 10% more efficient." I'm sure I did. And in a production system, we'd do hotspot analysis and figure out what parts of the code we care about focusing on. What the interviewer told me was, "I prefer to show off my superiority in a domain I've worked in for a decade to helping co-worker succeed."
• "You used the wrong algorithm." "Which one would you have used and why?" "This other one... it's what we use here." Not being able to identify the difference between algorithms indicates that the organization values form over substance.
• "I didn't ask you to recite literature, I asked you to design a system." If the system I've been asked to design is the subject of a current CS research, then there's no way I'm going to pull a better solution out of my butt in 30 minutes. The pathology of shunning research is the "we're smarter than everyone else" problem.

What to Do

For me, I've dinged some companies that rely too much on whiteboarding because it's a leading indicator of weak candidate filtering. And when the employee pool is less than optimal, things will go pear-shaped when the company's stock stops going up. That's when the solid engineers will leave for the next high compensation opportunity, which will leave the folks who should have been filtered.

I use the interview behavior of the interviewers as an indicator of how they will be as co-workers. If they drive you toward a successful outcome and kibitz with you when you're coding, that's an indicator that they'll help team members succeed. On the other hand, if they play "gotcha" with the coding, they'll do the same thing if you join the company.

As an industry, we need to change recruiting techniques to focus on engineering candidates abilities to work with others and solve problems. Specifically:

• The "Lunch Problem" technique I discussed earlier
• For coding skill, evaluate the candidate's open source contributions or if they don't have a portfolio, then give them a take-home problem. In either case, assign an engineer to review the code.
• Look at a candidate's public interactions including how they behave in online communities, their blog and other public writing, and any presentations they've given. Use this information to see if they will fit the organization's norms for communication and advocacy.