How To Step Through a Coding Interview

Before whiteboarding a solution

• Clarify the problem. Most questions will have some degree of ambiguity, so make sure you actually understand the question before attempting to solve it. The easiest way to clarify the problem is to restate the problem in your own words and to provide a few simple test cases.
• Ask for additional context. Will it need to run in an embedded, memory-constrained environment? If so, that will mean your solution should be extra cautious with its memory usage (preferring an iterative over a recursive solution, for example). Will it need to run in a single thread or will it be running in an environment where you will have multiple threads, processes or machines at your disposal? If it is the latter, that is a good sign that a Divide and Conquer solution is usually a better alternative (quicksort usually outperforms mergesort in a single thread, but mergesort quickly outperforms quicksort as thread count is increased).

While solving the problem

• Think out loud! The interviewer doesn't know what is going on in your mind, so it is important to think out loud so that they know you haven't just given up. When I am interviewing at a company, I tell the interviewer that I will being thinking aloud, and apologize in advance in the event that I say anything dumb while doing so. I tend to talk pretty much non-stop(besides when the interviewer is talking) until I actually begin implementing the solution. While non-stop talking isn't necessary, if you are not talking or scribbling on the whiteboard for extended periods of time(on the order of magnitude of 30 seconds or so), the interviewer may think you are simply stuck.
• Take advice. In the event you have gotten stuck, or you seem to be heading in the wrong direction(another important reason to think out loud) interviewers will typically help guide you in the right direction. Make sure not to come across as argumentative or dismissive of their advice, since that could be a potential warning sign to the interviewer that you may be difficult to work with.
• "Diff" your solution. Let the interviewer know of any places that would differ between the solution you are implementing for the sake of the interview and how you would implement it in a production setting. You will have limited time and whiteboard real estate, so you will probably need to make changes(shorter variable names, less extensibility, etc.) to accommodate those constraints, but just be sure you let the interviewer know why you are doing so.
• Test as you go. Quickly go through some of the test cases that you wrote down earlier, paying close attention to terminating conditions and potential off-by-one errors.

After implementing your solution

• Walk through the test cases one final time.
• Talk about how your solution performs. What are the runtimes and memory usage of your solution(in Big-O)? Can you do better? Is there any way to break it(integer overflows, buffer overflows or null pointer exceptions are usually good candidates here)?

Most interviewers will allot an extra 10-15 minutes for you to ask questions at the end of the interview. This allows the interviewer to gauge your interest in the company and the role, as well as for you to find out whether the company is a good fit for you:

• Not taking advantage of this section of the interview will show disinterest on your part, so always ask at least one question! I have actually given a candidate(who had a technically sound interview) the thumbs down in an interview because they failed to do this.
• My favorite question to ask the interviewer during this section is, "What do you like, as well as dislike, most about working for the company?", since this can help alert you to any red flags.
• Other great questions for this part of the interview revolve around the technology stack of the company. What were some factors that influenced the use of one piece of technology over its alternatives? Were there any interesting blog posts on the company site? If so, now would be a great time to chat about them. Just be sure that the questions you ask aren't easily available on the corporate page, since that will make it appear as if you didn't do your research.

Finally, thank the interviewer. They are taking time out of their day to interview you, so it is important to be grateful for that. Optionally, ask for their email address to send a follow-up email thanking them, as well as the recruiter.