Hello there.

My name is Alexander Vatolin. For several years I've been teaching people across different areas of IT — some came for algorithms, some for system design, some for applied programming. Lately it's been more and more ML. And at some point I caught myself with a feeling I couldn't put into words for a long time: it's piled up.

Piled up are the notes I once wrote for a single student. Piled up are the explanations I've repeated twenty times — each time a little sharper. Piled up are the problems I picked by hand, because in the standard sets they're either too dull or too brutal. And all of this I finally want to pull out of my drafts and put out there — for the people it might help.

That's how the idea of this series came about. I'll start with competitive programming — because that's the area where I have the most material, and where, as it seems to me, the Russian-speaking internet still lacks calm walkthroughs without academic pomp or wildly inflated expectations. There's plenty on Codeforces already, so my posts are more of a sublimation of my own thoughts and opinions and don't claim to be the final word.

Today's post is an overview: what CP (competitive programming) is about, why anyone does it, and how the series will be laid out further on. The series is aimed more at beginners, but I'll always be glad to hear criticism and suggestions from veterans.

What competitive programming is

In one sentence: you're given a well-known problem from Computer Science — solve it as fast as you can. This wonderful description I borrow from the book CP4, which, in fact, is what nudged me toward this series in the first place.

There are three important words in that sentence, and each deserves its own paragraph.

"Well-known" — means the problem has already been solved. This isn't research; nobody expects you to invent a new algorithm. The author knows the solution, and hundreds of people before you have found it. Your job is to lift your level enough to recognize the problem and reach for the right tool.

"Solve" — means writing code that produces the same answer as the author's, on their hidden tests, within the time limit. Hidden tests are a separate important thing: they force you to think through edge cases yourself, rather than reading them off the statement.

"As fast as you can" — that's the sporting part. Without it, CP wouldn't be CP. And "faster" can mean both faster than your opponent and, sometimes, that your solution itself runs faster. More on that some other time.

What this looks like in practice

Let's take a simple problem. There are $$$N$$$ stalls on a line at coordinates $$$x_1 \lt x_2 \lt \dots \lt x_N$$$. You need to place $$$C$$$ cows in them so that the minimum distance between any two cows is as large as possible. Nobody likes being cramped — not even cows.

Now watch how different people approach this.

Beginner A sees "place them to maximize the minimum" and tries brute force: which $$$C$$$ out of $$$N$$$ stalls to pick. That's $$$C$$$-choose-$$$N$$$ — at $$$N = 10^5$$$ it'll never finish. Time Limit Exceeded.

Beginner B tries greedy: put the first cow in the first stall, then each next cow in the closest free stall where it fits. Doesn't work — Wrong Answer. The greedy here is dishonest: the optimal answer depends on which minimum distance you're aiming to guarantee, and you don't know it in advance.

Experienced C says: Aha. We don't know which distance $$$d$$$ is achievable, but if we fix $$$d$$$, the check becomes trivial — greedily place cows left to right, each next one no closer than $$$d$$$ from the previous, and count whether all $$$C$$$ fit. And notice: if $$$d$$$ works, then any smaller $$$d$$$ also works. So the answer is monotone in $$$d$$$. Which means — binary search on the answer. Writes it in half an hour, gets Accepted.

Sportsman D sees "maximize the minimum" and immediately writes binary search on the answer. Ten minutes. That connection is a reflex for them.

The difference between B and D isn't talent. The difference is that D once learned the pattern "maximize the minimum / minimize the maximum — try binary search on the answer," saw it in a dozen problems, and now recognizes it on autopilot. This can — and should — be learned. That, in essence, is what training is for. By the way, it seems to me these four levels line up rather nicely with the four divisions we see on CF.

Why I'm doing this (and maybe you should too)

Important note: CP isn't an end in itself. Nobody pays you a salary for solved problems on Codeforces or any other platform.

CP is a means. A means of becoming an engineer who:

• quickly recognizes familiar problems in unfamiliar wrappers;
• keeps a ready toolkit in their head and can assemble it for the problem at hand;
• automatically thinks about edge cases;
• debugs calmly under pressure and doesn't fall apart when nothing goes according to plan.

These skills pay off everywhere afterwards — from interviews to system design, from research to ordinary production work. It's no accident that IOI and ICPC were originally conceived as a way to cultivate well-rounded engineers, not as a self-contained discipline.

How the series will be laid out

The plan goes like this:

• One post — one topic. I'll try to start with the basics, then we'll wander into deeper territory. Maybe something unusual will come of it.
• The posts will mostly be about how to arrive at the algorithms, how to remember them, what cues hint that they're the right tool.
• At the end — a problem set on Codeforces and on my own site: from a baseline implementation of the algorithm to something properly tricky.
• Solutions for all the problems you can find without me. On CF most problems have editorials. On my little site I also publish solutions. And there the problems will mostly be on the easier side.

If this resonates — stick around. The next post will start with the most basic but no less useful technique: brute force. I'll try to get it out soon.

See you. I'll be glad to receive your problems, questions, and suggestions in the comments.

All posts in the series are tagged #EDU-M.