Sometimes I open a Codeforces problem, look at its rating, and think:

"This should be easy."

Then, 30 minutes later, I'm still staring at the screen.

The funny part?

Sometimes the solution is actually simple.

So why couldn't I solve it?

Recently, I've started realizing that there is a big difference between:

Knowing a concept

and

Recognizing when to use it.

For example, I might already know about:

• GCD
• Sorting
• Prefix sums
• Binary search
• Two pointers

But when a problem doesn't explicitly tell me which technique to use, everything suddenly becomes harder.

Reading the Solution Feels Easy

This is something I find interesting.

After failing to solve a problem, I read the editorial and think:

"Oh... that's it?"

The solution suddenly looks obvious.

But if I had never seen the editorial, I might have spent another hour without finding that idea.

Understanding a solution after seeing it and finding that solution independently are two very different things.

Maybe the Problem Isn't Always the Problem

Sometimes I fail because I don't understand the algorithm.

But sometimes the actual reason is much simpler:

• I missed an important detail in the statement.
• I ignored the constraints.
• I overcomplicated the problem.
• I started looking for an advanced technique too early.
• I had the right idea but couldn't implement it correctly.

This is why getting a wrong answer can sometimes teach me more than getting an accepted submission immediately.

The Most Dangerous Thought

For me, one of the most dangerous thoughts is:

"I can't solve this problem, so I probably don't know enough algorithms."

Sometimes that is true.

But sometimes I already know everything required to solve the problem.

I just failed to connect the pieces.

And recognizing those connections is probably one of the most important parts of competitive programming.

What I'm Trying to Improve

Instead of immediately searching for a complicated algorithm, I'm trying to ask myself a few questions:

• What exactly is the problem asking?
• What do the constraints tell me?
• Can I solve a smaller version of the problem?
• Is there something important that remains unchanged?
• Can I find a simple observation before thinking about advanced techniques?

Sometimes these questions lead nowhere.

But sometimes one small observation completely changes the problem.

Still Learning

A problem being easy doesn't necessarily mean it will be easy for me.

Every unsolved problem can reveal something that I need to improve.

Maybe one day, the problems that make me stare at the screen for an hour today will become the ones I solve in five minutes.

Hello Codeforces!

If you are completely new to Competitive Programming, starting can feel confusing.

You see thousands of problems, unfamiliar algorithms, and people solving problems much faster than you. Sometimes even an easy problem can feel impossible.

So, where should you start?

“Here are a few things I wish I knew when I started.”

1. Learn One Programming Language

First, choose one programming language and become comfortable with it.

If you're starting with C++, learn the basics first: loops, functions, arrays, strings, vectors, and basic STL. You don't need to master the entire language before touching Codeforces.

Once you know the basics, start solving problems.

Focus on:

• Variables and data types
• Input / Output
• Conditions
• Loops
• Functions
• Arrays
• Strings
• vector
• set
• map
• Basic STL

Don't spend months learning the language before solving problems. Once you know the basics, start practicing.

2. Understand Time Complexity

Before learning advanced algorithms, learn how to estimate the complexity of your solution.

At least understand:

O(1)

O(log n)

O(n)

O(n log n)

O(n²)

Always look at the constraints before deciding your approach.

For example, an O(n²) solution may work for small n, but can be too slow when n becomes large.

This habit will become extremely important as you improve.

3. Start With Easy Problems

Don't start with difficult problems just because you want to improve quickly.

Start with simple implementation and beginner-rated problems.

Your goal in the beginning should not be:

"How quickly can I increase my rating?"

Instead:

"Can I understand the problem and solve it by myself?"

Try to build the habit:

Read → Think → Code → Submit → Debug → Learn

Don't try to learn every DSA topic at once.

Start with basic problem solving and gradually learn new techniques as you encounter problems that require them.

There is no single roadmap that works for everyone. Focus on understanding the concepts and building your problem-solving skills gradually.

5. Participate in Contests

Don't wait until you become "good enough" to participate in contests.

Join contests while you're learning.

At first, you might solve only one or two problems. That's completely fine.

Contests teach you things that normal practice doesn't:

• Time management
• Reading problems quickly
• Choosing which problem to attempt
• Debugging under pressure
• Handling wrong submissions

Your rating may go down sometimes.

That's normal.

Rating is feedback, not your identity as a programmer.

When I first started looking at Codeforces, rating felt like the main goal. But rating can be a terrible way to measure your progress as a beginner.

Instead, ask yourself:

Did I solve something I couldn't solve last week? Did I understand why my solution got WA? Did I learn a new technique? Did I upsolve a problem after a contest?

If the answer is yes, you're improving.

6. Upsolve Your Unsolved Problems

This is probably one of the most important habits.

Suppose you couldn't solve Problem C during a contest.

Don't just move on.

After the contest:

1. Try the problem again.
2. Think about it without the contest pressure.
3. If you're still stuck, read the editorial.
4. Understand the main idea.
5. Close the editorial.
6. Implement the solution yourself.

This turns a failed contest problem into a learning opportunity. Upsolving is also a recurring recommendation in Codeforces roadmaps and beginner discussions.

Don't count a problem as “learned” just because you understood the editorial. Try implementing it again without looking.

7. Learn From Your Mistakes

WA, TLE and RE are part of Competitive Programming.

Instead of feeling bad about them, ask:

Why did my solution fail?

Maybe you:

• Missed an edge case
• Used the wrong data type
• Had an inefficient algorithm
• Misunderstood the statement
• Made an implementation mistake

If you understand the reason, the mistake becomes useful.

Final Advice

Don't try to learn everything at once.

Start small.

Solve problems regularly. Participate in contests. Upsolve your mistakes. Learn new techniques one at a time.

Most importantly, don't compare your progress with other people.

Everyone has a different starting point.

Your goal should simply be to become a little better than you were yesterday.

Learn → Practice → Contest → Fail → Upsolve → Improve

That's the journey.

Good luck, and happy coding!