Every year, students hand in A-Level Computer Science coursework (the NEA) with genuinely working, well-built code and come away with a disappointing mark. The code isn’t usually the problem. The write-up is.
The write-up is marked as evidence of a process, not a description of a result
A common mistake is treating the write-up as documentation for the finished program: “here’s what it does, here’s how to use it.” That’s not what’s being assessed. The mark scheme is looking for evidence of a process — design decisions actually being made and justified, problems actually being hit and debugged, alternative approaches actually being weighed up. A write-up that only describes the finished, working version makes all of that invisible, even if it genuinely happened during development.
What examiners are actually looking for
- Design decisions with reasoning, not just a diagram. “I used a dictionary here because lookups needed to be fast and the keys are unique” earns marks; a data structure diagram with no explanation doesn’t.
- Real testing evidence, including things that failed. A table showing only passing test cases looks suspicious to an examiner who knows real development always has failures along the way; showing a test that failed, why it failed, and how it was fixed is stronger evidence of genuine understanding.
- Evaluation against the original objectives, specifically — not a general “I think it went well,” but checking each stated requirement against what was actually built.
Why this gets missed
Students doing the actual coding work are, reasonably, focused on making the program work. Nobody keeps a running log of every design decision and dead end while deep in solving a bug. By the time the write-up gets written, weeks later, most of that process has been forgotten — so the write-up ends up being a tidy afterward-the-fact description instead of a real account of the process, and loses marks for exactly that reason.
The mark scheme rewards the messy real process - the decisions, the dead ends, the fixes. A tidy write-up of only the finished version accidentally erases the exact evidence it’s being marked on.
The practical fix
Keeping a short running log — a few lines each session on what was tried, what broke, and why a decision was made — turns the write-up into transcription rather than reconstruction. This is also exactly the kind of structural habit a tutor familiar with the NEA mark scheme can set up early, well before the deadline crunch makes it too late to capture.
If coursework marks keep coming back lower than the code quality seems to deserve, the write-up process — not the programming ability — is the more likely place to focus revision time.
Try it yourself
Open your current NEA code and pick one data structure or design choice you made. Write a 3-sentence justification for it as if explaining it to your examiner.
Show the worked approach
- State what you chose (e.g. a dictionary/hash map for a particular lookup).
- State the alternative you could have used instead (e.g. a list with linear search).
- Explain, in terms of the actual requirement, why your choice was better - faster lookups, clearer code, less memory, matching how the data is naturally structured.
What to focus on: Comparing your choice against a real alternative, not just describing what you did - the comparison is what shows genuine reasoning rather than the first idea that came to mind.
Common mistake: Writing a description of the finished structure with no justification at all ("I used a dictionary to store the data") - that's documentation, not the evidenced reasoning the mark scheme is actually looking for.
Frequently asked questions
How much of the NEA mark is actually the write-up versus the code?
It varies by exam board, but the write-up (analysis, design, testing, evaluation) typically carries as much weight as the working program itself, sometimes more - a technically impressive program with a thin write-up routinely scores lower than a simpler program documented properly.
When should I start keeping the running log mentioned below?
From the very first session, before you've written a single line of final code. The earliest design decisions (why this data structure, why this approach) are exactly the ones that get forgotten first, and they're often the most markable.
Do I need to include failed attempts in my testing section?
Yes - a test table showing only passing tests looks incomplete to an examiner who knows real development involves failures. Showing a test that failed, your diagnosis of why, and the fix demonstrates genuine understanding more convincingly than a clean table ever can.
What if my project changed direction partway through?
Document that change and why you made it - a design decision that was later revised, with reasoning for the revision, is stronger evidence of real engineering judgement than pretending the final design was the plan all along.
Ready to find a Computer Science tutor?
Browse Computer Science tutors →