How to Impress during a Data Structures & Algorithms Whiteboard Interview

If you’ve already mastered the technical skills required for a Data Structures & Algorithms exercise, use this guide to improve your coding practices and technical communication skills.

The difference between a good interview performance and a great interview performance lies in the details.

1. Make sure you fully understand the question. Try out a few examples and make sure the interviewer approves. Ask additional questions about the range of the input, and the size of the input, etc. No better way to waste valuable time than to solve the wrong problem or miss a big part of it.
2. Mention that you’re looking for corner cases. Try to find them. If you don’t find any, explain why there aren’t any.
3. Talk about your ideas for solving the problem. Aim for the brute force solution first if you need to (and mention that’s what you are doing).
4. Talk about other approaches you are considering. Talk about the pros/cons/tradeoffs. Mention both time and space complexities of those options.
5. Then, start coding your solution. Don’t just blindly code without some approval from the interviewer or without explaining why you’re choosing one option as opposed to a different design.
6. Compartmentalize your code. If something needs to be a helper function, make it one. In fact, if the problem looks like it needs a large amount of code, just name your helper functions and mention that you will implement them with code later. However, note that you will have to convince the interviewer that you would have been able to finish writing out the implementation of those sub-functions if you run out of time.
7. Pick strong variable and function names that make sense. However, they should ideally be short, for ease of writing on whiteboards. Everyone knows that naming is a hard problem in software engineering. Do your best, but show that you actually care about good coding practices.
8. Watch the clock! The onus is on you to make sure you finish your solution or wrap it up on time. Don’t rely on the interviewer to remind you. Before the interview starts, know its duration. Note that many interview rooms are booked only for a specific amount of time (applies to both phone interview and onsite). The interviewer may aim to leave a few minutes at the end for questions.
9. Focus on getting a working solution down. If you need to clean up parts of the solution or get rid of redundant steps, you can do that later.
10. Your interviewer will likely ask the time and space complexity of your final solution. Go section by section (e.g. each for-loop or helper function) and systematically calculate the answer. Don’t just give the answer off the bat for the whole thing.*
11. If you do think you can improve your time or space complexity, mention how, even if you don’t have time to code it. If you’re confident that you cannot, due to some mathematical property, you should mention that as well.
12. Explain why your code works. Be sure to show an example case (a short one will suffice if you’re running out of time), but if you can actually prove that it works for all cases, that’s even better. For some problems, this may require some knowledge from your Algorithms class. For Dynamic Programming (DP), show why solving the subproblem leads to solving the overall problem (start with the base case). For greedy algorithms, you can show that the solution is a greedy algorithm and that’s why it always works.

*Whatever you do, don’t BS the complexities or make arbitrary guesses — this looks bad. If you’re wrong about them, your reasonings to get to those answers will show only more red flags. Caveat: if there is an internal function or data structure whose complexity you don’t know, then mention that and hopefully your interviewer will assist you or you can use that function as a variable in your computed big-O notation.