A Strategy For The Dreaded Interview Coding Question

If you’re a software developer and you’re thinking about changing jobs, you’re probably at least a bit anxious (if not downright freaked out) about the prospect of facing a whiteboard armed with only a trusty dry erase marker and your wits while an interviewer fires a coding question at you. That’s not shocking because software development interviews are weird: the skills necessary to answer the technical and behavioral/situational questions that are asked don’t necessarily map 1:1 with the skills to be a good developer. We’re used to developing with access to tools like IDE’s and StackOverflow, without unnatural time constraints and the pressure of landing a job in the balance. I’ve interviewed literally hundreds of candidates in my roles as a manager both at Microsoft and Amazon, and I’ve seen hundreds bomb coding questions. That doesn’t shock me for the reasons previously mentioned, but what does shock me is the number of bright folks who fail on the questions simply because they don’t approach them with a solid strategy.

The anti-patterns are crystal clear and they almost always lead to a wipe, for example: diving straight in on code, assuming that language/syntax doesn’t matter, or failing to consider edge cases before implementation. To avoid these pitfalls, I recommend that every interviewing developer should practice the following strategy before going into interviews and put it into practice (without fail, no matter how simple the question seems) during the process.

Restate the problem and ask clarifying questions.

Repeating the problem in your own words and asking some follow up questions only takes a second, and it’s a good way to quickly tease out any bad assumptions that have been made. It also gives the interviewer confidence that you’re used to attacking real world coding tasks the right way: being sure that you’ve correctly interpreted requirements and thinking through questions that impact various potential approaches. Ask how important optimization is instead of just assuming that implementing the naive solution is bad. Ask what you should optimize for, for example quickest execution speed or smallest memory footprint.

Walk through a basic example in detail and consider a few edge cases.

Take the time to think through at least one straightforward case, as well as a few relevant edge cases. Talk through your thought process as you’re going through them, utilizing the whiteboard as much as you can. Consider null or zero length inputs. Consider very large inputs, and be prepared to answer questions about whether your implementation would fit in memory on specific hardware given specific inputs. The process of walking through these cases should get you very close to pseudocode.

Write up pseudocode.

Be sure that you’re not writing in a real programming language. Pick a spot on the board where you don’t have to erase your pseudocode when you start to write real code, and will be able to read it. Lots of interview questions require thinking about recursive versus iterative implementations, so it doesn’t hurt to always consider whether that question is in play if it is relevant to the problem. Don’t abandon the pseudocode to dive into real code until you have completed the problem. Be sure to continue the dialogue with the interviewer while you’re thinking, and show that you can listen and course correct given hints.

Pick a language, and ask how important syntax is.

Always assume that for actual implementation, the interviewer cares about the details. I’m generally not a stickler for small syntactical minutia, but I get annoyed I get when an interviewer just assumes that it’s alright for the final implementation to be in pseudocode or some hodge-podge of languages. If you decide to code in a language other than the one that you indicated that you’re the most comfortable with on your resume, be sure to explain why. Asking how much the interviewer cares about syntax can help you decide whether to take an extra pass at the end of the loop being sure that everything is spot on; if the interviewer doesn’t care they may see it as a waste of precious time.

Code it!

You’ve done all the hard work, getting from pseudocode to your language of choice should be fairly trivial.

It’s important to remember that a typical interview in a loop will run 45-60 minutes, and most interviewers are going to want to touch on more than a single coding question. The expectation is most likely that you can complete the question in 20-30 minutes, so be sure that you’re not spending a ton of time on each step. A lot of interviewers will tell you that they’re not necessarily looking for you to get to a fully working implementation, but don’t believe them. If you don’t get code up on the board or stall out they will definitely ding you. Don’t spend more than a few minutes restating the question and walking through edge cases. The bulk of your time should be spent in an even split between pseudocode and code.

The beauty of following this strategy is that you will come across as organized and informed even if you don’t understand the question. It also provides an opportunity to work with the interviewer through follow up questions while running through examples and pseudocoding. Remember, the interviewer knows the answer to the question and they probably want to get you hints as you move in the right direction, so engaging them and using them as a resource is critical. Hope that these ideas help, now go nail that interview loop!

  1. cgp

    The basic example should translate pretty easy into something testable (a unit test if you are into that sort of thing)

  2. Rob Williams

    I had an interviewing manager once give me access to a dev environment on a laptop hooked up to a projector. It was the best interview I’ve ever had. They were fully aware that developers have access to an IDE and Google during their day to day work, and that utilizing these tools is an important part of programming is itself.

    Now that I’m a hiring manager, I do all my interviews this same way.

  3. berto

    awesome tips. couldn’t come at a better time!

  4. Derek Hunter

    What sort of coding problems are we talking about here? We code almost exclusively in C and I am struggling to think of a worthwhile example I could give to someone and expect to see a coded solution in 20 minutes.

    Asking candidates about pointers and malloc() usually weeds out 90% of them!

    • Tyson Trautmann

      Search for interview coding questions at Microsoft, Google, or Amazon or check out books tailored at interview prep and you’ll find a lot of examples. Data structure navigation/manipulation (tree/graph/linked list traversal, interaction with matrices, etc) is a pretty typical example. I also never ask a candidate to answer a question in a particular language, my team does mostly Java development right now but I’m willing to hire any bright developers and not just experts in a particular language.

    • Good point. I hadn’t thohugt about it quite that way. 🙂

  5. Randy Lee

    I wouldn’t work for a company that insisted upon an interview coding challenge. Using such a test betrays zero insight into the qualities of mind that separate rote coders from visionaries who can transcend mere code to produce a great application.

  6. Bruce Lehmann

    We don’t do ask for anything fancy: just code a bubble sort (any language) and find some very obvious logical or syntax errors in a code sample. That gets us to people who actually know how to write code (95%).

  7. Paul

    From your explanation I am guessing that you are looking for the ability of a candidate to be able to understand and explore a problem, articulate their understanding of the problem/solution in a none code based format and then be able to accurately translate that into code. That sounds reasonable but there are a lot of places that would prefer a candidate to not explore/expand too much to start with, go straight to articulating their ideas in code on a very narrowly focused area of the problem and then build-up/evolve the solution as they go on. Neither of which would be my preference for getting an understanding of whether a person is a good fit. So with there being at least three different and somewhat mutually exclusive things that could be looked for using a coding test, I think it is only fair to let the candidate know what is actually being looked for. You could argue that the candidate should ask, but it is also valid to interpret not being told as a lack of ability on the employers part to provide the right level of direction needed to fulfill tasks to their expectation.

    Finally to anybody that has been rejected on the basis of a coding test do not be overly concerned about it, have a reflect on it and see if there is anything that you would do better next time or that you could do with learning about. In reality this interview malarkey is all subjective. It sort of has to be. If you look at the scientific method and what it takes for a theory to be accepted (and even then their is no claim of proof) or if you are more of a rationalist what it takes to actually prove a theorem, any job interview no matter how skillfully conducted, or whatever is claimed about the tests they make you go through, can be anything other than subjective. Not that I think that is a bad thing, it is the reality of the situation and it just means that you were not right for that situation at that point in time.

    • Tyson Trautmann

      Agreed on all points.

      In interview loops at Amazon we’re always assigning a mix of competencies to each interviewer (the hiring managers assign them, so I’m one of the folks doling them out). For example one interviewer on a loop may be told to drill into a candidate’s customer obsession, coding ability, and knowledge of data structures. That person will probably ask a situational question about customer interaction and probe on the details to try to get a feeling for the candidate’s passion for the customer. They may follow that with a coding question that gives the candidate their choice of data structures to solve a particular problem. They will certainly be looking for thought process and problem solving ability as well as whether the candidate can take hints and course correct. Getting a working solution is just one small part of the puzzle.

      Interview loops are definitely subjective. Steve Yegge does a great job describing this in his post on interview “anti-loops”. I believe that even the best candidate in the world will still max out at a 70-80% chance of passing any given loop. That’s just the nature of the beast, the loop (and coding questions) still fill a very necessary function IMO.

Trackbacks for this post

  1. Bookmarks for July 25th | Chris’s Digital Detritus

Leave a Reply