Now it’s time to solve the questions, but don’t just jump in. Instead, remember you want to fully understand the problem. You should try an example, and then focus on the algorithm that will solve the problem. You then want to explain your solution and code for the solution. The following steps walk you through the process:
The best way to solve an interview problem is to approach it methodically. Here are the suggested steps:
Make sure you understand the problem. Your initial assumptions about the problem may be wrong, or the interviewer’s explanation may be very brief or difficult to follow. You can’t demonstrate your skills if you don’t understand the problem. Don’t hesitate to ask your interviewer questions about the problem, and don’t start solving it until you understand it. The interviewer may be deliberately obscuring things in order to determine whether you can find and understand the real problem.
Once you understand the question, try an example. This example may lead to insights about how to solve the problem or bring to light any remaining misunderstandings that you have. Starting with an example also demonstrates a methodical, logical thought process. Examples are especially useful if you don’t see the solution right away.
Make sure you understand the problem before you start solving it, and then start with an example to solidify your understanding.
Focus on the algorithm you will use to solve the problem. Often, this will take a long time and require additional examples. This is to be expected. Interactivity is important during this process. If you stand quietly staring at the whiteboard, the interviewer has no way of knowing whether you’re making productive headway or are simply clueless. Talk to your interviewer and tell him or her what you are doing. For example, you might say something like, “I’m wondering whether I can store the values in an array and then sort them, but I don’t think that will work because I can’t quickly look up elements in an array by value.” This demonstrates your skill, which is the point of the interview, and may also lead to hints from the interviewer, who might respond, “You’re very close to the solution. Do you really need to look up elements by value, or could you …”
It may take a long time to solve the problem, and you may be tempted to begin coding before you figure out an exact solution. Resist this temptation. Consider who you would rather work with: someone who thinks about a problem for a long time and then codes it correctly the first time or someone who hastily jumps into a problem, makes several errors while coding, and doesn’t have any idea where he or she is going. Not a difficult decision, is it?
After you’ve figured out your algorithm and how you will implement it, explain your solution to the interviewer. This gives him or her an opportunity to evaluate your solution before you begin coding. Your interviewer may say, “Sounds great, go ahead and code it,” or something like, “That’s not quite right because you can’t look up elements in a hash table that way.” In either case, you gain valuable information.
While you code, it’s important to explain what you’re doing. For example, you might say, “Here, I’m initializing the array to all zeroes.” This narrative enables the interviewer to follow your code more easily.
Explain what you are doing to your interviewer before and while coding the solution. Keep talking!
Ask questions when necessary. You generally won’t be penalized for asking factual questions that you might otherwise look up in a reference. You obviously can’t ask a question like, “How do I solve this problem?” but it is acceptable to ask a question like, “I can’t remember - what format string do I use to print out a localized date?” While it’s better to know these things, it’s okay to ask this sort of question.
After you’ve written the code for a problem, immediately verify that the code is correct by tracing through it with an example. This step demonstrates very clearly that your code works in at least one case. It also illustrates a logical thought process and your desire to check your work and search for bugs. The example may also help you flush out minor bugs in your solution.
Make sure you check your code for all error and special cases, especially boundary conditions. Many error and special cases are overlooked by programmers; forgetting these cases in an interview indicates you may forget them on the job. For example, if you allocate memory dynamically, make sure you check that the allocation did not fail. (If time does not allow for extensive checking, at the very least explain that you should check for such failures.) Covering error and special cases will impress your interviewer and help you correctly solve the problem.
Try an example, and check all error and special cases.
Once you try an example and feel comfortable that your code is correct, the interviewer may ask you questions about what you wrote. Commonly, these questions focus on running time, alternative implementations, and complexity. If your interviewer does not ask you these questions, you should volunteer the information to show that you are cognizant of these issues. For example, you could say, “This implementation has linear running time, which is the best possible because I have to check all the input values. The dynamic memory allocation will slow it down a little, as will the overhead of using recursion.”
Getting stuck on a problem is expected and an important part of the interviewing process. Interviewers want to see how you respond when you don’t recognize the answer to a question immediately. Giving up or getting frustrated is the worst thing to do if this happens to you. Instead, show interest in the problem and keep trying to solve it:
Go back to an example. Try performing the task and analyzing what you are doing. Try extending from your specific example to the general case. You may have to use very detailed examples. This is okay, because it shows the interviewer your persistence in finding the correct solution.
When all else fails, return to a specific example. Try to move from the specific example to the general case and from there to the solution.
Try a different data structure. Perhaps a linked list, an array, a hash table, or a binary search tree will help. If you’re given an unusual data structure, look for similarities between it and more-familiar data structures. Using the right data structure often makes a problem much easier.
Consider the less-commonly used or more-advanced aspects of a language. Sometimes the key to a problem involves one of these features.
Sometimes a different data structure or advanced language feature is key to the solution.
Even when you don’t feel stuck, you may be having problems. You may be missing an elegant or obvious way to implement something and writing too much code. Almost all interview coding questions have short answers. You rarely need to write more than 15 lines of code and almost never more than 30. If you start writing a lot of code, you may be heading in the wrong direction.