When interviewing for a software engineering job, it's common to be handed a dry erase marker and told to solve some arbitrary problem:
"Write a function that determines if the letters in a given string can be rearranged to form a palindrome."
"Implement a memoization function."
"How would you sort an array containing up to 100,000 randomly generated integers?"
As an interviewee, I used to hate whiteboard problems. The pressure of having to understand and solve a seemingly pointless or obscure problem in front of a stranger is enough to give anyone anxiety. I'll never actually write a merge sort during my day-to-day responsibilities as a software engineer anyway, so what's the point?
Now, as I sit on the other end of the conversation conducting the interviews, I'm beginning to see the merit of this format. The truth is, watching someone code for 30 minutes can tell you more about them than you would ever learn by asking them a hundred theoretical questions.
In practice, a mix of theoretical questions and coding exercises is important to include in the interview. For now though, let's examine why the whiteboard questions are so crucial.
The Merits of Whiteboard Interviews
As you watch a candidate code, there are many skills and attributes you can observe:
Does the candidate ask clarifying questions up front in order to better understand the problem? Or do they immediately start writing code?
Does the candidate begin with thinking through some test cases to solve for? Do they only consider the happy path? Or do they also think about where things could go wrong?
How does the candidate organize their code? Are their variables and functions clearly named?
What sort of syntax do they use? For example, in JavaScript, are they using ES6+, or are they sticking with ES5? Do they reach for the
forloop, or do they use one of the array helper methods likemap,forEach, orreduce?If the candidate gets stuck, how do they react? Do they get frustrated? Do they freeze? Do they ask for help? Can they explain their reasoning to you?
How does the candidate respond to gentle pushes and other feedback from you? Are they annoyed, or do they welcome the help?
Can the candidate optimize their solution? If they started with a brute force approach, can they think of ways they could be more efficient?
Can the candidate poke holes in their own approach? Are they willing to admit to things they don't know?
The Shortcomings of Whiteboard Interviews
Even with all the benefits of whiteboard interviews, there are still some drawbacks.
There are two prevailing arguments against using whiteboard questions in interviews:
Whiteboard interviews don't actually test for coding ability - they test for anxiety.
Whiteboard interviews favor computer science students who are recent graduates and have all the algorithms they learned fresh in their minds.
To some extent, I agree with both points. However, I think both of these shortcomings can be mitigated.
Anxiety
Regarding anxiety, the interviewer should do everything they can to help the interviewee feel comfortable. If they look flustered, encourage them. Assure them that they're doing great. Have them take a couple deep breaths.
You could also assess coding ability in the form of take-home assignments or online assessments. When using these formats, you do miss out on being able to be there when they code and to help coach them, but you do still get to see their coding style. The other drawback is that these two approaches make it fairly easy to cheat. There are always pros and cons to every decision.
Favoring Recent Grads
To ensure your interview process isn't biased against those with non-traditional computer science backgrounds or against those who graduated from college a long time ago, it's important to choose whiteboard questions that don't require specialized knowledge of a certain algorithm or formula.
Instead, choose a question that focuses more on general problem-solving and less on regurgitating information from a Data Structures and Algorithms class.
Theoretical Questions
In addition to whiteboard questions, it's still important to ask some theoretical questions too. For a frontend software engineer, you might ask them about event delegation, closures, variable hoisting, the this keyword, or how the call stack works.
The thing is, though, all of those questions are easy to search for online. Anyone can memorize this information. As an interviewer, you may be able to discern when someone knows their stuff and when they're just reciting something they crammed for last night, but not always.
It's not until you see someone code that you can actually get a good sense for whether or not they have the right skillset for the job.
Conclusion
Love them or hate them, whiteboard interview questions are an essential part of the interview process.
Top comments (14)
I too use whiteboards - though in my case it's a "draw me a system you've worked on before" to assess their communication skills.
That's followed by "OK, now, talk to me about something that catastrophically failed in this system, how you fixed it, and what it taught you."
Nice one! It also shows how much a candidate understood about areas they didn't directly work on, which is telling a lot about how a person works and how they go about fixing stuff. There's a lot of candidates that think it's ok to ignore stuff outside of their strict area of competence. While it's possible to be proficient even with a very narrow focus, the mentality and willingness to look at the whole system (or at least outside the direct area one is assigned to) always leads to become a much more effective engineer.
When i get answers like "i don't know, this was X's job" i take It as an indicator of the experience of the person I'm talking to.
Also interesting to hear the follow up on the "something that catastrophically failed in this system, how you fixed it, and what it taught you."
"Whiteboard interviews don't actually test for coding ability - they test for anxiety."
Good point.
Whiteboarding feels more like Waterboarding. 🤣
Yep. This is the sole reason I’ll never get a single job at any tech company that whiteboards me.
"it's important to choose whiteboard questions that don't require specialized knowledge of a certain algorithm or formula." -really agreed on this one.
as a lot of hardcore folks will tell you that if you don't know this sorting algorithm or this whatever data structure, you lack fundamentals. heck I can't even remember sql foreign key creation syntax, but I'm building lots of full stack web apps and are already being maintained by different people and still run smoothly.
One good thing about whiteboard interviews is that at least they are time constrained.
I hate open ended take home assignment supposed to take four hours but obviously will take 16 or more because we are perfectionists and don't know how we will be judged.
Also I dislike online whiteboard interviews more than offline what, because there ask you to compile and run your code in their super crappy online IDE, which is a major distraction because pseudo code is all you need really
Absolutely! There are trade-offs with each medium you choose.
For take-home assignments, I think having really clear criteria for what the graders are looking for is important. And equally important is communicating that criteria to the candidate. I once completed a take-home assignment during an interview that was supposed to take four hours, and they clarified that they don't care how the end result looks and not to focus on styling it up to look nice, and that was incredibly helpful to me.
For the online editors, I've run into those same problems as well. As an interviewer I think you need to decide what you're trying to evaluate here: either the pseudocode and problem solving, or the actual code and whether it compiles. If the exercise is something like a test-driven development exercise, then the immediate feedback and the tests running in real time is actually really helpful! But if you're just trying to see how the candidate solves problems and if they can think critically, then I agree, the code shouldn't need to compile.
I mostly agree, but imo I like interviews that focus on actual challenges faced by the team better, plus they also help identify most of the red flags. However, I completely agree with whiteboard interviews for new grads.
Absolutely. The better the coding exercise models the actual work you'd be doing in the job, the better of a predictor the test is.
Google found that a "work sample test" (i.e. whiteboard questions, take-home assignments, any sort of coding for software engineering jobs) was the best predictor of job performance and was able to account for 29% of the candidate's actual job performance.
(source: Work Rules! by Laszlo Bock)
We would ask ourselves 'has it happened yet?' Referring to the virtual lobotomy all our newly promoted tech folks received when they jumped into management.
Inevitably after about 6 weeks they thought and acted differently. Only about 20% were still admired by us as they seemed to jump out of the trenches.
Funny how you didn't like these things until you switched positions.
We would always say. Gee if they hired us now, we wouldn't be here.
There's plenty material out there explaining all those kinds of things. Unless you're just starting, there's no excuse for not knowing at least the basics of algorithms.
The real question, which I've never seen answered, is do whiteboard interview questions result in better employees? How would on do a-b testing? Throw out WB tests for group A and use them for group B, then follow up a year (is that enough time)?
I think they are looking at our communication skill, we shouldn't be intimidated about giving the wrong answers.