I'm preparing for coding assessments and interviews, but my biggest challenge is figuring out an approach quickly. I can usually understand what a problem is asking, yet I struggle to choose a data structure or algorithm, break the task into smaller steps, or even decide where to begin. When I read a solution afterward, it often seems obvious, but I'm not sure how I was supposed to recognize that approach independently.
Does this become more intuitive with deliberate practice? Should I focus on learning common patterns such as hash maps, two pointers, sliding windows, and BFS/DFS, or is it better to solve many varied problems and let the patterns emerge naturally? Also, how long should I work on a problem before using a hint or reading the solution? I want to develop persistence without spending hours stuck or merely memorizing answers.
4 Answers
A good progression is to solve an easy version first, identify the core operation, and only then optimize it. For example, start with a straightforward nested-loop solution before asking whether a hash map, sorting, two pointers, or a sliding window can reduce the work. Over time, you’ll recognize recurring structures, but the goal is to understand why a pattern fits—not just memorize its name.
Pattern recognition is useful, but it shouldn’t replace actually thinking through problems. Before looking anything up, spend around 20–30 minutes clarifying the input, output, constraints, and a simple brute-force approach. Then ask what makes that approach too slow and use the constraints to guide your search for a better data structure or algorithm. If you’re still making no progress, take a small hint rather than immediately reading the complete solution.
For interview preparation, these exercises are often part of the hiring process whether or not they resemble day-to-day development. Treat them as a specific skill to train rather than as a complete measure of programming ability. Keep a short review log for each problem: the key observation, the pattern used, why your first idea failed, and what clues in the constraints pointed toward the final approach. Revisit the problem later without looking at your notes.
Yes, it gets more intuitive, but randomly grinding hundreds of problems probably isn’t the most efficient way to improve. Practice by topic or pattern instead: learn the basic idea, solve a few representative problems, and then try to explain when that technique would and wouldn’t apply. After reading a solution, close it and implement the approach from memory. If you can’t do that, you understood the explanation but haven’t learned the method yet.
That makes sense. I can follow a solution while it’s in front of me, but reproducing it afterward is where I usually get stuck.
The review log sounds helpful. I think I’ve mostly been collecting solutions without recording the clue that should have led me there.