
Last month, ITMO University launched an edX course called How to Win Coding Competitions: Secrets of Champions. With this first iteration of the course coming to an end, I thought I would discuss my experience with it.
Deliberate practice techniques for software developers

Last month, ITMO University launched an edX course called How to Win Coding Competitions: Secrets of Champions. With this first iteration of the course coming to an end, I thought I would discuss my experience with it.

Scott Young has recently been writing about a concept he calls ultralearning, a philosophy and collection of techniques for quickly gaining mastery of a subject. This week, I’m going to explore how we can use ultralearning techniques for competitive programming practice.

Programmers get better at competitive programming mainly by solving competitive programming problems. It’s true that there are other activities that go along with problem-solving practice. Reading about algorithms, data structures, and problem-solving techniques is useful to avoid re-inventing the wheel. And it’s even more important to read solutions after you solve a problem, so you can learn from other practitioners and fix your mistakes. But the core of the learning process is solving problems. Without that core, reading textbooks and solutions won’t get you very far.

In January of this year, Jasmine Chen (lnishan) published a Codeforces blog post called An awesome list for competitive programming! Since then, she and a few collaborators have been editing and expanding the list on GitHub.
Awesome list in this context doesn’t just mean “a really great list.” It refers to a project started by Sindre Sorhus in which people create lists of links to useful and/or interesting resources, and publish them on GitHub. There is of course a list of these lists.
Here’s what the Awesome Competitive Programming list offers.

To get better at programming or math, it’s not enough to read about a topic. You have to solve problems. And solving problems is a lot more beneficial if you have access to solutions, especially ones with detailed explanations. But as useful as solutions are, they also present another problem: when is the best time to look at them?
Solving a problem yourself improves your understanding of a concept more than reading someone else’s solution. If that wasn’t true, then it would be possible to learn a technical subject just by reading about it. That would be easier, but it doesn’t work. So you need to struggle with problems.
However, you can’t avoid looking at the solution forever. Problems in textbooks or online judges are intended to be solved in hours or days. They aren’t unsolved research problems that take months or years to solve. (Or if they are, they’re clearly marked as such — e.g., some of the problems in Knuth’s books).
So part of your job as a problem-solver is to settle on the best time to look at each solution.

When I came up with 12 Reasons to Study Competitive Programming, I picked the following for reason #3: Studying competitive programming gives you a way to practice solving hard problems.
(As I pointed out in the article, this is also a reason that some people give for not studying competitive programming. They claim that most software developers work only on trivial problems. So they don’t see any reason to practice solving hard problems. That has always seemed to me like a backwards argument).
What does it mean for a problem to be hard? To answer that, I’ll borrow part of the definition of deep work: a problem is hard if it requires specific training and experience to solve. While some ad-hoc competitive programming problems can be solved by any programmer willing to spend an hour or so thinking and coding, modern contests contain problems that only programmers who have spent considerable effort practicing can solve in a reasonable amount of time.
That’s the type of hard problem that I’m talking about. To be hard, a programming problem doesn’t have to involve an unsolved research question. But it does need to provide a challenge to people who spend a lot of time solving puzzles.
What makes competitive programming hard? Here are some factors.

If you have a question about competitive programming, Quora is a good place to find the answer. Quora’s Competitive Programming topic attracts experienced competitive programmers, and they have written answers to a variety of common questions that beginning and intermediate programmers have about the subject.
It has been a few years now since the Quora topic was created, and most questions about the fundamentals of competitive programming have been asked and answered. While there are still new questions about specific problems, and about current events, it’s rare to see a new question about fundamentals.


It’s October, the time of year when leaves start to fall from the trees, and companies start to recruit college students for summer internships. Last week, I spent half a day interviewing some of those candidates. I also came across a long Hacker News thread called I Hate HackerRank. So I thought it would be a good time to revisit the dreaded coding interview.

Can you learn anything you want by reading a book? A blog post by Scott Young last week got me thinking about claims that some subjects are unteachable. Here are some examples:
Claim: Some knowledge and skills can only be learned using an apprenticeship approach.
Claim: You have to figure out your own path to success. You can’t learn the path from someone else.
Claim: It’s not always possible to teach someone to be a top performer, despite the best efforts of teacher and student. Factors other than practice time explain why some people perform better than others.

If you want to get better at something, you need a plan. Improvement doesn’t happen on its own. But once you have that plan, a bigger challenge is executing on it along with your other responsibilities.
One way to increase your chances of following through on changes is not to try to make big changes all at once. Instead, make small changes, but make them regularly. Let’s see how that works.