On whiteboard interviews - lazyblog
What follows is my highly opinionated point of view on the matter, I tried to write the few things I know and think about whiteboard interviews. I hope this helps. If you don't agree with something just comment below, email me, whatever works for you, I want to hear different point of views, me being salty doesn't affect my willingness to listen to people and change my mind.
Also sorry for the wall of text.
Practice, practice, and then practice some more. Whiteboard interviews are not related to software development, so to get good at them one has to specifically prepare, doing something different from the ordinary.
Pick someone and then go through interview questions in front of a whiteboard, best if you have a group, otherwise you will end up building your style only against that person. There are lots of resources to get questions from, I'll list a few:
- Cracking the Coding Interview: 150 Programming Interview Questions and Solutions, the relevant part here is "and solutions", this book teaches you how to refine an initially imperfect solution
- Interview Cake, they also send you a weekly problem
- HackerRank is used by a lot of companies, learn to hate the hidden test cases because during the take home assignment you won't have access to a large part of them
- LeetCode
- GeeksforGeeks
Whiteboard interviews are different from what we're used to in our every day practice, there are constraints that remove us from our normal workflow, possibly changing how we reason about problems:
- time constraint - usually we don't have to come up with a solution in 30-45 minutes
- peer pressure - stand up in front a whiteboard with 2+ people watching and taking notes
- no external help - like StackOverflow or Google, say what?
For these reasons one has to prepare differently before approaching interviews, the usual approach won't work. Luckily enough for the rest of us who can't invert a binary tree on a whiteboard, there are companies with a different interview process.
So, hopefully by now we agree that whiteboard interviews are different from our everyday work.
In whiteboard interviews you assess the candidate's
- problem solving skills
- programming skills
- behaviour under stress
- willingness to listen to suggestions
So let's see each of these in detail.
The focus during a whiteboard interview is on "what should I write so that it makes sense to them" or "what are they considering to be correct here", because in most cases a solved problem leaves a better impression. There is often a struggle from the interviewer to try and succeed in guiding the interviewee towards the result they feel to be correct. And a certain degree of insatisfaction if that goal is not met.
In 30-40 minutes there's little time for discussion, the focus is on finishing the exercise, the way it was meant to be finished, which is probably the most dangerous thing an interviewer could do in an interview: how could they assess the interviewee and their ability to reason about problems if all they are looking for is a correct solution?
If the solution is correct they saw you going through a straight path, you listed pro cons etc, all in line with the solution of the problem, showing some problem solving ability of your own in the process; conversely if the solution is wrong you went through a series of tricks and strategies to try and adapt to the problem, trying to see it from a different angle, removing constraints etc, all of this shows your ability to face a problem and fail multiple times while going through it.
So: you might show more problem solving skills (wtf is that anyway?) by failing at whatever problem they throw you, rather than at solving it.
How could you assess my programming skills by seeing me writing code in an editor that's not my own, not using my google-fu, I've never heard anyone looking at how interviewees use the keyboard, fire commands in the CLI, tweak their environments, wat? Ultimately all those skills are going to matter a lot, we will be sitting and coding away through problems so, "When are you going to assess my other skills? Because you are going to, right?".
You are really under stress, but not because your server is currently on fire or the product owner is raining stories over the team without any kind of social interaction, no, the stress here is of a different kind: you have 2+ people looking at you while you're solving a tricky problem. On the workplace you have 2+ working with you solving a real problem all together, everyone chimes in with ideas and suggestions, which requires a set of skills completely different to the ones needed for an interview; sure, you might say that the interviewer at some point might suggest some changes, and look at your reaction, but that's nowhere near to what happens when a colleague suggests a change in your algorithm.
This might be one of the things that one might understand about the interviewee, but right now I am ranting as you've noticed so I am not interested in the pros of whiteboard interviews.
When I'm stuck I usually try different techniques to fix the situation, what follows are approaches that I feel worked in the mock interview practice I went through every Friday during my batch at RC.
Things that you could do to unblock yourself.
It's ok to step back, realise an error or a dead end and take in the big picture again to see if the problem could be tackled from another angle. Usually this is pretty difficult to me because I feel it's like admitting defeat and the error I made, but in at least two occasions it would've helped me a lot, instead of, for example, pushing through the problem using a different data structure.
What happens to me is that my brain is somewhat resisting when I thing about starting over, usually suggesting things like "it will take too much time", "you don't know if the new path is better", "you will show weakness"; I interpret these as the brain trying all it can not to receive any more work, some kind of brain lazyness, because it seems a reasonable point to start over if the current approach looks invalid.
Usually you are required to do things in place and fast. Try changing that, it might be easier with a helper structure and doing it with two nested loops, just make sure to be ready for the incoming "is there a way to do it faster?", or "what if you have some space constraints?".
Sometimes you are given a data structure as input that's not quite what you would like to have, what if you had a proper data structure with everything you need, or what if you openly ignore the output format of your data and concentrate on something else that might look more difficult?.
The idea is to shape the problem onto your temporary understanding of the problem, and once you're done exploring the edge cases, the domain, and all the requirements introduce all the contraints that you removed so that you could focus on one piece at a time.
This might be a good idea, even as a general rule, approaching the problem without updating data structures, in place, or using helper data structures might give you additional insight that might lead to a smoother walk towards the solution.
Usually my first approach is slow and suboptimal, something like how this Google engineer did, of course without the Google and the engineer part, but you get the idea. Going straight into the perfect solution might be a risky move, and even if you do know the problem it might trigger another problem as question or even stricter requirements, something you might want in a whiteboard interview.
At this point I am talking about the stage of the interview where you are writing code.
Wishful programming. I first heard the term from a fellow recurser during a mock interview, the advice is to code the main body of the solution, leaving out simple functions for later, just name them properly and describe what their input and output are, usually they are trivially enough that the interviewer will agree in "leaving them for later".
Even if your're writing in an untyped language you still want to describe in some way input and output so that it's clear to you and the interviewer, you don't need to "what did I say this function took?" while you're going through a problem; assign a place on the whiteboard for this, you will have there a list of function signatures you are going (or not going) to code.
You might even want to do that to smoothen your mental process while thinking about the process, if you assume you have utility functions from a magical library your problem might look easier. It might also help you while thinking, "what if I had a function that reverses this array and removes odd numbers?".
Getting help from the peple interviewing you, within allowed limits.
Let the interviewer read what you're writing, you might as well just came out of a CS retreat with God himself , but if they can't read what you've written then what use is that? The font size of your code / reasonings on the whiteboard should take into consideration how distant are the interviewers and how much space you have, which brings us to the next point.
You have to use all the space available, we usually write from left to right, so starting writing in the middle of the
whiteboard might lead you to font-size: 4px, and you don't want that thought in your head when you're trying to figure
out Difficult Stuff.
What I like to do is to write the requirements and desired output of my program in the top left part of the whiteboard, so that the rest of the things will start from there, for example a first implementation or pseudocode sketch could go on the right, function signatures a bit above these, and so on.
Stand back, I know how to check if a singly linked list is a palindrome in O(n) time and O(1) space.
No really, I believe there are some, like learning to think about space and time complexity, algorithms and data structures, and so on, but still, if you went to uni (I didn't) you might've studied them.
This is already long enough, I will talk about this in a later post.