Coding Tests: How to Prepare, What to Expect
So you wrote a fantastic resume, made it past the HR screening, and now made it to the interview. The lead software developer asks some icebreaker questions… but a large whiteboard sits ominously in the room. It's obvious the technical aspect of the interview is about to commence — and you're afraid you'll have no clue how to answer the question asked of you.
Every developer has experienced the dreaded whiteboard test, and even the best of them have felt pangs of anxiety. So if the nerves get to you, understand it's a very common feeling and you aren't alone. Far from it actually. Whiteboard interviews are considered a pretty hot topic in the software engineering community. But, alas, they are here to stay.
Fortunately, there are many tactics to alleviate anxiety. This article covers how to prepare for a typical coding interview. The focus will be on whiteboard exams because they are typically the most difficult and most stressful. However, the advice we share can be applied to other types of coding tests.
First, let's talk about a couple of things that might be good to purchase to prepare for a whiteboard interview.
Practice at Home. Buy A Whiteboard.
One of the best ways to prepare for a whiteboard interview is to actually buy a whiteboard. Doing so will help you acclimate to the environment. Once you have your whiteboard, crack open a coding interview book — the best probably being Cracking the Coding Interview — and begin writing out the problems on your whiteboard. Under no circumstances should you look up answers on the internet or in the back of the book. After all, there will be no Googling during the interview, so avoid doing so while practicing.
Ask for some help from friends or family, preferably those knowledgeable in the subject matter. If possible, even a work colleague that you trust won't spill the beans. They can serve as the interviewers in a mock interview. Remember, interviews are just like anything else in life. The more you practice, the better the outcome. Now that your whiteboard and interview book are in hand, let's discuss how you should approach studying.
Understand "Go-To" Problems
There are thousands of questions that an interviewer can ask. That said, there is no way you can or should be expected to know every one of them. However, if you learn to answer 10 or so of them very well, then that information can usually be applied to other questions. Let's look at an example.
Let's say that the whiteboard interview has begun, and the prospective employer asks you to write out the merge sort algorithm in Java. Uh-oh. You never studied that one! The only one you studied was Quicksort; however, this can be used to your advantage.
Take what you know about Quicksort and apply it to merge sort. For instance, if Quicksort uses recursion, then chances are that merge sort does as well. If you can't remember a single thing about Quicksort, then it is perfectly okay to ask about how it works to jog your memory.
The second part of the questions says "in Java." Whatever you do, do not get hung up on the language itself. Don't think about semicolons, classes, or curly braces. Just focus on the problem at hand. If the interviewer asks what language you are using, simply explain that it is pseudocode and once the concept is complete it will be written in Java.
Communication is Key
The most important part of a whiteboard interview is the dialog between you and the prospective employer. It is not "one of" the most important things, it is the most important thing. Many interviewers would rather see the wrong answer from an engaged interviewee than the right answer from someone who does not know how to communicate. Here are a couple of tips for being an effective communicator during an interview.
The first thing to do is restate the problem. There is nothing worse than thinking you understand the issue and then coding something completely different. (Trust me, I've been there.) Start out by making sure you understand what the input is. Ask if the function takes one integer, an array, or both. Next, make sure to ask what the expected output is. Should it return an integer or a boolean? Here is a quick example of what this may look like using dialogue.
Interviewer: Write a function that reads a file and prints out each prime number inside of it.
Interviewee: That sounds like an interesting problem. So is the input a flat file?
Interviewer: Correct, and the numbers are comma separated.
Interviewee: I see, and is the output just void? Can I use print lines to display the prime numbers? One more thing, what is the largest number that I can expect to validate?
Interviewer: Good questions! Yes, use Java's System.out please. The largest number will be 100.
These are just a few examples of questions that would be worthwhile to ask. For instance, the fact that the numbers only go up to 100 means that a brute-force prime number algorithm would work just fine. This will really assist when developing the code. As an aside, it is always worthwhile to point out the courteousness of the conversation: politeness can go a very long way!
Whatever You Do: Keep Talking
Now that the question is fully understood, it's time to start coding. While coding, make sure to thoroughly explain the thought process. Even before writing the code, it sometimes helps to write a step-by-step. Let's look back at the problem given earlier. Recall that the interviewer asked: Write a function that reads a file and prints out each prime number inside of it. Here is a good way to begin the problem and also facilitate conversation.
Algorithm to solve the problem:
- Read the text file. Use buffered reader, scanner, or some other Java API.
- Break up line by line. Can be done using a while loop on a File object.
- Write a for loop to parse each line and get the number.
- Call an "isPrime" helper function on each number in the for loop.
- End program at end of file.
Now that the code has been broken into bite-size pieces, it doesn't look so intimidating. Also, keep requesting feedback from the interviewer. Pretend like they are the product owner in an Agile environment, and their feedback is required.
Now that the code has been broken down and approved by the interviewer, the pseudocode can be written. Once the pseudocode is written, then try writing it accurately in Java. Honestly, at that point anyone there will more than likely be satisfied, but it always helps to write it in an actual programming language.
No matter how much practice is put into a whiteboard interview, it will always be a stressful endeavor. In times like these it is important to remember that nothing worth doing is ever easy. Furthermore, bear in mind that folks who are giving the interview have more than likely been in your position, and can empathize. Just make sure that you have practiced problems on a whiteboard and performed mock interviews. Once you're actually at the interview, communicate with the interviewers by resting the problem statement and stepping through your logic. If you have done all this, you have already done more than most developers do to prepare.