A student submits a binary search. It handles sorted input, duplicates, the first element, the last element and a single-element array. It crashes on an empty array.
What is that worth?
On a hiring platform the answer is usually zero. The submission failed the suite, the candidate does not advance, and that is the correct answer to the question being asked. In a course it should be seven marks out of eight, with a note attached that says edge cases - because that is the one thing this student has not learned, and it is a teachable thing.
Both answers are right. They answer different questions, and the distance between them is why a coding test built for recruitment behaves strangely in a classroom.
Similar machinery, opposite purpose
Similarly to HackerRank and CoderPad, an education platform compiles submitted code in a sandbox, runs it against test cases, enforces a time limit, and compares output. The machinery is not where these tools differ.
The difference is what happens after. HackerRank was built primarily for technical hiring and CoderPad for live interviewing, and both are good at the job they were designed for. That job ends with a decision about one person on one day: advance, or do not. Once the decision is made, the submission has done its work.
Teaching does not end. The same student writes code again next week, and for the twelve weeks after that. A course does not need a verdict on a submission. It needs a position on a curve - and it needs the curve.
One question, thirty students
Take that binary search question and give it to a class of thirty. Eight test cases, one mark each. Here is what actually comes back in a first-year class, and what two scoring rules make of it.
| What the student wrote | Students | Test cases passed | All-or-nothing | Per test case |
|---|---|---|---|---|
| Correct throughout | 9 | 8 of 8 | 100% | 100% |
| Correct, but crashes on an empty array | 12 | 7 of 8 | 0% | 87.5% |
| Linear scan, times out on large input | 5 | 2 of 8 | 0% | 25% |
| Nothing submitted | 4 | 0 of 8 | 0% | 0% |
| Class average | 30 | — | 30.0% | 69.2% |
The averages differ by 39 percentage points on identical submissions. That is worth noticing, but it is not the important part.
The important part is the second column from the right. Under all-or-nothing scoring, twenty-one students share the same score. A student who wrote a correct binary search and forgot one guard clause is recorded identically to a student who submitted an empty file.
For hiring that is not a flaw. Both candidates are a no-hire this week, and the platform is not wrong to say so. For teaching it destroys the only information the assessment produced. Those twenty-one students need three different interventions, and the mark sheet says they need the same one.
What the same data looks like when it is kept
Score the same submissions per test case and the class splits into groups a teacher can act on:
- Nine students have the concept and the edge cases. They need harder problems, not another lesson on binary search.
- Twelve students have the algorithm and not the defensive habit. This is one demonstration, five minutes, on what an empty input does to a loop that assumes a first element.
- Five students have not understood the algorithm at all and reached for a linear scan. This is a different lesson entirely, and giving them the edge-case demonstration would waste their week.
- Four students did not submit, which is not an academic problem yet. It is an attendance or a confidence problem, and it is the one a teacher should chase first.
Same code, same test cases, same sandbox. The only difference is whether the platform threw the detail away after deciding pass or fail.
The second thing hiring tools do not need: last week
A recruitment platform has no reason to remember that this candidate also sat a test in March. Each assessment stands alone, because each hiring decision stands alone.
A course is the opposite. The question a teacher actually has in week nine is not how did this student do. It is:
- Is this student improving, flat, or sliding?
- Is the class weak on recursion specifically, or on everything?
- Did the students who struggled with loops in week three struggle with recursion in week eight, or did those two groups barely overlap?
- Which questions did most of the class get wrong - and was that the students, or was it a badly worded question?
None of those can be answered from one submission, however precisely it was scored. They need every submission from every student mapped to the topic it tested and kept in one record. That is a different shape of system from one that produces a hiring signal, and it is not a feature that can be bolted on afterwards - it depends on the per-question detail being retained from the first week of term.
The question-quality half of it
There is a version of this that catches teachers out. If 26 of 30 students fail one question and pass everything around it, the likeliest explanation is not that the class collectively forgot one topic. It is that the question was ambiguous, or the expected output had a stray newline, or the time limit was set for a compiled language and half the class writes Python.
A platform that keeps per-question outcomes across a term can show that pattern. A platform that records pass or fail cannot, because a bad question and a hard topic look identical in a column of zeroes.
What to ask a coding assessment tool, if the use is teaching
- Is partial credit per test case available, and is it visible to the student? Seven of eight is a different conversation from a zero, and the student should be able to see which one failed.
- Are hidden test cases separated from visible ones? Students need enough feedback to debug and not enough to hard-code the answer.
- Is each question mapped to a topic? Without it there is no way to say the class is weak on recursion - only that it is weak.
- Does one student have one record across the whole term? Fourteen separate result screens are not a record.
- Can a teacher see which questions the class got wrong, across attempts? That is the only route to fixing the paper rather than blaming the cohort.
- Do written and multiple-choice questions live in the same assessment? A programming course is not only programming, and splitting the paper across two systems splits the record too.
A hiring platform will answer well on the first two and has no reason to answer the rest, because none of them are its job.
Use each for what it is
None of this makes HackerRank or CoderPad worse tools. If the task is screening two hundred applicants for one role, a purpose-built hiring platform will do it better than any assessment system meant for a classroom, and the all-or-nothing rubric that loses so much information in a course is exactly the right rubric when the output is a shortlist.
The mistake is only in the substitution: reaching for a hiring tool because it also runs code, and then discovering in week nine that a term of submissions produced a column of scores and nothing that says what to teach next.
Teemly evaluates coding questions against visible and hidden test cases and records the outcome per case, so a submission that passes seven of eight is stored as seven of eight rather than as a failure. Questions carry topics and learning outcomes, so results roll up by topic across a term instead of stopping at a score, and question-level history makes a question that most of a class got wrong visible as a question rather than as a weak cohort. If you are choosing between platforms, our guide to what makes a good coding assessment platform covers the evaluation in more depth, and choosing a coding assessment platform for bootcamps covers the case where the cohort turns over every few months. You can see how the scoring works on our coding assessment software page.