I'm trying to improve at coding challenges and technical assessments, but my main difficulty is figuring out the solution approach quickly. I can usually understand what a problem is asking, yet I often get stuck deciding which data structure or algorithm to use, how to break the problem into smaller pieces, or even what the first step should be. When I read the explanation afterward, it usually makes sense, but I'm not sure how I was supposed to recognize that approach independently.
For people who struggled with this early on, did problem-solving eventually become more intuitive? What helped you start identifying useful approaches faster? Should I focus on learning common patterns such as hash maps, two pointers, sliding windows, and BFS/DFS, or is solving lots of problems the main way those patterns become familiar?
Also, how long should I work on a problem before checking a hint or solution? I want to develop persistence without spending hours stuck or simply memorizing answers. My main goal is to prepare for software engineering interviews, where these assessments are difficult to avoid.
4 Answers
Treat each problem as practice in asking the right questions, not just finding the final code. Start with a brute-force approach, write down the constraints, and look for repeated work or a useful invariant. Then ask what information needs to be remembered as you scan the input. Those questions often point toward a hash map, two pointers, a sliding window, or another standard technique. Keeping a short journal of the problem pattern and the clue that revealed it can help recognition develop much faster.
A reasonable time limit is around 20–30 minutes of genuine effort for a medium problem, sometimes longer if you’re making progress. If you’re completely stuck, take a small hint rather than immediately reading the full solution. Afterward, redo the problem from scratch later that day or a few days afterward. The important part is not just understanding the answer—it’s being able to explain why that approach works and implement it without copying.
These challenges are often used in hiring, so preparing for them is understandable, even though they don’t represent most day-to-day software development. Pattern knowledge helps with assessments, but don’t reduce practice to memorizing templates. Try to understand the tradeoffs, prove to yourself why the algorithm works, and spend some time solving problems without immediately searching for a known pattern. That builds the broader problem-solving skill as well as interview speed.
Yes, it becomes more intuitive, but random grinding isn’t the most efficient route. Learn a small set of common patterns, then practice recognizing when each one applies. After reading a solution, close it and implement the idea from memory. If you can’t, study the explanation again, then try to reproduce it without looking. That turns a solution from something that merely seems obvious into something you can actually use.
That makes sense. I can usually follow an explanation, but I need to get better at closing it and rebuilding the solution myself instead of assuming I understood it.