I Thought I Could Never Crack Google — Until I Realised This

Yesterday, I was solving a coding problem.
I had written a working approach, but instead of slowing down and understanding it properly, my mind immediately went to optimisation.
- Can I remove this loop?
- Can I reduce the time complexity?
- Can I solve it using two pointers?
I kept changing the code, but I was not actually getting closer to the solution.
Then I realised something:
I was trying to optimise the code before I had properly understood the pattern behind the problem.
And honestly, I do this more often than I would like to admit.
When we practise DSA, we often put too much pressure on ourselves to find the optimal solution immediately.
We see a problem and start thinking:
- “What is the
O(n)solution?” - “What pattern am I supposed to use?”
- “Why am I not able to solve this quickly?”
But sometimes, the problem is not that we do not know enough.
The problem is that we are trying to move too fast.
Before optimising, we need to understand what the problem is actually asking.
- Are we looking for a continuous part of an array?
- Are we comparing values from both ends?
- Are we repeating the same smaller decision?
- Are we searching for something inside a sorted space?
These small clues often point toward patterns such as sliding window, two pointers, dynamic programming, or binary search.
Once you start recognising those signals, LeetCode problems feel less random.
You stop treating every problem like something completely new.
You begin connecting it to problems you have already solved.
That is what I explored in my latest article:
LeetCode Gets Easier Once You Recognize These 15 Coding Patterns
The article covers common patterns such as two pointers, sliding window, binary search, prefix sums, backtracking, monotonic stacks, graph traversal, and dynamic programming.
But more importantly, it explains how to recognise when a pattern might be useful.
Read the complete article here: LeetCode Gets Easier Once You Recognize These 15 Coding Patterns

The biggest reminder I took from yesterday was simple:
Do not optimise something you do not fully understand yet.
- First, write the basic approach.
- Understand why it works.
- Find what is making it slow.
- Then optimise it.
A brute-force solution that you genuinely understand is far more useful than an optimal solution you only memorised.
You can also read more articles on DSA here
Until next time,
Neha