You finish your code, test it, and everything looks clean. There are no errors, the outputs match, and the logic feels solid. You hit submit… and your score comes back lower than expected. What gives?
If you’ve encountered issues with an auto-grader, you’re not alone. Maybe you passed all the sample cases. Maybe your code even worked for edge inputs on your end. But the platform docked points anyway, and it’s not telling you why.
That’s where grading rubrics come in. Most online judges (HackerRank, Codility, university portals, etc.) use strict behind-the-scenes rules to grade submissions. These go beyond just “Does the code run?”, they check for time limits, output format, untouched boilerplate, and more. And small missteps in those rules? They cost real marks.
In this post, we’ll break down five of the most common traps that students fall into, as well as the quick checks we use to dodge them every time. No fluff, no theory, just the practical stuff that actually saves points.
Before we get into the traps, a quick note: if you’re struggling with the same situation and need a reliable expert to do your programming homework, we’ve been helping students since 2014.
Trap 1: Passing Sample Input Isn’t Enough
You write your code, you run the sample tests, and it works. You might think you are done, right?
Not even close.
Sample test cases are meant to get you started. They’re often too simple, too “clean,” and rarely cover the full range of what the grader will actually check. The real grading happens behind the scenes, with hidden test cases that go over all the edge conditions, boundary values, and inputs designed specifically to break sloppy logic.
A common fail case would be a code that works perfectly fine for a small array of positive numbers but breaks miserably when fed zero, negatives, or even on an empty list. Another scenario would be a piece of logic that assumes sorted input when none was promised.
Your Checks:
- Test with empty inputs (e.g. [], “”, 0)
- Throw in max-size inputs, especially if the constraints mention something like 10^5 or more
- Try weird formats, repeated values, all same elements, unsorted data, etc.
Mini Tip
Assume the grader is trying to break your code. Because it is. Design your tests like you’re debugging your future mistakes.
Trap 2: Hardcoding Output Format
Your logic is spot on, and the values you’re printing are correct, but your submission still fails. Why? Because your output wasn’t formatted exactly the way the grader wanted.
Online judges don’t grade you like a human would. They don’t care that your answer looks right. If there’s an extra space, a missing newline, or even the wrong capitalization, your submission can fail.
Let’s say the expected output is ”Result: 10”. You print ”Result:10” without the space, that’s enough to lose points. Or worse, the prompt expects ”YES” in uppercase and you print ”Yes”. Looks harmless. Fails instantly.
Your Check:
- Copy-paste the expected output format directly from the problem statement. Build your output to match it exactly.
- If the prompt says the output should be “yes” or “no,” treat it as case-sensitive. Most are.
Mini Tip:
The grader is a robot. It doesn’t infer or assume, it matches strings. If it says print “Done”, printing “done” is a wrong answer.
Trap 3: Runtime or Memory Limits Exceeded
This one stings a lot because your code is right. It works. It gives the correct output on sample cases. But when you do submit, the grader throws a Time Limit Exceeded or Memory Limit Exceeded error, and your score tanks.
What went wrong? Most likely, your solution just wasn’t fast enough.
Most students hit this when they use brute-force approaches that work fine for small inputs but choke on large ones. Common culprits are:
- Nested loops that run in O(n²) when O(n log n) is needed
- Sorting inside loops
- Building or storing huge arrays unnecessarily
If the input size goes up to 10^5 or higher, the platform expects near-linear solutions. Anything above O(n log n) usually won’t make the cut.
Your Checks:
- Always read the input constraints; they’re not just filler. They’re hints on the expected complexity.
- Do a rough Big-O analysis of your approach before coding.
- Test with large input cases. Generate them if needed.
Mini Tip:
If your code runs in over a second for a large input, it’s probably not efficient enough. Optimize before the grader proves it for you.
Trap 4: Ignoring Function Signature Requirements
You might write the perfect solution, but when you hit submit, the grader crashes. Or worse, you get zero marks with little to no feedback at all.
One of the most common (and very annoying) causes is that you changed something you weren’t supposed to, like renaming the function or editing a portion of the boilerplate code.
Many online platforms provide a predefined function signature like def solve(): or def isValid(s: str) -> bool:. The grader calls that exact function behind the scenes. If you rename it, add parameters, or tweak the return type, then the grader won’t know how to run your code.
Even if your logic is flawless, it won’t really matter; the system just skips your function or throws a runtime error.
Your Check:
- Don’t rename the function, or modify the parameter list, or the return type unless the problem statement explicitly says you can.
- Only write your code inside the provided function body.
Mini Tip:
Think of the function signature as the contract between you and the grader. If you change it, it won’t know how to proceed.
Trap 5: Uncaught Edge Cases in Logic
Your code runs. It passes the sample inputs. You’re confident and now it’s definitely correct. But then hidden test cases fail, what else could go wrong at this point ?
This usually means you missed an edge case.
Edge cases are the weird, rare, or extreme inputs that break otherwise “working” logic. Maybe you didn’t handle an empty array. Or a string with just one character. Or a zero that slipped into a division. These aren’t bugs, they’re oversights.
And graders are designed to catch them.
Your Checks:
- Ask yourself: “What’s the weirdest version of this input I could get?”
- Think of:
1. Empty inputs ([], “”)
2. Repeated elements
3. Max/min values
4. Unexpected but valid edge conditions - Write quick test cases just to stress-test logic paths you don’t usually hit.
Mini Tip:
Use assert statements in your test code to make sure your assumptions hold. Failing fast is better than failing silently.
Quick Checklist Before You Submit
Before you hit the final “Submit” button, run through this list. It takes less than a minute, and it can save you a ton of points.
- Tested beyond the samples?
Don’t just rely on the given test cases. Run your code with edge inputs, empty data, max values, and weird edge formats. - Output formatting matches exactly?
Double-check spacing, newlines, and capitalization. If the prompt says “YES”, printing “Yes” will fail. Don’t assume the grader is forgiving. - Code runs within time and memory limits?
Glance at the input constraints and ask: “Is my solution fast enough?” If you’re pushing O(n²) on large data, rethink it. - Boilerplate untouched?
Didn’t rename the function? Didn’t change the parameter list? Good. If the grader can’t call your code, it won’t grade it. - Edge cases covered?
Did you think through weird inputs like empty arrays, large numbers, weird patterns? Cover the blind spots before they catch you.
Take the extra minute. It’s the difference between a pass and a head-scratcher.
Wrap up
A lot of students think they lost marks because their code was “wrong.” But more often, it’s because they didn’t think like the grader.
These traps don’t show up in your IDE. They show up in how online judges check your work with strict rules, hidden tests, and zero tolerance for ambiguity.
The good news? Once you know what to look for, these issues are easy to avoid. It’s not about writing more code, it’s about writing smarter.
So, next time you tackle a coding problem, just run through the checklist once before you submit. You’ll catch mistakes earlier, lose fewer marks, and spend less time guessing & finding what went wrong.
It’s a very small shift in mindset and it makes quite a big difference in the results.
