Coding Interview Preparation (My Path to SRM)

At first I was overwhelmed by the sheer amount of topics and learning opportunities. From free videos on YouTube with varying quality to paid courses offering a thoughtful curriculum. Out of the many structured and well-designed learning paths towards coding interviews I had to choose one or two. The secret was to follow one or maybe two of them and not waste time jumping back and forth between tens of different curricula. Sometimes it is better to trust that the author put some serious thought into compiling a suitable learning path.

Choosing a curriculum

I wasn’t in a hurry. So I chose to start with a quite thick book titled Cracking the Coding Interview (CTCI) by Gayle Laakmann McDowell. The book contains about 150 coding questions divided into different topics and difficulty levels. The programming language that is used in the solutions section is Java unless the use of a different language was particularly stated. Since I wanted to get better at Go I solved the coding questions using Go. Almost all question could be solved with Go. I’d argue that this often produced cleaner, easier to read, code. But that’s just me being opinionated. πŸ˜‰For what it’s worth, others have gone there before and published their solutions for Go. There is also a semi-official repository containing solutions for all sorts of languages.

I found it much easier to visualize a solution on a whiteboard than in a code editor.

Train as you fight!

Train as you fight we used to say in the army, meaning that the more realistic the training the higher the chances of success in a real situation. Trusting that simplified sayings hold true I ordered myself a whiteboard and board markers. The whiteboard became my center of learning. Every time I finished reading a chapter in CTCI I went to the coding questions for that chapter and solved them on the whiteboard. I set myself a timer for 40 minutes for each question, just like in a real interview. I talked out loud while solving the question as if there was an interviewer in the room. Sometimes it was hard to rephrase a problem or explain my approach in English. However, I think I figured it out over time and also improved my technical English skills along the way. More often than not I was stuck with a question. Since there was no real interviewer in the room I had to use the hints in the book to bootstrap myself out of the misery. CTCI has really nice hints for each question. The hints they start broad and get narrower with each further hint releasing more and more information about the problem. My goal was to use as few hints as possible. The author arranged the hints randomly on different pages. This means that looking up a hint did not lead to accidentally peeking at further hints for the same question. I liked how much thought went into that book! πŸ‘

In the beginning I was unable to finish even the easy and moderate questions in time. Don’t get me started on the hard ones… When I hit the time limit I noted down how far into the solution I made it (for example by taking a picture of the whiteboard). Then I continued solving the question. Later, when I finally gave up on the problem or thought I had a decent solution I compared that to the expected solution. Over time I made it further and further into the solutions, eventually finishing questions on time. πŸ™‹πŸŽ‰

It was very important for me to raise awareness of my progress to keep pushing and not get frustrated. By measuring time and how far I came with each question I was able to maintain the momentum over weeks.

I sometimes had to redo some exercises because my initial solution wasn’t good enough.

If you don’t have a whiteboard and prefer not to get once I advise to code on paper or in a plain text editor (no syntax highlighting, no auto-correction). Nowadays Google often offers coding on a Chromebook in an on-site interview. As far as I know candidates can choose if they prefer a whiteboard or a Chromebook. I heard stories were people prepared on a keyboard only to find out that there were no Chromebooks available at the site they interviewed. I’d say preparing on a keyboard only comes with a small risk while preparing on a whiteboard or on paper is usually a safe bet.

Testing

I did not have a learning buddy. Therefore I had to pay people to mock-interview me. If you happen to know someone who is also preparing for coding interviews I highly recommend pairing up and mock-interviewing each other about one a week. Experiencing an interview from the interviewer’s point of view is a great learning. It improves one’s own skills and helps to get better in providing useful signal. Having an interview once a week furthermore reduces the uncertainty of the interview situation in general. After a while one gets used to the circumstances and it becomes easier to focus on solving the interview question. Being interviewed is stressful enough in itself, there is no need to add extra adrenalin by experiencing this situation for the first time when it counts. Ideally it becomes routine and almost boring to be interviewed.

Resources

Curricula and quizzes:

Sources of problems, questions, and exercises:

  • Hacker Rank is full of interesting coding questions. Most of them have test cases. An automated grading system provides instant feedback which is tempting but misses the point of an interview where no or little feedback is given.
  • Project Euler features mostly math-related questions. They tend to get tougher over time.
  • The CareerCup forums host an ever-growing collection of coding interview questions. Here are a few for Google SRE. Geeks for Geeks never let me down when it comes to finding the, interesting problems to solve.

Technical deep dives and algorithms explained:



πŸ”¬ Experimental Feature: Subscribe here to receive new articles via email! πŸ”¬