Are whiteboard coding interviews really that bad?
A common thing to do if you want to be better at what you do is to hang out where the experts are. Listen to them, learn and open your world. In the world of software development, Twitter (and lately, Medium) is the place to be.
A few months back, this Tweet started a conversation:
If you don’t know him, that’s David Heinemeier ( DHH ), creator of Ruby on Rails. If you take a look at his tweets, you will see that David has a strong opinion about practices that are considered “standard” in Silicon Valley, like working long hours, favoring work over family, and basically the use of practices that treat developers as disposable resources instead of people.
The conversation was about how software companies use “whiteboard” interviews as a standard process to hire developers, and question how useful they really are.
When the creator of a framework widely used to create hundreds of robust applications all over the world (Twitter being one of them, at least for a while) openly declares he wouldn’t pass a basic step of a interview that any mid-level developer has to face in a lot of companies out there, what does it say about the process itself?
This resonated very close to home for me. A few months before that I interviewed at Google for a position that was exactly what I was already doing every day for a living at that moment.
During the phone interview I was faced with two data structure algorithm problems that I failed miserably. It brought to me a good case of imposter syndrome.
I couldn’t gasp how being able to come out with an efficient way to find all the palindromes in a string in a Google Doc in under 20 minutes had anything to do with integrating Enterprise applications. If someone even tried to code in a Word doc, I would be seriously concerned.
David’s tweet brought attention of a lot of people who, like him, would fail whiteboard interviews:
It’s not a secret that whiteboard interviews is a dreaded process in interviews nowadays.
While I truly believe that my experience with Google helped me to work harder to become a better developer, I can still see the flaws in the process.
The mix of pressure, a lack of a compiler, and not being able to look to documentation puts you in a position that little to no times would you find in your day to day work.
If great developers like David would be excluded by this process, why do companies keep doing it?
Gayle Laakmam, writer of “Cracking the Code Interview” explains that these problems are made for interviewers to understand how you work under pressure: Do you ask enough questions if you don’t have enough information? How do you work as a team member when you get stuck in a difficult problem? Do you stop when you find a solution, even if it’s not optimal, or do you keep trying until you find a better solution?
As a meta exercise, it sounds like a good way to know if your candidate will do a good work in your team. The problem is that it seems interviewers very often miss this point: If you resolve the problem in a way they don’t like, a lot of them will consider it wrong. It doesn’t matter if it works or not:
These problems are also oriented to see if you understand basic computer science concepts like time and space complexity, or the correct use of data structures. However, for a lot of interviewers (who already have the answer beforehand) don’t settle for just the correct use of a linked list; if you don’t throw the most efficient way to find the median in it, you’re automatically rejected.
And this brings a contradictory problem: performance is all about measuring and trade-offs.
Most of the time, an algorithm which might not be the optimal solution is a perfect acceptable solution in a real world application. Hell, sometimes finding the optimal solution is a waste of effort: You can live with an algorithm with linear time complexity (instead of log n) for datasets relatively small. I don’t want a developer who spends extra time finding a better way to do something which is not really a performance problem.
This is because performance is all about measuring. Don’t waste your time over-optimizing things that are not really a problem to begin with. In some moment, you will have to live with non-optimal solutions in order to put your effort in another place that really needs it.
It might seem that whiteboard interviews are more a rite of passage: “I suffered through it, do you have too”.
Worst part is, even as strict as whiteboard interviews might seem, the truth is that if you spend enough time solving problems in places like Leetcode, you might ace them without really knowing how to do real-world software development.
The other side
Now, going the opposite side of whiteboard interviews has its downside. I know teams with a low bar for developers to reach during interviews. “Can you answer “trivia questions” (what is polymorphism?)? You’re hired”.
I’ve struggled with multiple co-workers because they weren’t correctly filtered during interviews, and since they could Google the questions during the interview, once you have them working in your team you find out they don’t have the experience you expected.
Many times me and my co-workers have asked ourselves: “why wasn’t this person’s lack of experience caught during interviews”?
I’ve interviewed developers who do an excellent work answering your questions only to find later that, while they understand the concepts, they don’t know how to balance software performance and available time and budget.
Whiteboard interviews might seem like this missing filter, but it’s difficult to apply them in an efficient way.
Is there a solution?
Do you want to know if a developer has the experience you need for your team? Set them against a real world problem, with real world resources (compilers, Google, time).
Some people recommend to give candidates defects you’ve had before and have them solve them in the same time it took your team to fix them. Give candidates problems to take home and then sit down with them and have them walk you through their solution. Have them solve problems with people in your team.
It means you have to dedicate time and effort from your team to find right matches, but you know what? At the end of the process both you and your candidates will know if you are really made for each other.
If you want to keep your whiteboard interviews, that’s fine, just don’t miss the point of why they were created in the first place: To find people who knows how to solve your day-to-day problems, not math trivia.
