Why pattern matching is not ideal (and how to actually think through problems).

Many people, especially those who start from Leetcode / Neetcode, believe the skill being tested in interviews is "recognizing patterns". Often times, this is advertised as a "shortcut" or a "trick" such that you don't treat each problem as a brand new one. You see a new problem, you attempt to search from your knowledge base, which of the patterns works (e.g. sliding window, two pointers!), then you apply that template, sometimes even memorizing the structure of it. In my opinion, this is a very rigid way to go about problem solving, and it also causes you to hit your skill ceiling very quickly.

The whole "N patterns solve 80% most of LeetCode" genre is built to train exactly this bad habit. Because Leetcode has relatively low variety (as in many problems are essentially re-modeled after each other), it could also create the false illusion that this method works. It only works until your interviewer comes up with something creative or asks you a followup that you haven't seen before.

These posts always end on the same line: you are not bad at problem solving, you are just bad at identifying patterns. In my opinion, these people got it completely backwards.

Let me offer a different perspective. The actual skill being tested in interviews is "problem solving". Pattern recognition is just one tool you reach for along the way, often only once you've solved the problem, you apply some "pattern". In general, I also dislike the term "pattern" as it implies "pattern matching" which suggests that all you have to do is create a bijection between "problems" and "patterns" to be able to solve the problem. This is also what causes people to resort to flashcards & spaced repetition, essentially attempting to match problem X -> pattern Y.

To start, I'll redefine "patterns" as "techniques". Techniques could be algorithms such as dfs or dijkstras, which you're not supposed to rediscover during interviews. No one expects you to, but it's an implicit agreement with you and the interviewer that you did your due diligence to learn these basic techniques. If you lack the correct technique, it would be extremely difficult to solve a problem. So yes, you should absolutely learn and understand these fundamental algorithms (techniques, patterns, however you want to call it) deeply.

Something I observed that's very common among people is "forcing" a pattern onto a problem. Let's take this problem for example.

Takahashi is playing a game.

The game consists of $N$ stages numbered $1, 2, \dots, N$. Initially, only stage 1 can be played.

For each stage $i$ ($1 \le i \le N-1$) that can be played, you can perform one of the following two actions at stage $i$:

• Spend $A_i$ seconds to clear stage $i$. This allows you to play stage $i+1$.
• Spend $B_i$ seconds to clear stage $i$. This allows you to play stage $X_i$.

Ignoring the times other than the time spent to clear the stages, how many seconds will it take at the minimum to be able to play stage $N$?

Constraints

• $2 \le N \le 2 \times 10^5$
• $1 \le A_i, B_i \le 10^9$
• $1 \le X_i \le N$
• All input values are integers.

Before you read further, spend 30 seconds and tell me what technique you should use to solve this problem.

If "pattern matching" is the first thing you go for, it's much easier to make wrong assumptions or judgements about a problem. For example, thinking that the keyword "minimum" must mean this is DP. Then after trying DP for 20 minutes and not working, then try greedy because thinking that "not DP implies greedy".

This blog by -is-this-fft- describes this much more in-depth, and I highly recommend a read.

Instead one should first reason through the problem and find useful observations. In this case, maybe notice that operation 2 could actually send you back stages (which makes DP hard as dependency doesn't work). A keener eye might notice that you could remodel both operations as weighted directed edges.

With that observation, the solution is trivial. It's neither DP or greedy, and it's simply the shortest path on a weighted graph, which can then be solved with the dijkstras technique.

With all that said, I suppose the takeaway is that, how could you pattern match without even reasoning through the problem? On harder problems, maybe the solution requires a combination of techniques, or it requires a chain of thought before you can even apply a pattern. Treating "pattern matching" as this magical thing to solve every problem is exactly what causes so many people to struggle. To me, pattern matching is training "recognition". You're building your knowledge base, think of it as a hashmap to lookup answers from. Whitebox teaches synthesis, so you build the solution from the ground up.

Colin Galen has some very good videos about how to utilize your intuition & scientific way to grind problems and improve. There's a good amount of overlap between our philosophy and his.