Introduction
Recognize the pattern. Recall the anchor. Reuse the idea.
When you study for coding tests, this happens a lot.
You read the problem, but you have no idea which algorithm to reach for.
Then you solve it, and this thought shows up.
"Oh — this was similar to something I solved before."
The truth is, most coding test problems aren't entirely new.
Far more often, they're a familiar structure wrapped in a different story.
How do you solve a new problem?
In this series, we approach a problem like this.
Problem
↓
Pattern
↓
Anchor Problem
↓
Core Idea
↓
Apply
Read the problem.
Find its structure.
Recall the problem that shows that structure most clearly.
Take only the core idea from that problem and apply it.
What matters isn't memorizing problems.
It's recognizing structure.
What is an Anchor Problem?
In this series,
every structure has one problem that shows it most vividly. That problem is what we call its Anchor Problem.
Many people think an Anchor Problem is "the easiest problem."
But it's a little different.
An Anchor Problem isn't the easiest problem — it's the one that shows the core structure in its purest form.
For example, the structure behind Dynamic Programming has Fibonacci as its anchor.
Not because you should memorize Fibonacci.
Because the heart of DP —
State
Recurrence
Memoization
shows up here in its simplest form.
There's a second condition, quieter than the first.
You must already own it.
An anchor you have to look up is not an anchor — recall is the entire point.
Fibonacci works because you knew it before you knew what an algorithm was.
And here is what an anchor is not: an answer.
Fibonacci does not hand you the recurrence for the next DP problem you meet. You still have to derive that one yourself.
What it hands you is the shape of the hole you need to fill.
Find the state.
Find the transition.
An anchor never gives you the answer. It gives you the shape of the hole.
And that is enough.
Not every algorithm has one
Here is the part most people skip.
"Dynamic Programming" is the name of a structure. Overlapping subproblems. Optimal substructure.
It describes what the problem has.
That is why one anchor covers it whole.
Now say "Two Pointers" out loud.
What does that name describe?
Two indices. That's your code. It says nothing about the problem.
"Two Pointers" is not a structure. It's a tool.
Most people call it a pattern. That is exactly the trap.
In this series, a pattern is a structure — what the problem is. Never a tool — what your code looks like.
That distinction is the whole reason this series is called Think in Patterns, and not Think in Tools.
A tool can serve many structures. So there is no single Anchor Problem waiting under it. Hunt for one and it slips through your fingers.
And most concept names in this field are tool names.
Dynamic Programming is the exception, not the template.
So before you hunt for an anchor, ask one question.
Is this name a structure, or a tool?
If it's a tool, split it first.
Think in Patterns
In this series, rather than explaining algorithms,
we focus on when you should reach for one.
Every post follows the same flow we just saw.
You see the problem → find the structure → recall the Anchor Problem → take only the core idea → apply it to the problem in front of you.
Keep repeating this thought process, and
even when you meet a new problem, the structure starts to show itself first.
Going forward, each post takes a single structure and the one anchor that reveals it.
One tool may split into several such posts. That is the point, not the exception.
And we begin where the map is easy.
Dynamic Programming is that rare name already a structure — so its anchor, Fibonacci, falls out clean.
Then we take our own advice on a name that isn't. Two Pointers. A tool, not a structure.
Split it, and the anchors are waiting underneath.
Let's begin.