I hate algorithms, and here is what is actually going wrong
Elman Huseynov · 2026-08-07 ·
Most developers dread algorithms.
Developers cram before an interview. Then they forget it.
That reaction is earned. Here are four reasons, and a fix for each.
1. You see the answer before the question
Open any binary search tutorial.
A tutorial starts with the name. Then it shows the code.
The interesting work already happened. Someone read a problem and decided it was binary search. The video starts after that.
A real problem sounds different: "Find the smallest capacity that ships all packages in 10 days."
Nothing in that sentence looks like a sorted array.
The fix. Before you read a solution, write one line. What in the problem should have pointed you there?
If you cannot write it, you have read the problem and nothing more.
2. Nobody says what the code is for
"Reverse a linked list" is a riddle.
I did it several times before I found out what it runs.
An LRU cache moves a used entry to the front. Undo walks back through a chain.
A scheduler pulls a task out of a queue.
Pulling a task off a queue is a normal Tuesday at work.
The fix. For each algorithm, find one real system that runs it.
git bisect is binary search. Rate limiters are sliding windows.
Database indexes are balanced trees.
Five minutes each. It turns trivia into machinery.
3. The difficulty jumps
The usual path: variables, loops, functions, interview problems.
A lot hides in that gap.
Why an array lookup is instant. What a hash table does. Why instant stops being true at 10 million items.
Nobody says it out loud.
You fail a problem a stranger labelled Easy. You draw a conclusion about yourself.
The conclusion is wrong. You were handed step 40 and told it was step 5.
The fix. When something feels impossible, look for the missing step. It is usually one idea, and smaller than it looks.
4. The scoring tells you nothing
A problem site gives you one bit. Solved, or not.
Four separate things can fail.
Recognising the pattern. Recalling the technique. Getting the edges right. Writing correct code.
A red cross hides which one it was. So you fix nothing and open another problem.
Skipping the fix is how people grind for months and stay still.
The fix. After every problem, write down which of the four failed.
Two weeks of that beats 100 more problems.
The week that carries all four is how to prepare.
The part that really is hard
Some algorithms are genuinely difficult. Dynamic programming takes time however it is taught.
Most of the misery comes from the order it arrives in.
Hide the reasoning. Strip the purpose. Skip the foundation. Then measure with one bit.
Fix those four and the wall goes away. It still takes months.
The work stops being unpleasant. That decides whether you finish.
The longer version of why I care is in why I built AlgoPath.
Where I put this into practice
AlgoPath is built on those four fixes.
Signals come before the solution. Every step ends in a real production case. The ladder starts at "what is an algorithm". The trainer names which of the four you missed.
The first 33 steps are free.