How to Answer Trace Table and Algorithm Questions in IGCSE Computer Science Paper 2

For Cambridge IGCSE Computer Science (0478) in 2026–2028, Paper 2 directly tests whether you can dry-run algorithms, complete trace tables, identify and correct logic errors, and write or amend algorithms. The syllabus is unusually explicit about precision: trace tables may require variables, outputs and user prompts to be recorded at each step, and algorithm-writing answers must use formal pseudocode rather than vague English in most coding questions. The safest exam strategy is to treat every algorithm literally. Do not predict what you think it is meant to do. Execute each line in order, update values only when the code changes them, and record the state carefully.

Paper 2 in the 2026–2028 syllabus

Paper 2 is Algorithms, Programming and Logic. It lasts 1 hour 45 minutes, is worth 75 marks and contributes 50% of the qualification. The questions cover Topics 7–10 and include short-answer and structured questions plus a final 15-mark unseen scenario. Calculators are not allowed. Cambridge says practical programming experience is required and that, for ordinary Paper 2 coding questions, solutions must be written in the syllabus pseudocode format: program code does not earn marks there. The exception is the final 15-mark scenario, where candidates may use pseudocode or Python, Visual Basic or Java. This distinction matters when you practise algorithm-writing.

The final scenario has different representation rules from ordinary Paper 2 coding questions.

What a trace table is actually testing

A trace table tests whether you can execute an algorithm exactly, step by step. The syllabus defines it as documenting a dry-run and specifically notes that variables, outputs and user prompts can all matter. That means the task is not only “what is the final output?” A question may expect you to track a loop counter, an accumulator, a flag, a value read from an array, a prompt shown to the user or several outputs produced at different stages. Read the table headings before you start because they tell you which parts of the program state the examiner wants recorded.

Use one-line-at-a-time discipline

The most reliable trace method is mechanical. Read one statement. Decide whether it changes a variable, tests a condition, enters or exits a loop, accepts input or produces output. Update the table only when something relevant changes. Then move to the next executable line. This prevents a common mistake: mentally jumping ahead to what the algorithm will eventually do and writing a value before the code has actually produced it. Nested conditions and loops look difficult when you view the whole block at once; they become manageable when you execute one line at a time.

Click to enlarge

Initial values matter

Before the first iteration, identify every variable that has already been initialised. Accumulators may begin at 0; counters may begin at 1; Boolean flags may begin as TRUE or FALSE; maximum and minimum variables may be set from an input or an array element. Do not invent a starting value. A wrong initial state contaminates every later row and can also hide the real source of a debugging error.

Loops: avoid the off-by-one mistake

For a FOR loop, write down the first and last values of the loop variable and remember that the body executes once for each permitted value. For WHILE and REPEAT loops, pay attention to when the condition is tested. A WHILE loop can execute zero times if its condition is false immediately; a REPEAT loop executes the body before testing its stopping condition. Off-by-one errors happen when students increment the counter at the wrong moment, stop one iteration early or perform one extra iteration after the condition should have ended the loop. Trace the condition exactly where the algorithm tests it.

Conditions: take the branch the code gives you

At an IF statement, evaluate the condition using the current values. If it is true, execute the correct branch; if false, skip it or use ELSE where present. In nested conditions, finish the inner decision before returning to the outer structure. Marking the truth value beside a condition in rough working can prevent you from following a branch that never executed.

An original trace-table example

In the example below, the algorithm reads four numbers and adds only the even ones to Total. The input values are 3, 6, 5 and 2. The key is that Total changes only on iterations where Number MOD 2 = 0, but OUTPUT happens on every iteration. That is why the recorded outputs are 0, 6, 6 and 8. Notice that the odd inputs still belong in the trace table even though they do not change the accumulator. The algorithm read them, the condition evaluated them and the output statement still executed afterwards.

Click to enlarge

Trace tables are not just about output

The current syllabus guidance explicitly includes variables, outputs and user prompts in the information that can be recorded at each step. If a question supplies a trace table with columns for multiple variables, do not fill only the output column. Likewise, a value can stay unchanged for several rows without becoming irrelevant. A stale-variable error occurs when a candidate accidentally reuses an older value after the algorithm has updated it, or changes a value that the code never changed. Let the program state, not intuition, decide what goes into each cell.

Algorithm writing: precision beats conversational English

Cambridge states that precision is required when writing algorithms. The syllabus even contrasts a formal condition such as x > y with a sentence such as “x is greater than y”, which is not accepted as algorithm notation. For the 2026–2028 structure, use the pseudocode conventions in the syllabus: assignments, IF statements, loops, arrays, procedures and functions should be expressed in a form the examiner can execute. The goal is not perfect programming-language syntax. In fact, Cambridge says logic is more important than syntax. But that is different from writing an informal paragraph describing what the program should do.

Debugging questions: find the fault, then correct it

When a question asks you to identify an error in an algorithm, separate the two jobs. First state what the logic does incorrectly. Then show the correction. For example, an algorithm intended to find the highest score is wrong if it updates Highest when Score < Highest. Saying “the IF is wrong” is too vague; saying that the comparison is reversed and should test Score > Highest directly addresses the fault. Also inspect initial values, loop bounds, array indices, conditions and update statements because a small error in any of them can change the entire result.

Click to enlarge

Writing a new algorithm: build it from inputs, process and outputs

Before writing pseudocode, identify the inputs, processing and required outputs. Then choose the structures needed: sequence, selection, iteration, arrays, validation or procedures. For longer questions, write the control-flow skeleton first and fill in detail after it is sound. This is safer than writing from line one with no plan, because the biggest losses usually come from logic errors rather than syntax.

The 15-mark scenario is different

The final Paper 2 question is a 15-mark unseen scenario, and Cambridge expects roughly 30 minutes for it. Unlike ordinary coding items, this question allows pseudocode or one of three named programming languages: Python, Visual Basic or Java. The method still needs to solve the scenario accurately, but the permitted representation is broader. Do not transfer that freedom to the rest of Paper 2. Outside this scenario, where the solution involves coding, Cambridge's 2026–2028 guidance requires pseudocode and says solutions written in programming code will not receive marks.

Common mistakes to eliminate in practice

The most common trace-table problems are predictable: starting with the wrong initial value, skipping an iteration, changing a variable in the wrong branch, forgetting that a variable keeps its previous value until reassigned, and recording only the final output. Algorithm answers often fail because they describe the idea in English but never express executable logic, use the wrong loop limits or update the wrong variable. After practice, identify the error category so you can target it again.

A 2029 warning

This article applies to the 2026–2028 syllabus. Cambridge has already published a substantially revised 2029–2031 course. From 2029, pseudocode is removed from teaching and assessment, Python 3 becomes the only programming language, the final scenario-based question is replaced by a redesigned structured question, and calculators are allowed on Paper 2. The tracing and debugging habits remain useful, but the assessment format changes. For the current exam, the safest rule is simple: trace state literally, write precise logic and follow the permitted 2026–2028 notation.