On preparing for coding interviews

Q: How should I prepare for coding interviews of a certain standard sort ("algorithms and data structures interviews," "whiteboard interviews," "Leetcode interviews")?

A: Do your best to mimic the actual environment of your interview:

  1. If possible, drill in the same IDE that you'll use in the interview.
  2. Practice talking through the question (literally, out loud, at least sometimes).
  3. If you won't be able to execute the code you write, don't let yourself do this as you write the code in practice.
  4. But do go back and make sure you wrote code that actually works, whether or not you'll be allowed to run the code during the interview.
  5. Do at least some of your practice in clothes like the ones you'll be wearing.

Choose a few problems that (i) are a bit harder than will typically be asked and (ii) exercise a few essential skills (graph traversal, binary search, whatever). Do them repeatedly, as drills.

LeetCode is better as a question repository and discussion forum than as a platform for testing your answers. The platform will confront you with overflow / underflow cases and other edge cases that your interviewers will overlook, guide you through, or happily leave underspecified. It's good to know about (e.g.) overflow, but it's inefficient to spend so much practice time on it.

Definitely try to learn all the essentials, but not at the expense of becoming more fluent in areas you know pretty well. People sometimes spend 10 to 25 hours struggling with the tricker parts of dynamic programming or XOR hacks when they would be better off using that time to absolutely nail down basic graph search algorithms.

Practice the skill of plugging away at a problem when you're stuck, but treat it as one skill among many. So: don't spend too much time struggling when you're stuck. It's more important to learn all the basic question types.

Cracking the Coding Interview is an excellent question repository (and a bit underrated as an instruction / reference book). The Algorithm Design Manual is a pleasant and very different sort of reference, with plenty of "aha" moments. But beware of the trap of substituting passive reading for active preparation.

Email me if you have other questions.


More posts about programming


Home page