← Back to all posts

I started competitive programming out of curiosity and stayed because it made me a significantly better engineer. Here’s what I’ve learned along the way — the strategies that worked, the mistakes I made, and advice for anyone starting out.

Why Competitive Programming?

CP teaches you to think fast, clearly, and under constraints. In a contest, you have 2 hours to solve 5-6 problems of increasing difficulty. There’s no Stack Overflow, no autocomplete, no AI assistant — just you and the problem.

This pressure forces you to develop skills that transfer directly to real-world engineering:

• Breaking complex problems into smaller subproblems
• Estimating time complexity before writing code
• Debugging systematically when your solution gets Wrong Answer
• Knowing when your approach won’t work and pivoting quickly

My Platform Setup

I use two platforms for different purposes:

Codeforces

Best for: Competitive contests and learning algorithmic thinking

• Rated contests every week (Div 1, 2, 3, 4)
• Problem difficulty is well-calibrated
• The editorial + community solutions are excellent for learning
• Focus: math-heavy problems, constructive algorithms, number theory

LeetCode

Best for: Interview preparation and pattern recognition

• Problems are tagged by company and topic
• Great for practicing specific patterns (sliding window, DP, etc.)
• Discussion section often has optimal solutions with explanations
• Focus: practical DSA patterns used in technical interviews

Strategies That Actually Work

1. Solve by Topic, Then by Difficulty

Don’t jump to random problems. Pick a topic (say, binary search), solve 15-20 problems of increasing difficulty, then move on. This builds deep pattern recognition.

2. Upsolve Religiously

After every contest, solve the problems you couldn’t solve during the contest. This is where the real learning happens. Read the editorial, understand the approach, then implement it yourself without looking at the solution.

3. Learn to Identify Time Complexity Ceilings

Before coding, calculate the maximum input constraints:

• N ≤ 10^3 → O(N³) is fine
• N ≤ 10^5 → O(N log N) needed
• N ≤ 10^7 → O(N) or bust
• N ≤ 10^18 → Math/binary search/matrix exponentiation

This alone saves hours of debugging TLE solutions.

4. Build a Template Library

Maintain a personal library of well-tested implementations:

• Graph algorithms — BFS, DFS, Dijkstra, DSU
• Data structures — segment tree, Fenwick tree, sparse table
• Math — modular arithmetic, sieve of Eratosthenes, fast exponentiation
• String algorithms — KMP, Z-function, hashing

During contests, you want to spend your time on problem-solving, not re-implementing standard algorithms.

5. Participate Consistently

Consistency beats intensity. Solving 2-3 problems daily for months is far more effective than grinding 50 problems in a weekend and burning out.

Common Mistakes to Avoid

• Not reading the problem carefully — I’ve lost countless points to misreading constraints
• Overcomplicating solutions — the intended solution is often simpler than you think
• Ignoring edge cases — empty arrays, single elements, maximum values, negative numbers
• Not practicing implementation speed — knowing the algorithm isn’t enough; you need to code it fast and correctly

The Bigger Picture

Competitive programming isn’t just about ratings and colored handles. It’s about building a problem-solving mindset that serves you in every aspect of software engineering.

When I work on my Spring Boot projects, the same mental model kicks in: decompose the problem, consider edge cases, think about efficiency, and iterate.

Start where you are. Solve what you can. Upsolve the rest. Stay consistent.