How I Started With Competitive Programming (and What I Got Wrong First)
A journal entry on starting competitive programming: the first few weeks on Codeforces, what Neetcode and LeetCode taught me that I could not get from coursework and the specific mistakes beginners make that I made too.
I started doing competitive programming seriously in late 2025. I had done LeetCode sporadically for interview prep before that, but treating it as exam practice rather than skill-building meant I was grinding without developing intuition. The shift was moving to Codeforces for regular contests and using Neetcode to build structural understanding of algorithm patterns rather than just solving individual problems. This is what that process looked like from the beginning.
Why I Started
Two reasons. First: I was embarrassing myself in time-pressured settings. Not in interviews specifically, but in hackathons where I needed to implement something quickly and kept reaching for brute-force approaches because I did not have the pattern library for something better. Knowing that a problem needs a sliding window or a monotonic stack is not the same as having the reflex to recognise it under pressure. That reflex requires repetition.
Second: the maths. My engineering degree is heavy on signals, linear algebra and complex numbers - topics that do not map directly to algorithm design. I wanted to build the discrete mathematics and combinatorics intuition that CS undergraduates develop naturally but that EE curricula skip. Competitive programming is one of the fastest ways to build that specific type of mathematical thinking.
The First Few Weeks
The first Codeforces contest I entered seriously I solved problems A and B and got stuck on C for 40 minutes before the contest ended. This is completely normal. Codeforces problems A and B at Division 2 level are warm-up problems; C is where the actual thinking starts. At the beginning you will solve A and B comfortably and hit a wall at C. The wall is the work.
The mistake I made in week one was reading solutions immediately after failing. This is tempting - you are stuck, the solution is one click away, you read it and you think you understood it. But reading a solution and writing a solution from a blank page are different cognitive tasks. Read the editorial only after you have spent at least 30 minutes genuinely stuck, and then close the editorial and write the solution yourself without looking at it again.
Neetcode as a Structured Starting Point
Neetcode's 150 (and later 250) problem list is structured by pattern: two pointers, sliding window, binary search, trees, graphs, dynamic programming and so on. The value is not the problems themselves but the grouping. Seeing five sliding window problems in sequence makes the pattern obvious in a way that encountering them randomly does not. I went through each category in the Neetcode 150 before doing unstructured Codeforces practice.
The trap in pattern-grouped practice is false confidence. You can recognise a sliding window problem when you just did ten sliding window problems. The harder skill is recognising it in a mixed set. After finishing a category in Neetcode, I would do several Codeforces problems without looking at the category first, to practice the recognition step.
What Competitive Programming Does Not Teach You
Competitive programming problems are self-contained and have provably correct solutions with known constraints. Real engineering problems have ambiguous requirements, shifting constraints and no editorial. The skill transfer is in the problem decomposition and the comfort with uncertainty during the solving process - not in the specific algorithms. Do not assume that being good at Codeforces means you will be good at designing systems or debugging production issues. The skills overlap less than they appear to.
Practical Approach
- Codeforces Division 2 A-C is the right starting range; Division 3 is easier but less representative of real contest difficulty
- Virtual contests (past contests run as if live) train time pressure better than upsolving alone
- Keep a log of problem types you found hard; review them weekly, not when you happen to encounter the same type again
- Time-box solving: 30 minutes on a problem, then take a hint (not a full solution); 30 more minutes, then read the editorial
- LeetCode is optimised for interview prep; Codeforces is better for developing algorithmic intuition; use both for what each does well
References and Resources
- 01.Codeforces - competitive programming platform with rated contests
- 02.Neetcode - structured algorithm practice with video explanations
- 03.LeetCode - interview-focused algorithm practice
- 04.CP-Algorithms - high-quality explanations of common competitive programming algorithms
- 05.The Algorithm Design Manual - Skiena - better than Cormen for developing problem-solving intuition
- 06.Introduction to Algorithms (CLRS) - the standard theoretical reference
- 07.Competitive Programmer's Handbook - Antti Laaksonen (free PDF from cses.fi)
You might also like
Inside British Airways Engineering: What a Maintenance Simulation Taught Me
Reflections on the British Airways Engineering Virtual Experience on Forage, covering A320 maintenance planning, C-check operations and what aviation engineering looks like from the inside.
Learning Business Analytics: From Probability to Machine Learning
Notes from working through a structured executive education business analytics course, covering probability, statistics, Python, descriptive analytics, predictive ML and prescriptive optimisation.
Why Every Software Engineer Should Understand Hardware
An argument for why understanding hardware - registers, memory, timing, power - makes you a significantly better software engineer, regardless of whether you ever write firmware.
React to this post