Stop Whiteboarding
Let’s reevaluate how we interview software engineering candidates
The Interview
There’s a whiteboard in your future.
You’re nervous. You’ve wanted a new opportunity for some time and you’ve convinced a company to interview you. You’re putting too much pressure on yourself because you don’t want to ruin it. You’re capable. You’ve been programming computers for a while now. You like talking about this stuff. You like thinking about this stuff. You like meeting people who know more than you do about this stuff. But, you’re still worried.
Why?
You’re worried because you have a short period of time in which you can communicate your competence and passion to a complete stranger. You don’t know what questions will be asked but you do know you will have to answer them elegantly and efficiently. You have to win over this stranger because he is going to be either a brick wall or your bridge.
“Thanks for interviewing with us today,” a man wearing a gingham shirt, jeans, and black rimmed glasses says as you enter a sterile white room. He sits at a table with nothing before him but a green dry-erase marker. “Two of my colleagues will be joining us in a few minutes but I think we can get started. I’d like you to whiteboard an answer to the following prompt: given a string, write a program in any language you want that reverses the string.”
When did whiteboard become a verb?, you think to yourself as you grab the marker and stand before the empty board of fate. You write your code and your interviewer asks you questions as you evolve your answer. Eventually, time will prevent you from proceeding any further and your interview will end.
The Intent & History
According to one version of history, the whiteboard was created in the late 1950s by a photographer named Martin Heit who realized that he could write on his negatives with a marker pen that could be easily erased afterwards.
A second version reads that the whiteboard was created by in early 1960 Albert Stallion who believed that enameled steel could replace chalkboards. A third version of the whiteboard’s history is that Edsger Dijkstra invented the wall-hanging as a means for screening front-end web developers for the University of Texas Austin’s Department of Engineering’s internal website’s social calendar.
In 1975, Jerry Woolf created the whiteboard pen. And in the 1990s, the whiteboards grew to ubiquity after being marketed as alternatives to the dust caused by chalkboards. Today, the whiteboard is everywhere.
Since the whiteboard was only created in the late 20th century, we can rationally conclude that software engineers were not adequately interviewed prior to this. How could a hiring manager whiteboard someone without an adequate board that is of a white color on which to do so? And yet shockingly, software engineers were actually screened and hired before the advent of the whiteboard. And further, some of these screened-without-a-whiteboard-engineers were actually pretty good.
But it’s difficult to think about interviewing a potential candidate without a whiteboard. It’s how we were hired and as a result, it’s how we hire others. In most organizations, there is no training or investment in how interviews are conducted. We don’t think about it that much because we know it to be a simple tool to assess a candidate’s abilities in four specific areas:
- Communication and collaboration skills
- Job-specific knowledge
- Survival abilities when under pressure
- White-boarding skills
Outside Software Engineering
How does America hire welders? We now work for a construction company. In our new role, we have to hire some welders for our team.
The welders will be responsible for fusing metals for a series of new projects. They must have specific skills and they must be very talented because they will be working on critical parts of our infrastructure. So, how will we go about screening the welders to see if they have what it takes to work on our projects?
We whiteboard them, of course!
In the United States, the American Welding Society (AWS) certifies welders in a variety of different areas. There are certificates for structural steel, structural aluminum, bridge welding, railroad, aerospace, pipeline, and more. The AWS created these areas of certification in order to provide confidence for a welder and the welder’s employers. Welding is a dangerous, safety-critical profession that is a part of the fabric of modern industrialized living. Bad welds have catastrophic consequences.
But, companies don’t stop the interview process upon receipt of a welding certification. When screening a welder, hiring managers ask the candidate to weld. The candidate must showcase her skills.
Why? Shouldn’t the welder’s years of experience qualify her enough?
Seeing a welding certificate inspires confidence that a candidate can successfully pass a test. Like IT certificates, welders complain about holes in current welding certifications. Listening to the candidate speak about welding gives further confidence that the candidate can retain knowledge about the field. But, observing the welding process gives us confidence that the welder can do the job.
Welding has some parallels to software engineering in that both disciplines appear at face value to have an easy solution for evaluating a candidate: execute a task. The welder welds. The software engineer writes code. And as a hiring committee, we base our decision of the candidate based on the output. But like software engineering interviews, welders often are asked to answer questions that do not relate to the anticipated daily tasks for which they are interviewing:
If the daily task is welding on the edge of a razor blade, then that is what the test should be. — Jody Collier, weldingtipsandtricks.com
Don’t Hate The Whiteboard, Hate The Questions
The problem in software engineering interviews isn’t the act of writing on a whiteboard; it’s the questions being asked.
In general, we need to ask questions of software engineers. That can’t go away. In the same way we need to see a welder actually weld, we need to see a software engineer actually solve a problem.
The field of software engineering is so large today that it feels daunting to know everything. Rather, we can’t know everything. But, we sometimes interview this way.
We sometimes ask front-end engineering candidates to execute long bash commands. We sometimes ask Java engineers to build out an AngularJS application. We sometimes ask QA engineers to construct binary search trees.
The easy answer is to only ask questions that fall within the candidate’s domain of expertise. But, this only solves for job-specific knowledge. This doesn’t solve for communication and/or collaboration skills. We still need to find a way to ask a candidate questions in which we can accurately assess both #1 and #2 from our list above (#3 and #4 are less important, of course).
One Alternative
I changed my interviewing approach this year in order to try to assess both a candidate’s job-specific knowledge as well as her communication and collaboration skills by asking a large question that fit within the domain of the candidate’s expertise and comfort area.
For example, I interviewed a smart 22 year-old computer science major college graduate for a front-end engineering position. He didn’t have much experience but he was passionate and had all the inspiring energy every company needs. The first question I asked was, “what are some of your favorite websites today?” He answered enthusiastically about a website that he spends hours browsing every week. So, we used that website as our foundation. Over the course of the next hour, I asked him to talk me through how he would architect the front-end for this website. As he gave me answers, I asked what he thought the downsides and upsides were. I asked whether he, as a consumer of this website, would like to see anything done differently in terms of performance or usability. It went on and on. I didn’t know anything about this website. This was the first time I saw it. But by starting with something that he was excited about, it was easy to have a technical conversation in which I began to understand what he knew very well and what he was capable of learning to fill in his gaps. Our focus was less about his ability to solve a concrete problem than his ability to think critically by applying his technical knowledge to a product he knew well.
In another case, I started an interview with a senior backend engineering candidate with, “what are some of your favorite technical things right now?” The candidate immediately responded with event-stream processing. We spent the next thirty minutes talking about this topic. I asked questions. She talked about the differences between various options and how they would be implemented. We abstracted the conversation to talk about how this would fit in a larger system and then we talked more about the details of a particular event-stream process itself.
And in a final example, I interviewed a backend engineering candidate in which we talked about how he would architect Netflix’s service layer in preparation of a denial of service attack. Five minutes into the interview, the candidate told me that he didn’t know what Netflix was doing about a particular topic. My response was that it didn’t matter. It was less important to discuss what Netflix actually did than to understand what he would do.
I found this process for interviewing to be more informative than whiteboarding solutions to the “reverse a string” question. I learned a lot about how the candidates communicated their knowledge. And since the topics generally fell within the candidate’s interest areas, I also found the responses to be more inspired and creative.
Keep The Whiteboard
For the majority of candidates, we still need to ask technical questions that can give us insight into the candidate’s capabilities. Whiteboards neither help nor hurt but the questions we ask and the way in which we ask them can change the entire interviewing process.
Interviewing is stressful. It’s very hard to stand in front of a group of strangers and defend one’s abilities. I know some people who don’t leave their current position because they fear interviewing. How we interview can help those people.
And so, I’d challenge you to rethink your interview process so that you are interviewing a candidate in an environment that is less intimidating. Give your candidate a safe domain in which she can answer questions and I think you’ll get better visibility on whether this is the right candidate for you.
And if you have further ideas on how we can all interview better, please let me know.
