IGCSE Computer Science rewards a specific kind of disciplined thinking: the ability to turn a fuzzy human description of a process into a step-by-step algorithm that a marker can credit line by line. Across both Cambridge and Edexcel variants of the IGCSE Computer Science specification, the algorithm and programming strand is where most candidates leak marks — not because the ideas are hard, but because the marking schemes reward structure, naming, and traceability more than they reward cleverness. This article walks through the mechanics of writing pseudocode, drawing flowcharts, and completing trace tables under timed conditions, then builds a revision plan that targets the marks Paper 2 typically awards for problem-solving.
Why the algorithm question is the centre of gravity on IGCSE Computer Science Paper 2
Paper 2 of IGCSE Computer Science is, in most variants, a problem-solving paper where the candidate is asked to read a scenario, identify a logical process, and produce either pseudocode or a flowchart that performs the task. The question is usually worth between 12 and 20 marks depending on the board and tier, and it is the single largest block of marks on the paper. Treat that as strategic information: if you can lock down the algorithm question, you have already protected a meaningful slice of the grade boundary.
Markers for IGCSE Computer Science do not reward exotic syntax. They reward three things: explicit input and output, sensible variable names, and a control flow that handles every case the scenario describes. A candidate who writes `IF score >= 50 THEN PRINT "Pass"` loses marks if the scenario said "print 'Pass' for scores of 50 or more, otherwise print 'Resit'" — because the alternative branch is missing. Markers look for completeness, not elegance. In my experience the most common reason an otherwise strong candidate drops to a 6 or 7 instead of an 8 or 9 is a single missing ELSE, a single uninitialised variable, or a single line of pseudocode that quietly assumes an input that the marker was told to provide.
Paper 2 also tends to bundle the algorithm question with one or two follow-ups: a trace table to test the algorithm on given data, a dry-run check, or a state the output question. The mark allocation for these is smaller, often 3 to 6 marks, but the marks are essentially free if your pseudocode is correct and your trace table is consistent. Candidates who run out of time on the algorithm question tend to lose these bundled marks as a side effect, which compounds the cost of getting stuck.
Reading the scenario before writing a single line of pseudocode
The fastest way to lose marks on the IGCSE Computer Science algorithm question is to read the scenario, decide you understand it, and start typing. The scenario is written to be slightly ambiguous on a first read, and the ambiguity is part of the test. Take 90 seconds to do three things before you write any pseudocode: identify the inputs, identify the outputs, and identify the decision points. Inputs are usually verbs like "enter", "input", or "type"; outputs are "display", "print", or "show"; decision points are signposted by "if", "otherwise", "depending on", or by conditional phrases inside the scenario.
After this quick read, write a single-sentence English summary of what the algorithm does. For example: "Read three numbers, find the largest, and print it." This is your contract with the marker. Every line of pseudocode you write afterwards should be justifiable in terms of that sentence. If a line does not serve the sentence, it does not earn marks. If a step from the sentence is not represented in your pseudocode, you have a guaranteed mark loss.
Some scenarios also include negative cases — empty inputs, out-of-range values, or invalid data. The IGCSE Computer Science mark scheme typically rewards candidates who handle these explicitly, even if the candidate's first instinct was to ignore them. A line like `IF age < 0 THEN PRINT "Invalid"` is worth a mark in its own right. I would rather see a candidate spend 30 seconds writing a defensive check than 30 seconds adding a clever optimisation that the marker is not required to credit.
The standard pseudocode vocabulary the marker expects
Cambridge's IGCSE Computer Science pseudocode guide, and the equivalent Edexcel document, both use a small, fixed set of keywords. Stick to them:
- INPUT and OUTPUT (or PRINT) for I/O.
- IF … THEN … ELSE … ENDIF for selection.
- WHILE … DO … ENDWHILE and REPEAT … UNTIL for iteration.
- FOR … FROM … TO … STEP … NEXT for counted loops.
- SET or ← for assignment.
- FUNCTION … RETURN for subroutines, on Cambridge; Edexcel often uses PROCEDURE for subroutines and FUNCTION for value-returning blocks.
Using language outside this vocabulary is a risk. A marker may still credit a clear `cin >> x` or `print(x)` line on an IGCSE Computer Science paper, but they are not required to. If you stay inside the published keyword set, you are removing ambiguity for the marker, and ambiguity costs marks. Candidates who have learned Python or Java syntax often need a deliberate translation step in their head — `if x > 0:` becomes `IF x > 0 THEN`, with the ENDIF inserted on its own line. That translation step is worth practising, because under timed conditions it is the place where the Python-trained student accidentally writes Python pseudocode and loses a mark they cannot recover.
Flowcharts versus pseudocode: when each one earns more marks
The IGCSE Computer Science algorithm question on Paper 2 typically asks for one or the other, not both. You do not get to choose on the day. But you should know the trade-offs, because exam boards occasionally offer the choice in a part-question, and because the way you revise differs.
Pseudocode is faster to write under exam conditions. A correct pseudocode solution to a typical "find the largest of N numbers" problem fits in roughly 12 lines. A flowchart of the same algorithm uses at least 9 shapes and requires the candidate to draw connectors, label arrows, and keep the geometry clean. For most candidates, pseudocode is the higher-mark-per-minute option. The exception is algorithms dominated by simple conditional branching, where a flowchart can be drawn faster than the equivalent pseudocode can be written and indented.
Flowcharts are also less forgiving of errors. A single broken arrow, a missing label on a decision diamond, or an ambiguous YES/NO branch can cost several marks because the mark scheme is tied to specific shapes. Pseudocode, by contrast, is partially credit-friendly: a marker can usually award 1 mark for input, 1 mark for the loop, 1 mark for the comparison, even if the final output line is wrong. If you are working under time pressure, the partial-credit profile of pseudocode usually beats the geometric precision required by flowcharts.
| Aspect | Pseudocode | Flowchart |
|---|---|---|
| Speed to write under timed conditions | Higher — typed or hand-written in plain text | Lower — every shape must be drawn and labelled |
| Robustness to small errors | High — partial credit available line by line | Low — one broken connector can void several marks |
| Best for counted loops | FOR … NEXT is concise and clear | Loop-back arrows are easy to misdraw |
| Best for simple selection | IF … ELSE … ENDIF is readable | Decision diamond is fast and unambiguous |
| Risk of syntax marks lost | Low if you stick to the published keyword set | Low if you know the shape vocabulary |
If your teacher has drilled both, sit a single past paper where you force yourself to use only the format you find harder. The format you avoid is the format that will cost you marks under stress, and stress is what Paper 2 is testing.
Trace tables: the 3-mark question that almost every candidate under-prepares
The trace table is the silent grade-mover on IGCSE Computer Science Paper 2. It is usually worth 3 to 5 marks, and it is treated by revision plans as an afterthought because it feels mechanical. That is exactly why it leaks marks. The mechanics of tracing are not hard, but they require a specific disciplined layout, and a single missed column can cascade into a mark loss for every dependent line.
Set up your trace table before you read the algorithm. Three columns is the minimum useful layout: variable being tracked, value before the line executes, value after the line executes. For nested loops or conditional updates, you will need additional columns for the loop counter and the condition. Draw the table in pencil so you can correct values cleanly — markers are generally tolerant of pencil corrections on a trace table, but a sloppily overwritten ink answer is harder to read and easier to mis-credit.
Trace one line at a time. Read the line, identify the variables whose values change, update only those columns, and move on. Do not try to predict the next two lines — the question is testing whether you can simulate the algorithm correctly, not whether you can predict it. Candidates who get a trace table wrong almost always get it wrong for the same reason: they updated a column they were not asked to update, or they used a value from two lines later. Slow, line-by-line discipline eliminates that error class.
Common trace table mistakes and how to avoid them
- Forgetting to re-evaluate a condition at the top of a loop. In a `WHILE x < 10` loop, `x` is tested at the start of every iteration. A trace table that tests the condition once and then assumes the loop will run to completion is wrong on the iteration where `x` reaches 10.
- Confusing assignment with comparison. `SET x = x + 1` is an instruction; the trace column should hold the new value of `x`, not the expression `x + 1`.
- Missing the ELSE branch on a conditional update. If the line is `IF x > 0 THEN SET x = x - 1`, the trace table should leave `x` unchanged when the condition is false. Candidates frequently write the new value anyway.
- Losing track of which iteration of a nested loop you are on. Add a column for the outer loop counter, label every iteration row, and tick off as you go.
Practise trace tables by deliberately tracing correct algorithms and incorrect algorithms side by side. Tracing a known-bad algorithm — for example, one with an off-by-one error in a `FOR` loop bound — teaches you where to look for the error class. The IGCSE Computer Science mark scheme does not test whether you can trace, it tests whether you can trace correctly, and the difference is rehearsed pattern recognition.
Variable naming, indentation, and the quiet marks most candidates leave on the table
Variable naming is one of the most under-marked features of a strong IGCSE Computer Science answer. The mark scheme often allocates 1 mark for "appropriate variable names", and that mark is awarded or withheld based on whether a human reader can tell, without re-reading the scenario, what each variable holds. `x`, `y`, and `z` rarely earn the mark. `totalScore`, `largestSoFar`, and `attemptsRemaining` almost always do.
Indentation earns nothing in the formal mark scheme, but it is the single cheapest way to make a paper easier to mark and easier for you to debug. A candidate writing pseudocode by hand on Paper 2 should indent one level for every loop body and one level for every IF/ELSE branch. If a marker has to choose between crediting a borderline answer, they will credit the indented one. The same logic applies to arrow labels on flowcharts: a YES and NO on every decision diamond removes any ambiguity about which branch is which.