Thoughts and Updates from the Hedvig Blog

Subscribe to the blog
Get updates sent directly to your inbox

4 interview questions I ask every engineer (whiteboards are involved)

by Matt Johnson on August 11, 2016
J Hedvig

There’s been a bit of a resurgence recently in the debate about the merits of the whiteboard interview – that it’s beyond out of date and a model for perhaps the worst way to evaluate software engineering talent. Of course, the most common response to this criticism is, “Well, this is just the way we’ve always done it.”

Ok, full disclosure: We do use the whiteboard at Hedvig in hiring, but it’s hardly the be-all and end-all of the interview process. It’s simply one part of many in finding the best fit between Hedvig and job candidates. If correctly structured, the algorithm problems and coding challenges will give meaningful information to both the prospective candidate (these problems shed light on the type of work a candidate will see when they join the team) and to my team.

Here at Hedvig we like to know more about candidates and their thinking style rather than just testing their abilities, so we stay away from rote examinations that other companies often use to winnow out as many candidates as possible. I’ve interviewed hundreds of engineering candidates over the course of my 20-plus year career, and with that experience, I’ve found it’s best always to include the following four particular questions in each and every interview.

Question 1: What is your most successful project to date, and why was it the most successful?

We ask this question to understand the candidate’s thought process. The project itself is actually irrelevant; what’s key is the ability to articulate technical information in a group setting and to demonstrate that the person can think clearly about why something worked out well.

One of our engineers once asked me, prior to interviewing a very senior candidate, “How do I really interview this candidate? He knows more about ‘xyz’ subject than I ever will.” My answer was simple: If the candidate can describe a complex project so that you clearly understand its value and its concept, you have proved that you can learn from the candidate as well.

Also, candidates who attribute their success to their team rather than to their own singular brilliance are often better able to adapt to our collaborative environment. At Hedvig, we shy away from developers who aren’t team players and instead fancy themselves rockstar coders.

Question 2: Have you worked with any distributed systems and, if not, what is your comfort level around these concepts?

Our founder and CEO, Avinash Lakshman, built the company with the focus on bringing a distributed systems mindset to storage, an industry that has seen only incremental innovation over the last decade. As a result, everything we do at Hedvig is built around distributed systems and our most senior engineers know them like the back of their hand.

We recognize that few new developers and computer science graduates come to us already steeped in all things distributed computing. Even experienced developers may not have distributed systems experience. But we do expect our candidates and employees to have at least a passing knowledge of technologies such as Apache Cassandra and Dynamo. Put simply: distributed systems as an architecture does not mean you can run your application across multiple nodes, and we definitely don’t consider client/server architectures as distributed. A sophisticated and nuanced understanding of distributed systems comes in time, and we’re big proponents of learning on the job. We’re looking for those with a passion for doing things in new ways.

By the way, it’s usually at this point that a candidate will jump up to the whiteboard (or be prompted to do so) to illustrate distributed systems concepts.

Question 3: Are you comfortable talking with customers?

Even though we’re fortunate to have won large, enterprise customers, we’re still a scrappy startup. Avinash can often be found side by side with our engineering team, working out the kinks or optimizing a customer’s deployment of the Hedvig Distributed Storage Platform. In short, we wear many hats. Our engineers also assist with customer service and are often on the phone with customers to troubleshoot any issues. This is a valuable loop that enables us to build loyalty among our users and receive direct feedback to improve the product.

Question 4: What is an example of a project where you failed or did not have a successful outcome, and what would you have done differently?

This is the final question that I usually ask to bookend the interview. It is very much about ferreting out how the candidate thinks rather than what she or he has done. In addition, the candidates we hire have already learned how to admit mistakes, learn from them and take that knowledge into new projects and endeavors. We look for people with an insatiable desire to keep learning and improving their programming skills.

Everyone fails at some point, and the lessons you learn by picking yourself up and starting again often help push you to the next big achievement or breakthrough. At Hedvig, we’re doing something that hasn’t been done before, and we need folks who are OK with taking the risks associated with such innovation.

Not the be-all and end-all

So why do we value whiteboard skills when they’ve suddenly become so passé? This is partly because our engineers are often also teachers – sometimes explaining their code line by line in group code reviews. Or check out this pic of Avinash holding court with some of our engineers as he whiteboards distributed systems concepts.


As a result, we often see more extroverted applicants do a bit better in this portion of the interview. At the same time, whiteboards are by no means the only criterion on which we evaluate people. To be flexible, we often also give a homework assignment so candidates can spend time on a problem at their own pace.

I’ve even had a few engineers ask not to use a whiteboard and instead offer to walk me through a side project they’ve built themselves. And that’s fine, too. As Jon Evans at TechCrunch wrote last year, “Every candidate must have a side project that they wrote, all by themselves, to serve as their calling card.”

Again, the whiteboard and the side project are tools for me to better understand how candidates think and why they did what they did and not just focus on the end result. So if you think you have what it takes to answer these questions — with or without a whiteboard — then apply today!

Apply Today!

Matt Johnson

Matt Johnson

Matt runs engineering and development for Hedvig. Matt has more than 15 years as a VP of Engineering. Most recently Matt led the File Services teams at NetApp.
See all authored articlesÚ