Here's the thing nobody really says out loud: algorithm questions aren't testing whether you're a genius coder. They're testing whether you can follow instructions slowly and not lose track. That's it. The people who lose marks aren't the ones who don't understand loops, they're the ones who try to hold five variables in their head at once, lose one halfway through, and write down a number that feels about right.
Computing is also a slightly smaller cohort this year: provisional entries are down a little on the last couple of summers. That's not a reason to relax, it's a reason to get the technique right, because the marks on these questions go to whoever shows their working most clearly.
Why algorithm questions feel harder than they are
Pseudocode looks intimidating because it's compact. A four-line loop can run twenty times, and twenty
rounds of mental arithmetic is exactly where things fall apart. Your brain is brilliant at lots of things;
tracking count, total and i simultaneously across twenty iterations
is not one of them. The exam isn't asking you to be a computer. It's asking you to be the paper the
computer writes on. And paper doesn't forget.
The trace-table trick, step by step
A trace table is just a grid. One column for every variable in the algorithm, plus a column for any output. One row for every time a value changes. You walk through the code line by line and write down what happens. No skipping. No "I'll just do this bit in my head."
Say the algorithm sets total to 0, then loops i from 1 to 3 adding i
to total each time. Your table gets a column for i, a column for total,
and you fill it row by row: i=1, total=1. i=2, total=3. i=3, total=6. The answer is sitting right there at the
bottom of the column. You didn't have to be clever. You had to be tidy.
The reason this works in an exam specifically is that it's visible. Even if you make a slip on the last line, the examiner can see you understood the process, and the method marks are built around exactly that. Doing it in your head gives them nothing to award if your final number is wrong.
Trap one: the off-by-one error
The classic. A loop that says FOR i = 1 TO 5 runs five times, but FOR i = 0 TO 5
runs six. People assume the count and quietly skip a row, or add one they shouldn't. Your trace
table kills this dead: you write a row for each pass, so you literally count them. If your loop bound is 5
and you've got six rows, something's wrong. Go back and check.
Trap two: checking the condition at the wrong moment
A WHILE loop checks its condition before it runs the body each time. A
REPEAT…UNTIL loop checks after, so it always runs at least once. Mix these up and you'll
either run a loop one time too many or miss the first pass entirely. When you trace, write the condition
check as its own step: "is x < 10? yes → run body." Forcing yourself to ask the question on every row
means you can't accidentally skip it.
Trap three: confusing = and == in pseudocode
In a lot of exam pseudocode, a single = means "make this equal to" (assignment), while
== means "is this equal to?" (a comparison that's either true or false). Read
x = x + 1 as "x becomes one bigger," and IF x == 5 as "if x is currently five."
When you're tracing, an assignment changes a value in your table; a comparison just decides which branch you
take. Keep those two jobs separate in your head and a whole category of silly mistakes disappears.
GCSE computer science revision tips that actually stick
Technique only sticks if you drill it on real questions, so don't just read this and nod. Pull up past-paper algorithm questions for your board and trace every single one with an actual grid, even the easy-looking ones. The goal is to make the table automatic, so that under exam pressure your hand reaches for it before your brain tries to be a hero. If you're not sure which topics are dragging you down, our guide to spotting your real weak areas is a good place to start.
A few small habits make the table even more bulletproof. Use a ruler or just draw straight columns. A messy grid is where slips creep back in. Label every column before you start tracing, not halfway through, so you're never guessing which number belongs to which variable. And cross out an old value rather than erasing it: if your final answer looks off, the crossed-out trail shows you exactly where the algorithm went somewhere you didn't expect, which is usually the difference between finding your mistake in ten seconds and rewriting the whole thing.
It's also worth tracing a couple of questions backwards once you're confident: given an output, work out what the input must have been. You won't always get asked that, but it forces you to understand what each line of the algorithm is actually doing rather than just copying values down a column. That deeper read is what stops a slightly reworded question from throwing you on the day.
One more thing worth knowing: the exact algorithm and computational-thinking content varies by exam board, so "computer science" isn't one fixed syllabus. GCSE Boss maps the algorithm spec points in your actual board's specification, so you're drilling the question types that genuinely come up for you: not a generic mix from five different boards. That's the whole idea: revise your spec, not a one-size-fits-all version of it.
The one-line version
Write the table. Track every variable, row by row. Count your loop passes, check your conditions in the right order, and keep assignment and comparison separate. Do that and the scary question on the paper turns into the most mechanical marks you'll pick up all exam. You've done the work. Now make it visible.