Reading grader feedback and submission discipline

When you submit a solution to a judge, the grader returns a verdict. AC means you solved it. WA means the output was wrong. RE, MLE, and TLE are errors. Each verdict tells you something different about what went wrong. Reading the verdict and thinking through what it means is the first step to fixing your solution.

What each verdict means

AC (Accepted): your solution is correct on all test cases. You are done with this problem.

WA (Wrong Answer): your output does not match the expected output on at least one test case. Your logic has a bug, or you misread the problem statement. The judge does not show you which test case failed or what the expected output was.

RE (Runtime Error): your code crashed. This happens if you access a list out of bounds, divide by zero, recurse too deep, or hit another runtime fault. The judge sometimes shows a short error message. Read it carefully. IndexError usually means you read past the end of a list. RecursionError means you recursed too deep without raising the limit.

MLE (Memory Limit Exceeded): your code used too much memory. This happens if you store too much data in a list or dictionary, or if you forgot to stop allocating memory in a loop.

TLE (Time Limit Exceeded): your code ran too slowly. The judge gave it a fixed number of seconds (usually 1 to 5, depending on the contest) and your code did not finish in time. This means your algorithm is too slow, or you have an unnecessary loop or expensive operation that is making it slow.

What to do for each verdict

AC: celebrate and move on.

WA: your logic is wrong. Do not blame the judge or guess. Go back to your code. Test it locally on the sample input. If it passes the sample, read the problem statement again. You may have misread what it is asking. If you reread the problem and still think you understand it, write more test cases. Try edge cases: empty input, single element, all zeros, all the same value, minimum and maximum constraints. One of these will probably fail.

RE: Look at the error message. If it is a recursion error, either increase the recursion limit with sys.setrecursionlimit() or rewrite your code iteratively. If it is an array access error, add print statements before the crash to see what index you are trying to access. Check your loops. Check your array sizes. Off-by-one errors are common here.

MLE: you are storing too much. Check whether you need every data structure you created. If you are using a list, do you need to store all values, or can you process them one at a time? If you are using a dictionary, is every key necessary? Sometimes you can use a simpler data structure or process input in a streaming way.

TLE: your algorithm is too slow. This is usually an algorithmic problem, not a small optimisation. If the time limit is tight and you know your algorithm is asymptotically correct, look for expensive operations: do you call a function that is O(N) inside a loop that is already O(N)? Can you precompute something? Can you use a faster data structure like a set or dictionary instead of a list?

Submission discipline

When you fix a bug and resubmit, make one change at a time. If you change three things at once and the next verdict is still wrong, you do not know which change mattered and which two made things worse.

Test locally before you submit. Run your solution on the sample input. If it fails locally, do not submit yet. Once it passes locally, submit. If it gets WA at the judge, come back and add more test cases locally.

Do not panic and start guessing. One wrong submission wastes time and uses up your submission quota (some contests limit submissions). Read the feedback, think about what it means, make a targeted fix, test locally, and resubmit.

Keep a list of what you have tried. If you submit three times with different changes and they all fail, you need to step back and reconsider your approach, not just keep tweaking. Maybe you misread the problem. Maybe the algorithm itself is wrong.

A worked example: fixing a TLE verdict

Your solution gets TLE. The problem asks to find all pairs of numbers that sum to a target value in an array of size 10,000. Your first attempt uses nested loops: for each number, check if its complement is in the array by searching linearly. This is O(N squared), too slow.

You rewrite using a set: build a set of all numbers, then for each number check if its complement is in the set. This is O(N), much faster. You test locally on the sample and it runs instantly. You submit. Still TLE.

You step back. You realize you are not reading the problem correctly. The array has 100,000 elements, not 10,000. Your O(N) solution should still handle that, but you check your implementation. You are reading the input inefficiently, using int(input()) in a loop 100,000 times. Switching to sys.stdin.read().split() and parsing once makes your input faster. You submit again. AC.

The lesson: when you get TLE, the problem is usually algorithmic (pick a slower algorithm faster). But sometimes it is input parsing or a hidden operation inside your loop that is expensive. Test locally with the maximum constraint, not the sample.

Pattern recognition across verdicts

Over time, you recognize patterns. If you always get WA on the same problem, the issue is likely logic, not format or runtime. If you get TLE on problems with large arrays, you might have a data structure bottleneck. If you get RE on problems with deep recursion, you know you need to increase the limit or rewrite iteratively.

Keep notes on your past submissions. Which problems have you solved? Which gave you WA multiple times before you figured it out? Which took a quick fix? This history teaches you where your weak spots are. Focus practice on those areas.

Recap

AC means you are done. WA means your logic is wrong; test locally and look for edge cases. RE is a crash; the error message tells you what kind. MLE means you used too much memory; simplify your data structures. TLE means your algorithm is too slow; rethink the approach. For any verdict except AC, make one change, test locally, and resubmit. Keep track of what you have tried to avoid repeating the same fix.