Getting Started

Welcome aboard! 🎉 We’re kicking things off with a friendly and practical introduction to competitive programming — and yes, that means diving into some real problems right away.

These first challenges may look elementary, but don’t let that word fool you. They’ll test your logic, your attention to detail, and your ability to understand problem statements — skills that every successful coder needs.

So, grab your keyboard and get ready to meet your first “opponent” in this world: the robot judge. 🤖

What Are “Elementary” Problems?

In this opening section, we’ll focus on problems that only require basic programming concepts — mostly arrays and loops.

These are the building blocks of problem solving. You’ll learn how to read the problem carefully, design a solution, and write clean, functional Python code that passes the robot judge’s strict tests.

Think of this as your training arc — learning how to handle test cases, input/output formatting, and efficient code writing.

Even though these problems don’t use advanced algorithms yet, they’re an excellent way to sharpen your skills and prepare for what’s coming next.

Meet the Robot Judge

In competitive programming, you don’t submit your code to a human instructor — you submit it to a robot judge.

This judge doesn’t care about your comments or variable names. It only checks one thing - Does your program produce the correct output for all hidden test cases?

If even one test case fails, the judge rejects your solution. 😅

So, precision is everything — reading the input carefully, matching the output format exactly, and handling edge cases like a pro.

Understanding the Robot Judge’s Feedback

So, you’ve written your first program, tested it locally, and confidently hit Submit. The screen loads, the judge runs your code through its mysterious test cases... and then — boom — you get something like:

❌ Wrong Answer

or worse…

⚙️ Time Limit Exceeded

Don’t panic! 😅 This is a completely normal part of competitive programming. Every coder — even the best — has stared at those verdicts wondering what went wrong.

Let’s go step by step and understand what the robot judge is trying to tell you, how to read the verdicts correctly, and what you can do about them.

✅ Accepted (AC)

🎉 Congratulations! Your program passed all test cases within time and memory limits.

It’s correct, efficient, and well-behaved.

You can celebrate — maybe even screenshot that green tick. 💚

⚠️ Presentation Error (PE)

Your output values are correct, but the format isn’t exactly right. Maybe there’s:

• An extra space at the end of a line
• A missing newline
• Wrong indentation

To fix this, print exactly what’s required — nothing more, nothing less.

❌ Wrong Answer (WA)

This one stings a bit — your program ran fine but produced an incorrect result for at least one hidden test case.

That means there’s a logic bug or an edge case you missed.

To fix it:

• Re-read the problem statement carefully — maybe you assumed something incorrectly.
• Add your own extra test cases, especially with edge values (like 0, 1, large numbers, etc.).
• Use print debugging (or a Python debugger) to trace where your logic might fail.

Remember — resubmitting the same code won’t help. You need to fix the logic.

🧱 Compile Error (CE)

This means your code didn’t even run — the judge couldn’t compile or interpret it.

For Python, this usually means:

• You missed a colon (:)
• You have an indentation error
• Or a variable is undefined

Fix the syntax errors, test locally, and resubmit.

💥 Runtime Error (RE)

Your code started running but crashed midway.

Common causes:

• Division by zero
• Using an invalid index (like arr[10] in a 5-element list)
• Infinite recursion
• Memory access issues (rare in Python but common in C++)

⏰ Time Limit Exceeded (TLE)

The dreaded TLE means your program works — but it’s too slow. You hit the judge’s time limit (usually 1–3 seconds per test case).

You’ll need to optimize your algorithm.

💡 Think smarter, not harder — efficiency wins contests.

🧠 Memory Limit Exceeded (MLE)

Your code tried to use more memory than allowed. Maybe you created a huge list or a recursive function that grew too deep.

Programming Hints

Before we dive deep into advanced algorithms and problem-solving patterns, let’s pause and talk about something equally important — how to program better.

This isn’t a “how to code” guide — you already know the basics like variables, if statements, loops, and functions. What we’re going to do here is level up your style — the way you think, structure, and write code that’s clean, reliable, and contest-ready.

You already have all the tools you need. The secret is learning how to use them effectively. ✨

Let’s walk through some habits and tips that will help you write cleaner, more contest-friendly Python code.

1. Write Comments First

Before you start typing code, take a moment to describe what your program or function is supposed to do — in words.

If you can’t explain it clearly, you probably don’t fully understand it yet.

These short comments become your roadmap. They make debugging easier and keep your thought process clear.

Even in a contest setting where time is tight, a 10-second comment can save you 10 minutes of debugging.

2. Document Each Variable

When you declare a variable, jot down what it represents. It might sound small, but when you’re debugging 15 minutes later, you’ll thank yourself.

If you can’t describe a variable easily, maybe you don’t really need it — or don’t fully understand its purpose.

3. Use Constants Instead of Magic Numbers

Avoid sprinkling random numbers all over your code. Instead, define constants at the top so your code is easy to maintain.

This way, if the board size changes or the limit increases, you only need to update it once — not everywhere.

4. Don’t Overcomplicate Simple Data

In short programs, you don’t always need to create custom objects or complex structures.

In contests, clarity and speed matter more than architecture.

5. Avoid Repeating Code — Use Functions

Whenever you find yourself copying the same code twice, stop. That’s a signal you should extract it into a function.

This is shorter, easier to read, and far less error-prone.

A Final Word of Wisdom

If you get “Wrong Answer”, the judge won’t tell you which test case failed. No hints. No hand-holding.

This might sound harsh — but it’s actually one of the best teachers. It forces you to:

• Think like the problem setter
• Test your code rigorously
• Develop clean, generalizable logic

So when the robot keeps saying “NO” but you’re sure your code is right — take a deep breath, go back to the problem, and read the specs again. Chances are, you’re missing something tiny… and fixing it will teach you more than any tutorial ever could. 💡