WJEC GCSE Computer Science Revision Guide

WJEC's GCSE Computer Science (spec code 3520) is one of the exam board options in Wales and used by some centres in England. It splits the subject into two written exams plus a non-exam programming assessment, and each part rewards a different kind of revision. Treating it like a single blob of "computer science facts" is how most students waste time.

What's actually in the specification

Unit 1 covers computer systems: hardware, the fetch-decode-execute cycle, memory and storage, networks, and system software. Unit 2 covers computational thinking, algorithms and programming, which is where boolean logic, sorting algorithms (bubble sort, merge sort), and data structures like arrays and 2D arrays get tested. There's also a programming task, done in a language such as Python or VB, which builds skills but isn't directly examined the same way as the written papers.

A common mistake is spending 80% of revision time on programming because it feels more "real" and 20% on the systems unit, then losing marks on questions about bus width, cache memory, or the difference between LAN and WAN topologies. Both units carry real weight in the final grade, so split your time roughly in proportion to that.

Binary and number systems: don't skip the arithmetic

WJEC expects you to convert between binary, denary and hexadecimal by hand, and to perform binary addition and understand overflow. Practice this with pen and paper, not a calculator, because the exam won't let you use one for these questions. A typical exam question gives you an 8-bit binary number and asks for its denary and hex equivalent, or asks you to add two binary numbers and explain what happens when the result exceeds 8 bits.

Same goes for logic gates and boolean algebra. Know the truth tables for AND, OR, NOT, NAND, NOR and XOR cold, and be able to build a truth table from a logic circuit diagram. These questions are formulaic once you've drilled them, which makes them some of the easiest marks on the paper if you practice.

Algorithms: trace tables are your friend

When a question shows pseudocode or a flowchart and asks you to trace through it, use a trace table every single time, even in revision. Write out the variable names as columns and update each one line by line as the algorithm runs. Skipping this step and trying to work it out in your head is the single biggest cause of silly mistakes on algorithm questions.

For sorting and searching, you need to describe how bubble sort and merge sort work step by step, not just recognize the names. Practice writing out the process in your own words: bubble sort compares adjacent items and swaps them if they're in the wrong order, repeating passes until no swaps are needed. Being able to state that clearly, with correct terminology, is worth more than vague gesturing at