Preparing for Coding Interviews (A journey) - The Problem Solving Process
About this series
This series of posts documents the learnings, challenges i encountered and the decisions i made on my journey to hone the (algorithmic) tools of my trade. It's partly a tool for me to arrange my thoughts on this, partly a resource for me to revisit every now and then, and partly to serve as a guide for anyone who might find it useful.
Check out the meta post for a list of all related posts. For any Hiring Managers/TA Partners seeing this, drop me an email if you like what you see!
The Typical Process
- Create a notes document to accompany the question
- Select a language to solve the problem in, and write down the function prototype of the expected solution (to determine expected input and output formats)
- Write tests/asserts which call the function to verify if the solution works (AKA Test driven development)
- Think of some on your own test cases before copying over the provided ones, and then think of some more after copying
- Use this as an opportunity to clarify details about the problem from the interviewer
- In the notes document, list down assumptions, approach ideas and observations
- This helps condense thoughts into atomic, verifiable claims
- For every potential solution, write out it’s ‘approach’ pseudocode, even if it doesn’t meet some of the question’s limitations (like space or time complexity)
- This helps develop ideas, and lets you fail fast, along with potentially getting helpful insights from the interviewer
While Practicing
- All of steps from The Typical Process
- If a solution in a language feels like it can be optimized (either performance or readability), then attempt the same problem in a different language to inform the language selection process for future problems
- If a different (not necessarily better) solution is found after you’ve submitted your solution, analyse and write it down as an approach too
