I've become frustrated at the time it takes me to solve some coding problems while practicing for the coding interview. I've spent as much as 2 hours on a single problem.
A typical coding interview question should take approximately 40 minutes to complete from initial explanation to final result and follow-up questions. Interviews are 45 minutes, and the first 3-5 minutes are for getting the interviewer familiar with the interviewee.
Instead of drawing out the time, I've come up with a plan to keep a question at 40 minutes. This will cause me to get used to the time required, and make me focus on getting a near-optimal solution out of my head quickly. With practice, this should get easier. I hope. Keeping it to 40 minutes will also allow me to get more done per day.
Coding interview solutions should be less than 50 lines of code. Many I've done end up at about 20-30 lines of Python. They are meant to be challenging, but not a 200-line solution. If you're doing coding challenges online, be aware that you might be doing a problem with a long solution that would not be a candidate for an interview problem.
Coding Problem Process
- Read the problem. Then re-read the problem. Look for details. What is provided? "Ah, I only get access to a node, not the head node of the list. Good to know." This will keep you from wasting time.
- Come up with an idea for a first solution. Brute force is OK. Just get something workable out of your head.
- Come up with test cases.
- Refine your solution. Can you go from O(n2) time to O(n log n) or O(n)? Is there a way you can use O(1) additional space instead of O(n)? Download this cheat sheet from Cracking the Coding Interview. BUD is the most important part.
- Use hints in the book when you get stuck or are having a hard time refining.
- Come up with a second solution that is better, in time/space from the first solution.
- Refine the second solution where you can. Do not write code yet. This would have been your solution if you had gotten the go-ahead from your interviewer to start coding.
- Read the answer description from the book. Do not read the code. This may open your eyes to something that wasn't clear in the problem statement.
- Code your answer on the board, or on paper if you don't have a board. Your code could be the answer you read from the book (without looking at their code), or your solution if yours was the same or better.
- Test it manually with your test cases. You will likely find a bug or two. I find bugs about 75% of the time.
- Fix bugs carefully.
- When satisfied, read the answer code from the book. Optimize your code based on what you see in their answer. Try a couple of test cases to make sure you didn't break it. Keep in mind the answers in the books have been corrected, refined, tested, and optimized over the years. Don't expect your code to be as polished.
- Optional: take a picture of your code on the board so you have a record of your solution before you erase it.
- Optional: copy your code and test cases to a computer. Run it to make sure it works as expected. This is helpful with recursive code and when you're new to the programming language you're using. It takes additional time to do this, beyond the 40-minute window, but it can be helpful.