The toy problem was trapping rain water, and initially, I was not prepared to work through a height map, nor implement a matrix. I took the majority of the time allotted for both of us to interview while working through my toy problem, and despite that, my senior, Ivan Bailey, took the time to offer advice I won't forget.
During the diagramming process, I suggested the usefulness of a matrix to myself early on, but skipped over the idea due to a lack of familiarity. I didn't want to introduce any extra opportunities to trip myself over. As I drifted further and further away from that idea, Ivan interjected, and let me know that it may be helpful to explore that idea further. This interruption was unfortunate, from my perspective, as I had overlooked a great approach to the problem (for the wrong reason). However, if it weren't for Ivan, it's unlikely I would've found the solution in the allotted time block. More on your interviewer (likely) not being big and bad later. Ivan took even more time give me some awesome feedback, and here's what I recollect:
Use more visuals
Diagramming isn't the end-all-be-all of visual planning.
When you have a complex set of data, such as a height map, consider transforming it into another shape or format. It doesn't have to be a data structure; it can be any shape (drawn or typed) that helps you approach and understand the problem.
Example: The toy problem for the pair exercise, trapping rain water, works with 2-dimensions - the x and y-axis. You know what's great for visualizing 2-dimensional data? Graphs. Coincidentally, you know what's awesome for converting graph data to code-accessible data? A matrix (n-queens says hello).
Once you understand the problem, take it one step further and make some notes. Express that new data model or shape as pseudocode, or if that's not feasible, include it in your diagram. If you decided to include it in your diagram, use that model as a reference when you're pseudocoding.
Step through your pseudocode
Sometimes, just writing pseudocode isn't enough.
Once you've achieved understanding of the problem and have some pseudocode through the page, walk through it. Not just mentally - I mean meticulously visit each line and type the expected output as a comment. Then, pass that expected output into the next line, like a memo pattern. Remember our acting as the interpreter exercises? I never knew just how helpful that would be - it not only shows that I'm thinking about the problem in a structured way, but it coerces me to self-validate my code. Don't be afraid to interact and play with your diagram through this process, either.
Don't be afraid of your interviewer
Think of them as an ally, not a gatekeeper.
You want to be sure that you have a firm understanding of the problem before trying to solve it. If you don't understand the inputs, ask for clarification - if you don't understand the format of the output, ask about that too. You're also showing that you care about solving the problem, and sometimes you never know unless you try.
Example: The earlier a ship starts an uncorrected drift, the further it'll be from its destination once it makes landfall (if ever).
I don't think the point of this advice was for you to bombard your interviewer with low level questions at every turn. Rather, it was to encourage asking for help or clarification if it's needed. If you're truly stuck, and the problem can't be made more granular, this is a positive thing. It might even become a win if you self-correct your approach. It shows that you'll ask for help when needed, and that you're capable of rewiring/rethinking your process.
Top comments (0)