Why I built AlgoPath

I could write code. I had shipped real things that real people used. And I still sat in front of an interview problem with no idea what to do.

That gap is what AlgoPath is for.

What actually went wrong

I did what everyone recommends. I opened a problem site, picked a problem, got stuck, read the solution, understood the solution, and felt fine. Then I opened the next problem and got stuck again.

After about 60 problems I noticed something uncomfortable. I was not getting better at solving problems. I was getting better at reading solutions. Those are different skills, and only one of them shows up in an interview.

Here is the moment it became obvious. A problem asked for the longest stretch of a list where some total stayed under a limit. I stared at it for 20 minutes. Then I read the answer: sliding window. I had solved four sliding window problems that same week. I knew how to write one. What I could not do was look at a problem that never says the words "sliding window" and recognise that it wants one.

Nobody had ever taught me that step. Every tutorial I had watched started after it. "Today we solve this with a sliding window" - and then a clean explanation of a thing I already knew how to write.

The step in the middle

Solving an algorithm problem has three parts:

1. Read the problem and work out what kind of problem it is.
2. Recall how that kind of problem is solved.
3. Write the code.

Courses teach 2 and 3. Problem sites give you 3. Part 1 is where interviews are won and lost, and it is treated as something you pick up by accident after enough repetitions.

You can pick it up by accident. It takes a few hundred problems and most people quit before then, which is roughly what happened to everyone I knew who tried.

So I built the thing that trains part 1 directly.

What that turned into

150 steps in order, each leaning on the one before it. A step takes one idea, explains it, has you write it, then drops it into a real production situation - a rate limiter, an LRU cache, an autocomplete. "Find the pair that sums to a target" and "match a refund against the two charges that produced it" are the same algorithm, and only one of them sounds like a job.

Alongside them: 52 patterns, each with the signals that point at it and the neighbour that looks right and is not. And 194 unlabelled problems, where you name the pattern before writing a line and are told whether you were right. That last one builds a map of what you confuse with what, which is the most useful thing I have ever had while studying this.

How a step works

Read the idea. Learn the signals that point at it, before the code, on purpose. Write the core yourself in an editor on the page - JavaScript, Python or PHP, running in your own browser. Some steps hand you working code with one planted bug instead. Then wire it into the real case and make it pass. Stuck steps have a hint ladder that starts with a question and ends near the code, and you choose how far down you go.

A step is done when you can explain it with no notes and write the core again from a blank file. Then it comes back a few days later, then a couple of weeks, then a month.

Three depths

Every lesson is written three times and you pick which one you read, per step. Simple assumes nothing and uses no jargon. Standard is how a working developer would put it. Academic gives you invariants, correctness and precise complexity. A course written only for beginners gets abandoned by everyone else; one written properly loses the people it was for on page one.

Who it is for

People who can write a loop and a function, and stall the moment a problem does not announce what it wants.

That includes career switchers, self-taught developers, and people with a few years of working experience who never studied any of this formally. I am in that last group. The course starts at "what is an algorithm" for a reason: I got tired of material that assumed I already knew what a hash table did internally, and I did not want to build the same wall for someone else.

It is not for people preparing for competitive programming contests, and it will not get you through an interview next week.

Why I am the one writing it

I am Elman Huseynov. I have worked as a software engineer for 10 years, currently at Zalando in Berlin, before that at Shopify and Scoutbee. Mostly JavaScript, TypeScript and React on one side, PHP and Python on the other. The longer version is at helloelman.com.

None of that stopped me freezing in front of an algorithm problem, and that is the part worth saying out loud. I had shipped production systems used by a lot of people and I still could not read an unfamiliar problem and say what kind of problem it was. Those two skills are related far less than the job titles suggest.

I also never studied computer science. Everything I know I picked up while shipping, which is efficient for the work in front of you and leaves specific holes. This was one of the holes.

I built the whole thing while learning it, which shows up in the material. Every place the explanations slow down and repeat themselves is a place I got stuck.

Where to start

The first 33 steps are free, and that is not a sample. It covers Big O, hash tables, two pointers, sliding windows and binary search - about a fifth of the course, and enough that the recognition trainer and the confusion matrix have real content in them.

Start at step 1 if any of the words above are unfamiliar. Start at the recognition trainer if you already write code and want to know how bad the gap is.

Both of those are the same link: algopath.pro.