Why are algorithms so hard when you can already code
Elman Huseynov · 2026-09-29 ·
Short answer. Writing code and solving algorithm problems are two skills, and the second rests on five ideas nobody lists. What an operation costs. Which container fits the question. The invariant a loop keeps. Solving a small example by hand. Reading the constraints as instructions. Each idea fits in a paragraph, and all five take about a week.
1. What an operation costs
You know how to look something up in an array. The question is what that costs.
An array index is one step whatever the size. Searching an unsorted array is one step per element.
Looking up a key in an associative array is one step. Sorting is n log n.
Five facts. Without them every choice is a coin flip. You cannot compare two plans you cannot price. How to price them is in Big O notation explained simply.
2. Choosing the container
Most beginners keep everything in an array. Arrays are what they were taught.
The question worth asking is what you need to do most often.
Asking "have I seen this" points at a set. Asking "what value belongs to this key" points at a map.
"Give me the smallest so far" points at a heap. Order matters, keep an array.
Half of all interview problems are solved by picking right here. The rest of the code follows on its own.
3. The invariant
An invariant is one sentence. It stays true on every pass of the loop.
"Everything left of i is already sorted." "The window always sums to at most k."
Loops without one are written by trial and error.
You add a plus one, the test passes, and you never learn why.
Write the sentence before the loop.
Most off-by-one bugs stop existing. A plus one either keeps the sentence true or it does not.
4. Working the example by hand
Take four elements and solve them on paper. Slowly.
Your hand compared two things, remembered a best value, and moved forward.
Comparing, remembering, and moving forward is the algorithm.
Most techniques in the first half of any curriculum formalise something people already do by hand.
Skip this step, and the code feels like it came from nowhere.
5. Reading constraints as instructions
"n up to 1000" allows a quadratic solution. "n up to 200000" forbids it.
One line often decides the whole approach. Beginners read it as trivia. The full table of bounds is in time complexity from the constraints.
What none of this is
None of the five is about intelligence. None is about maths.
The five are small pieces of knowledge, one paragraph each. Most tutorials assume you have them.
Six months of writing working code is enough. All five fit in a week.
The order it arrives in makes it feel impossible. You were handed step 40 and told it was step 5.
Where the ladder starts
AlgoPath starts before the first algorithm, with the free lesson what is an algorithm.
Costs, containers, invariants, constraints. One step each, in that order, with code you write.
The first 33 steps are free, and they cover all five.
The skill above the five is pattern recognition. The mixed-up pairs are in algorithm patterns people confuse.
If the material itself feels hostile rather than hard, that is a different problem with a different fix.