Algorithm review template: turn “I solved it once” into “I own the method”
After each problem, record:
ARCHIVE / 21
All writing
Reusable methods, open questions, and notes grounded in real work.
Algorithm study roadmap: from intuition to a method library
The right roadmap is not just difficulty progression. It is capability progression.
Backtracking is constrained search, not random brute force
Backtracking becomes stable when three things are clear:
Before solving more problems, build complexity intuition first
Complexity intuition is the ability to look at an idea and quickly ask:
Binary search: the real challenge is monotonicity and boundary design
Binary search is not mainly about a loop template.
Graph problems become much easier once the model is explicit
Graph problems feel messy when the model is vague.
How I make a project actually move forward
Projects often stall not because people are idle, but because the work is not split clearly enough.
How I structure a small project so it does not become messy too quickly
Small projects often become chaotic not because they are large, but because they start without boundaries.
Many DP problems are really about choices
A large share of DP problems are structured around comparing choices under a constrained state.
Monotonic stack: why so many “next greater element” problems collapse into one pattern
Monotonic stacks are powerful when you need the first larger or smaller element to the left or right, without rescanning for every position.
Problem classification is pattern recognition, not label memorization
Useful classification is not about saying “this is a binary search problem”. It is about seeing the structural signal early enough to choose the right first direction.
Put AI into the workflow instead of leaving it at the tool-demo stage
The real value of AI starts when it becomes a stable part of the work loop.
Sliding window: when interval problems do not need full recomputation
Sliding window is valuable when a continuous interval can be maintained incrementally instead of recomputed from scratch.
Start DP from state definition, not from formulas
The safest starting point for DP is a plain sentence:
The real risk in algorithm study is not difficulty, but lack of feedback loops
Many people do not struggle because they are incapable. They struggle because every solved problem disappears from memory too quickly.
Tree problems depend more on recursion semantics than traversal names
Tree problems become clearer once you can say:
Two pointers: when to think in terms of narrowing from both ends
Two pointers are useful when moving one boundary can eliminate a large set of impossible combinations.
When architecture starts to matter
Architecture matters when:
When to move from memoization to a DP table
Memoization is often the easier bridge when you are still understanding the recursive structure.
Why dynamic programming so often feels like “I understand it when I read it, but I still cannot solve it”
DP often feels slippery because people memorize formulas before they understand state meaning and transition completeness.
Why linked list problems fall apart the moment pointer updates lose discipline
Linked list problems often fail because relationships are modified before the next safe reference is preserved.