Skip to main content

Command Palette

Search for a command to run...

Revisiting old problems

Updated
3 min read

In my experience, even in the most seemingly trivial of problems, when you stop to explain them and put them into words anyone can understand, if you are creative enough and aware enough of what you're doing, your brain will naturally come across all sorts of things of which can be talked about, unexpectedly, at length.

Just yesterday, I was working on a simple interview-style question to stay in shape with what I've been practicing over the past few months, feeling I should step up my knowledge of computer science and data structures and algorithms to make up for gaps in my skills. Anyone familiar with these kinds of questions, or perhaps with something like leetcode, has probably seen the "two sum" problem.

In the past, I definitely would have only imagined what I now know of as a brute-force or naive solution, with awful time complexity (maybe I'll write a post on that concept later) written it out, solved the problem, and walked away feeling like I didn't really actually learn anything, and wonder why I would even be doing these types of isolated and contrived problems.

Since then, I've gained a deeper understanding of the patterns behind these types of problems, and my brain has become at least somewhat familiar with recognizing them and being aware of when a solution can be optimized and when those patterns and coinciding coding techniques can be employed.

The problem was simple, and I had solved it three times before with three different solutions, and at one point thought through the pros and cons of each, however, knowing what I know now about learning, I knew that if something was worth learning, it would be worth reviewing. I swallowed my pride and the childish feeling of "I already know how to do this, it's a waste of time" and sat down to put my money where my mouth was, so to speak.

In doing so, I found myself naturally making connections I didn't find myself making when I learned how to solve this problem initially. I was challenging myself to, even if somewhat messily due to the nature of stream-of-consciousness thinking, explain my thought process in the moment and talk about the problems I could foresee. I was saying things like, "I chose to initialize these pointers here because, while it could work from other points, this is easier to think about and set conditions for", "Oh, I'm noticing my solution wouldn't work because of x, y, and z and I have to fix the way I wrote that", "While this works, at scale this could happen and it could be extremely costly..." and only briefly covered what the brute-force solution would be in general.

Throughout the whole process I demonstrated what my brain is doing in the background and became more conscious of it. I've found that over time, this is what really improves your skills. It's important to trust your brain. Give your brain good input. If you're doing that, you don't have to worry. Eventually it will all make sense, even if in the moment it doesn't feel like it.

Also, in the words of a buddy of mine who is also very much my senior in where we are in the stages of our careers, when we were discussing these kinds of problems and realizing that changing the data structure completely changed how we saw the problem: "Was it a hash map? It's always a hash map."