How to turn a written algorithm into IGCSE Computer Science Paper 1

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.

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.

Comments are not a formal requirement of IGCSE Computer Science pseudocode, but a one-line comment at the top of a non-trivial algorithm — `# find the largest of N numbers entered` — is a free insurance policy. If the marker is in a hurry, the comment is what they read first. If your pseudocode has a small bug, a clear comment can be the difference between "algorithm is wrong" and "algorithm is correct but the output line has a typo".

Common pitfalls and how to avoid them on IGCSE Computer Science Paper 2

Candidates lose marks on the IGCSE Computer Science algorithm question in patterns, not randomly. The patterns are predictable, and each one has a specific defensive habit that closes it down.

The first pattern is incomplete input/output. The scenario says "the user enters a number", and the pseudocode begins with `SET n = 0` instead of `INPUT n`. The fix is mechanical: every algorithm begins with INPUT, and every algorithm ends with OUTPUT. Train yourself to write the INPUT and OUTPUT lines first, before the processing, and the issue vanishes.

The second pattern is loop boundary errors. A `WHILE count < 10` loop runs while `count` is 0 through 9, which is 10 iterations, not 9. A `FOR i FROM 1 TO 10` loop runs 10 iterations. Candidates mix these up. The fix is to trace the boundary values explicitly during revision: write down the value of the loop counter on the iteration before the loop ends, on the last iteration, and on the iteration after. If you cannot tell which iteration is the last one, you have not internalised the boundary.

The third pattern is missing ELSE. The scenario says "if the password is correct, log the user in; otherwise, display an error". The pseudocode says `IF password = stored THEN PRINT "Logged in"` and stops. The fix is a single rule: if the scenario has the word "otherwise" in it, you have an ELSE branch. Always write both.

The fourth pattern is arithmetic on the wrong type. A scenario asks for the average of N numbers, and the candidate writes integer division where the marker expected real division. The fix is to declare the variable as REAL or FLOAT at the top, or to multiply by 1.0 before dividing. Both moves are accepted by IGCSE Computer Science markers and remove the ambiguity.

The fifth pattern is assumed libraries. The candidate's pseudocode calls a function that does not exist in the standard pseudocode library — `SORT(myArray)` for example, or `MAX(a, b)`. The fix is to write the sort or the max explicitly. The IGCSE Computer Science mark scheme does not credit assumed library calls unless the question has explicitly provided them.

A four-week revision plan that protects the 9 boundary on IGCSE Computer Science

A focused plan for IGCSE Computer Science Paper 2 should run roughly four weeks for a candidate working around 5 to 7 hours per week outside class. The plan below is a tutor's plan, not a textbook plan — it sequences work in the order that produces marks fastest, not the order that follows the textbook chapters.

Week 1 is vocabulary and format. Re-write the published pseudocode keyword list from memory. Re-write the flowchart shape vocabulary from memory. Take one past Paper 2 and produce a worked pseudocode solution for the algorithm question, paying attention only to the keywords and the indentation. Do not worry about correctness yet.

Week 2 is trace tables in isolation. Pick 10 short pseudocode snippets from past papers and trace each one, drawing the table first, then filling it in. Score yourself against the published mark scheme. The goal is to reach 9 or 10 out of 10 within the week. Trace tables are a trainable skill, and the trainability shows up fast.

Week 3 is algorithm construction under timed conditions. One past Paper 2 algorithm question, 25 minutes, no notes. Mark strictly. Repeat three to four times across the week. The goal is to internalise the 90-second scenario read, the INPUT/OUTPUT skeleton, and the boundary check on the loop. By the end of week 3 the algorithm question should be a routine, not an event.

Week 4 is full paper simulation. One full past Paper 2, timed, under exam conditions. Mark, then spend 90 minutes on the questions where marks were lost. The pattern of lost marks is itself diagnostic: if you keep losing the same mark in the same kind of question, the week 4 simulation has done its job, because you now know exactly what to fix.

What to do in the final 48 hours

Re-read the pseudocode keyword list. Re-read the flowchart shape vocabulary. Do one trace table for confidence. Do not attempt new question types in the last 48 hours — the cost of a failed attempt on the eve of the exam is higher than the benefit of a small gain. Sleep is the highest-mark activity available in the last 48 hours of IGCSE Computer Science revision.

From Paper 2 back to Paper 1: how the algorithm strand connects to theory marks

Paper 1 of IGCSE Computer Science tests the theory that the algorithm strand depends on: binary, denary, hexadecimal conversion; logic gates; data representation; and the structure of the CPU. The two papers are not separate subjects, and a candidate who revises them in silos leaves marks on both.

Number-base conversion is the clearest example. The algorithm for converting denary to binary — divide by 2, record the remainder, repeat until the quotient is 0, then read the remainders in reverse — is a Paper 1 question (it is testing the result) and a Paper 2 skill (it is testing whether you can implement the algorithm). A candidate who has only practised the calculation in isolation often cannot write the pseudocode. A candidate who has practised the pseudocode rarely gets the calculation wrong. The skill and the knowledge reinforce each other.

The same logic applies to Boolean logic. A Paper 1 question might give a truth table and ask for the Boolean expression. A Paper 2 question might ask for an algorithm that evaluates a Boolean expression. The candidate who can write the expression as `IF (age >= 18) AND (hasID = TRUE) THEN …` is the candidate who can also answer the truth-table question. Teach the two as a single topic, not two separate topics.

Data representation — how characters are stored, how images are stored, how sound is sampled — connects to algorithms through file size calculations. The IGCSE Computer Science mark scheme regularly asks candidates to combine the two: "a 10-second sound clip is sampled at 44.1 kHz with 16-bit samples. Calculate the file size." The arithmetic is a Paper 1 calculation; the algorithm that performs the same calculation in pseudocode is a Paper 2 skill. Practise both.

Conclusion and next steps

IGCSE Computer Science Paper 2 is won in the algorithm question and protected by the trace table. Candidates who lock down the pseudocode vocabulary, the input/output skeleton, the loop boundary check, and the line-by-line tracing habit are within reach of the 9 boundary before they have memorised a single line of theory. A four-week plan that sequences vocabulary, tracing, timed construction, and full-paper simulation is enough for most candidates to convert a 6 or 7 into an 8 or 9.

TestPrep Europe's IGCSE Computer Science diagnostic is a natural starting point for candidates who want a paper-by-paper breakdown of where their marks are currently being lost and a personalised plan for the weeks between now and the exam.

Frequently asked questions