GCSE Computer Science: Why a Student Who Can Code in Class Still Struggles on the Written Exam
If your child enjoys the practical side of GCSE Computer Science and can build working programs on a computer, it can be baffling to see them come home with disappointing marks on a written paper. The code works in class. They know what a loop does. So why are they losing marks on questions that seem to ask about exactly the kind of thing they do every week?
The short answer is that the written exam tests a different skill from writing code at a computer. Both exam boards for GCSE Computer Science (AQA, OCR, Edexcel, Eduqas and WJEC) assess the subject through written papers taken with pen and paper. There is no IDE, no autocomplete, no error message pointing at line 14. Your child has to read code, trace it in their head, write it by hand, and use the specific vocabulary the mark scheme expects.
The classroom skill and the exam skill are not the same thing
When a student codes in class, they are usually doing something like this: type a few lines, run the program, see what happens, fix the bits that broke, try again. This is a perfectly good way to learn programming. It is also a very forgiving environment.
The computer catches missing colons. It flags undefined variables. The student can print values at any point to check what the program is doing. If the output looks wrong, they can tweak and rerun until it looks right.
The written exam strips all of that away. A typical paper asks the student to:
- Read a short program and state what it would output.
- Complete a trace table showing the value of each variable after each line.
- Identify an error in a given piece of code and explain how to fix it.
- Write a short algorithm in pseudocode or a specified high-level language.
- Explain, in words, what a section of code does or why it is inefficient.
None of these tasks involve running anything. The student has to simulate the computer in their own head, keep track of changing values, and produce an answer that a marker can read and credit.
Why confident coders lose marks
A few patterns come up again and again.
Tracing errors. A student who can write a for loop fluently may still miscount how many times it runs when they trace it on paper. Off-by-one mistakes, forgetting that a while condition is checked before the loop body, or losing track of a counter variable are all common. In class, the computer handles this invisibly. On paper, every step has to be written down.
Imprecise answers. "State the output" means give the exact output, including spacing, punctuation and line breaks where relevant. "The output is a list of numbers" will usually earn nothing. "Identify the error" wants the specific line or construct, not a general comment that "the loop is wrong".
Confusing languages and pseudocode. Each exam board has its own pseudocode style. OCR's reference language, AQA's pseudocode and Edexcel's conventions are not identical. A student who writes beautiful Python at a keyboard may lose marks for writing Python when the question says "use pseudocode" or "use the OCR reference language". The marker is not trying to be awkward — they are following the specification.
Syntax that does not quite work on paper. With autocomplete, a student never has to remember whether it is length or len, or whether strings use single or double quotes in a given language. On paper they do. Small slips add up.
Explanations that assume the reader can see the screen. "It prints the answer" is not an explanation of what a function does. The written exam rewards students who can describe behaviour precisely: what the inputs are, what processing happens, what is returned or displayed.
A small worked example
Consider this short piece of pseudocode:
x = 5
y = 2
WHILE x > 0
x = x - y
OUTPUT x
ENDWHILE
A student reading this quickly might say the output is 3, 1. Trace it carefully on paper and the real sequence is:
| Iteration | x before | Condition x > 0 | x after x = x - y | Output |
|---|---|---|---|---|
| 1 | 5 | true | 3 | 3 |
| 2 | 3 | true | 1 | 1 |
| 3 | 1 | true | -1 | -1 |
| 4 | -1 | false | — | — |
The output is 3, 1, -1. The loop runs one more time than many students expect, because the condition is only checked at the top. This is exactly the kind of question where a confident coder who never traces on paper slips up.
What actually helps
The good news is that written-exam performance is very trainable once you know what is being tested. Some practical things that help:
- Hand-written practice. Ask your child to put the laptop away for part of their revision and write code by hand on paper. It feels slow and awkward at first. That is the point.
- Trace tables. Working through short programs with a trace table — one column per variable, one row per line of execution — builds the mental model the exam rewards.
- Past-paper questions by command word. "State", "describe", "explain", "write", "identify", "compare" each want a different kind of answer. Working through past-paper questions and comparing answers to the mark scheme teaches a student what each command word is really asking for.
- Pseudocode in the right style. Find out which exam board your child is sitting (the school will tell you) and make sure they are practising in that board's pseudocode conventions. Most boards publish a reference document.
- Reading other people's code. Being handed an unfamiliar snippet and asked "what does this do?" is a core exam skill. It is quite different from writing your own code from scratch.
Where tutoring can make a difference
A lot of this comes down to specific, individual feedback. A student may be writing perfectly reasonable answers that still miss the mark because they are not quite answering the question that was asked. Without someone pointing out exactly where the answer fell short of the mark scheme, it is hard to improve.
This is where one-to-one tuition can be particularly useful for Computer Science. At Luminary Tutoring, Annup works through past-paper questions with students, explains why a particular phrasing earns the mark and another does not, and helps them build the habit of tracing code carefully on paper. Lessons are live and online through Microsoft Teams, one hour at a time, and are recorded so students can rewatch a tricky trace or explanation during their own revision. The free consultation is a sensible way to talk through what your child finds hardest before committing.
A useful next step
Ask your child to try one past-paper question — ideally a "state the output" or a trace-table question — on paper, without a computer. Then compare their answer to the mark scheme line by line. The gap between what they wrote and what the mark scheme wanted will usually tell you, very quickly, where the real work needs to happen.