Model prob
1. What is the state?
a. What is minimum information I need to describe where I currently am in the
problem?
2. What is the operation?
a. What action am I allowed to perform?
3. What information do I gain?
a. After performing one op, what do I learn?
4. What is the invariant?
a. What remains true no matter what happens?
5. What quantitiy am I minimizing/maximizing for?
a. What does success look like?
6. What is the underlying mathematical structure of this problem?
a. Is it recursive?
b. Can I think backwards?
c. Is there symmetry?
d. Is something monotonic?
e. Is there an ordering?
f. Can I process greedily?
g. Is there overlap?
h. Is something independent?
i. Is there a graph hiding in here?
j. Can I sort to exposure structure?
7.
Problem Solving Notes
Page 1 — The Meta Skill
"Every difficult problem is easy once you know how to look at it."
The biggest mistake beginners make is immediately thinking:
"What algorithm is this?"
Experts instead think
What kind of world am I in?
Before writing code, spend several minutes understanding the landscape.
Every problem has:
● a state
● operations
● information
● constraints
● structure
The algorithm is just a consequence.
Universal Checklist
Whenever you see a problem:
1. What is the state?
2. What operations exist?
3. What information do I gain?
4. What never changes?
5. What am I optimizing?
6. What mathematical structure exists?
7. What smaller version already solves this?
Don't code yet.
Think.
Page 2 — State
The state is
the minimum information necessary to completely describe where you
currently are.
Think of a chess game.
The state isn't
"White moved knight."
The state is
● piece locations
● whose turn
● castling rights
● en passant
Everything else is history.
Examples
Grid
State
(row, col)
Maze
(row, col)
Robot with direction
(row, col, direction)
DP
(index, remaining capacity)
Coin Change
(amount remaining)
Intervals
(left, right)
Graph
(current node)
Ask
"What information would another person need to continue solving from here?"
Everything else is unnecessary.
Good states are
Minimal
Complete
Reusable
Page 3 — Operations
Operations define
What moves am I allowed to make?
Without operations
there is no search.
Examples
Grid
Move
Up
Down
Left
Right
Tree
Go to child
Go to parent
DP
Take item
Skip item
Binary Search
Discard left half
Discard right half
Sorting
Swap
Insert
Partition
Every operation changes the state.
Think
State
Operation
New State
Many algorithms are simply exploring all operations efficiently.
Page 4 — Information
Every operation tells you something.
Sometimes the operation is valuable only because of the information it reveals.
Binary Search
Question
Is middle too large?
Information gained
Entire half eliminated.
Egg Dropping
Drop egg.
Information
Break
or
Not break
Huge difference.
Twenty Questions
Each question partitions possibilities.
Good questions maximize information.
Competitive programming often asks
"What is the most informative thing I can do next?"
When stuck
Ask
"What uncertainty am I trying to remove?"
Page 5 — Invariants
An invariant is
something that remains true no matter what operations occur.
Finding invariants solves many hard problems.
Examples
Parity
Even stays even.
Connected Components
DFS never leaves component.
Binary Search
Answer always inside interval.
Two Pointers
Window always satisfies condition.
Heap
Parent ≤ children.
Sorting
Prefix already sorted.
Union Find
Every node belongs to exactly one set.
When stuck
Ask
"What absolutely cannot change?"
Many Olympiad problems are hidden invariant problems.
Page 6 — Optimization
Every optimization problem asks
"What does success actually mean?"
Minimize
Time
Distance
Moves
Cost
Errors
Maximize
Profit
Area
Score
Probability
Optimization changes algorithms.
Same graph.
Different goal.
Shortest path
Dijkstra
Maximum flow
Ford-Fulkerson
Reachability
DFS
Always ask
"What exact quantity am I optimizing?"
Many wrong solutions optimize the wrong thing.
Page 7 — Mathematical Structure
The algorithm comes from recognizing structure.
Recursion
Smaller problem solves larger.
Examples
Merge Sort
DFS
DP
Monotonicity
If true here
then always true later.
Binary Search
Ordering
Can sorting expose something?
Intervals
Events
Meetings
Geometry
Symmetry
Mirror image?
Rotate?
Reverse?
Graph
Objects
Connections
Immediately think
BFS
DFS
Shortest Path
Union Find
Greedy
Can local optimum guarantee global optimum?
Independence
Can pieces be solved separately?
Overlap
Repeated work?
DP.
Page 8 — Reverse Thinking
Forward thinking is often hard.
Backward thinking simplifies problems.
Examples
Can reach destination?
Instead ask
What states could reach me?
Topological Sort
Think about prerequisites.
Delete operations
Construct backwards.
Water Jug
Goal
↓
Reverse pours.
Math proofs often become obvious backwards.
Question
"If I already had the answer,
what must have happened immediately before?"
Many interview problems become trivial backwards.
Page 9 — Decomposition
Big problems are combinations of small ones.
Ask
"What independent pieces exist?"
Example
Word Search
Position
●
Direction
Knapsack
Item
●
Remaining Capacity
Trees
Left subtree
Right subtree
Combine
Graphs
Connected Components
Solve each separately.
Geometry
Split polygon.
Many recursive solutions come from
Divide
Solve
Combine
Every DP is basically
State
Transition
↓
Memoize
Page 10 — Thinking Like an Expert
Experts don't memorize.
They recognize.
Whenever you're stuck, slow down and ask:
Model
What exactly am I modeling?
State
What defines where I am?
Operation
What moves exist?
Information
What do I learn after each move?
Invariant
What never changes?
Objective
What am I optimizing?
Structure
Does this resemble:
● recursion?
● graph?
● interval?
● ordering?
● monotonicity?
● greedy?
● DP?
● geometry?
● probability?
● game theory?
Simplification
Can I:
● solve a smaller case?
● work backwards?
● sort first?
● compress the state?
● remove irrelevant information?
● prove something impossible?
● exploit symmetry?
Complexity
Where is the bottleneck?
Can I:
● preprocess?
● binary search?
● hash?
● cache?
● use a better data structure?
● trade memory for speed?
The Expert's Internal Monologue
The strongest problem solvers don't think, "I've seen this problem before."
They think:
"This is a search problem with a state (i, j), four legal operations, overlapping
subproblems, and a monotone property that lets me prune half the search space."
That's why they seem fast. They're not matching the exact problem—they're recognizing the
underlying structure.
Over time, you'll notice that almost every algorithmic problem is built from the same small set of
ideas:
● Define the right state.
● Understand the legal operations.
● Identify useful invariants.
● Recognize the underlying mathematical structure.
● Choose the algorithm that naturally fits that structure.
Once you train yourself to ask these questions automatically, new problems stop looking like
random puzzles and start looking like familiar patterns in disguise.