Three days left. Paper 2 tests whether you can actually think like a programmer on paper: trace tables, pseudocode, SQL, logic gates and writing your own algorithms. These are the questions students revise least and lose the most marks on. Here's the order that fixes that.
One focus per day, building to a timed run. Work it in order.
Ranked from analysed past papers. Start at the top: if you run out of time, you will have covered the most-tested ground.
The single highest-scoring topic on this paper across every analysed session, often reaching 9-10 marks. Syntax vs logic error definitions, debugging given code, and identifying normal/boundary/erroneous test data all come up together.
Appears in every session analysed, frequently worth 6+ marks in a full 'write an algorithm' question: FOR loops for a known number of repeats, WHILE loops for condition-controlled repeats.
Tested in most sessions and worth up to 20 marks across a series. Drawing flowcharts and writing pseudocode both require exam-board syntax, not general programming knowledge.
The most consistently tested construct. Appears across constructs questions, flowcharts, debugging and full algorithm-writing tasks, often totalling close to 20 marks in a series.
Appeared in every single session analysed: you're given code and asked to track variable values line by line. A missing column or a skipped row is the single most common way students lose marks here.
Appears in every analysed session, usually 3-4 marks, and is one of the most commonly skipped questions on the whole exam. The SELECT/FROM/WHERE pattern is quick to learn and reliable marks nobody else claims.
Consistently worth 10+ marks across sessions. Know all five validation types (range, length, type, presence, format) and be able to write pseudocode that applies them, not just name them.
Recently the single biggest allocation seen for this topic (6 marks): string functions like length, upper/lower case, substring and concatenation, plus predicting code output.
PrepWise has a one-page Knowledge Organiser for every topic above. In your final 3 days, use them the same way each time: cover the page, try to recall everything from memory, uncover and check what you missed, then repeat that topic again tomorrow.
Rules specific to Paper 2. On this paper, structure earns as many marks as knowledge.
When the question says 'write an algorithm' or 'write pseudocode', use OCR's conventions (INPUT, OUTPUT, IF/ENDIF, FOR/NEXT). Python-only syntax like print() or colons-and-indentation-only blocks can lose you marks even when the logic is correct. The mark scheme checks for structure, not a specific language.
Rule off one column per variable named in the code, plus an output column if there's an OUTPUT statement. Every row is one line of code executed. If a variable doesn't change on a line, repeat its current value rather than leaving the cell blank. A skipped column is the most common reason full marks are missed here.
SELECT [the fields you want] FROM [the table name] WHERE [the condition]. Read the question for the exact field and table names given: don't invent your own. This question is worth learning by heart since so many students leave it blank.
When converting binary to denary, place values are 128, 64, 32, 16, 8, 4, 2, 1 from left to right. Add up the columns where there's a 1. Working left to right instead of matching place values to position is the single most common conversion error.
A 6-mark 'write an algorithm' question typically awards marks for using the right construct (loop, selection), the right variable initialisation, and correct logic that solves the actual problem. Getting the syntax right but solving the wrong problem still loses most of the marks, so read the scenario twice before you start writing.
The errors examiners see most on this paper. Each one is an easy mark you already know how to keep.
Writing real Python code instead of pseudocode when pseudocode is asked for → Use OCR's pseudocode keywords (INPUT, OUTPUT, IF/THEN/ENDIF, FOR/NEXT, WHILE/ENDWHILE) even if you normally code in Python. The mark scheme rewards algorithmic structure in the board's format, not language-specific syntax.
Missing a variable column in a trace table → Before you start, list every variable named in the code and give each one its own column, including any that only appear partway through. A trace table with a missing column will have systematically wrong values for the rest of the trace.
Converting binary to denary right to left instead of matching place values → Line up each bit with its correct place value (128, 64, 32, 16, 8, 4, 2, 1) before adding, rather than just reading the digits in order. Double-check by re-adding your final total.
Giving vague definitions like 'it makes the code better' or 'it makes it faster' → Every definition needs a mechanism. For a syntax error, say the code breaks the rules of the language and won't run. For a logic error, say the code runs but produces the wrong result. Vague, outcome-only answers score zero.
Naming a sorting or searching algorithm without being able to perform it → Knowing that bubble sort 'compares adjacent items and swaps them' isn't enough if the question gives you a data set and asks you to demonstrate a pass. Practise actually working through bubble sort, insertion sort, merge sort and binary search on paper, not just describing them.
The 60 minutes before you walk in. Review what you know and settle your nerves.
Trace tables and SQL only click once you have done a few. Practise exam-style Computer Science questions in PrepWise, get marked instantly, and stop skipping the topics that carry easy marks.
Open the Computer Science Knowledge Organisers, quiz every priority topic and walk in ready. Free during alpha.
Get started with your personalised revision