Small Competitive Programming Mistakes That Cost Me AC

Hi everyone!

I am still learning competitive programming, and recently I noticed that many of my wrong submissions were not caused by difficult algorithms.

They were caused by very small mistakes.

So I decided to collect some of the mistakes that cost me AC, especially for beginners. ## 1. Using int when the answer needs long long

Sometimes every individual value fits inside int, but their product or total sum does not.

For example:

int n = 100000;
int x = 100000;

cout << n * x;

n * x = 10^10, which does not fit inside a 32-bit int.

A safer version is:

long long ans = 1LL * n * x;

The important part is 1LL.

2. Forgetting that integer division removes the decimal part

Consider:

int x = 25;

double p = x / 100;

You might expect 0.25, but the result is actually 0.

Why?

Because x and 100 are both integers, so integer division happens first.

Correct:

double p = x / 100.0;

3. Floating-point numbers are not always exact

Sometimes:

double x = 0.1 + 0.2;

is not stored internally as exactly 0.3.

So comparing doubles using:

if (x == 0.3)

can be dangerous.

Usually, use an epsilon:

const double EPS = 1e-9;

if (abs(x - 0.3) < EPS)

Also, do not automatically use round() everywhere. Use it only when the problem actually asks for rounding.

4. An O(n^2) idea can look fast on small tests

This code may look harmless:

for (int i = 0; i < n; i++) {
    for (int j = 0; j < n; j++) {
        // ...
    }
}

But if:

n = 200000

then the number of operations is roughly:

4 * 10^10

which is far too much.

Before coding, I now try to estimate the complexity first.

A useful rough guide:

• n <= 20 → exponential solutions may be possible
• n <= 2000 → O(n^2) may be possible
• n <= 2 * 10^5 → usually aim for O(n log n) or O(n)

These are not strict rules, but they are useful estimates.

5. map can secretly make the solution slower

Sometimes we use:

map<int, int> mp;

even when a simple array or vector is enough.

map operations are approximately:

O(log n)

while direct array access is:

O(1)

If values are small enough, this:

vector<int> freq(MAX_VALUE + 1);

can be much faster.

Of course, map is still useful when keys are large, sparse, or ordered traversal is needed.

6. Forgetting edge cases

A solution may work on all the examples and still fail immediately because of something like:

n = 1
all values equal
answer = 0
maximum possible value
minimum possible value

Before submitting, I try to test:

smallest input
largest special case
all equal
strictly increasing
strictly decreasing

Not every problem needs all of them, but thinking about these cases catches many bugs.

7. Changing a variable while still depending on its old value

Example:

a[i] = x;

if (condition(a[i])) {
    ...
}

Sometimes we actually needed information about the old a[i] before replacing it.

A safer update pattern is often:

removeContribution(a[i]);

a[i] = x;

addContribution(a[i]);

This is especially useful in problems with queries and frequency counting.

8. Greedy solutions need a reason

One of my most common mistakes was:

"Choosing the largest value looks optimal."

Sometimes it is.

Sometimes it gives WA on test 2.

Before using greedy, I now ask:

If I make this choice now, can it make the future worse?

If the answer might be yes, then the greedy idea needs proof.

9. Do not optimize before understanding the problem

Sometimes I immediately think about:

• binary search
• DP
• graphs
• Fenwick trees
• advanced data structures

while the real observation is just:

sort the array

or:

count frequencies

Understanding what the problem is actually asking is often more important than knowing more algorithms.

10. Read the statement one more time before submitting

This sounds obvious, but many WA submissions come from missing one word:

• exactly
• at most
• at least
• distinct
• non-decreasing
• positive
• non-negative

Those words can completely change the solution.

Final thought

Competitive programming is not only about learning more algorithms.

It is also about making fewer unnecessary mistakes.

Every WA or TLE can teach something useful if you understand why it happened.

If you know another small mistake that often causes WA/TLE, feel free to add it in the comments.

Good luck and happy coding!