1. How to Answer Programming Questions
Here's the thing most students get wrong: they read a programming question, panic slightly because it "looks unfamiliar," and just start typing pseudocode hoping something sticks. That's the wrong approach — and it's exactly why marks get lost even when the student clearly understands the topic.
The examiners aren't testing whether you can memorise a program. They're testing whether you can take a real-world problem, break it into logical pieces, and express those pieces using the tools CIE has given you (sequence, selection, iteration, variables, subprograms). So instead of "starting to type," you start by interrogating the question — like a detective, not a typist.
Where do programming questions appear?
- Paper 1 — tests your ability to read, trace, and explain algorithms and pseudocode. You're not usually writing brand-new programs here — you're interpreting existing ones.
- Paper 2 — tests your ability to design, write, test, and refine programs from scratch, including one guaranteed 15-mark programming question at the end of the paper.
Why this matters
Because the two papers test different skills, your revision strategy should differ too. For Paper 1, practise reading pseudocode fluently — like reading a foreign language you're becoming bilingual in. For Paper 2, practise writing pseudocode from a blank page, which is a completely different muscle.
The language rules — non-negotiable
All programming answers must use one of these three, and only these three:
- CIE pseudocode notation — the standardised syntax defined in the CIE specification (e.g.
← for assignment, IF...THEN...ENDIF for selection)
- Structured English — plain English written in a clearly numbered, logically ordered way (used less often, but valid for some question types)
- A high-level programming language — like Python, if the question specifically allows it
Mixing your own invented syntax with CIE pseudocode is one of the fastest ways to lose marks, even if the logic is perfect. The examiner needs to recognise exactly what each line does — ambiguity costs you marks even when your thinking was correct.
The 5 Key Questions — your system for every new program
This is the single most valuable habit in this whole chapter. Before writing a single line of pseudocode for a new program, force yourself to answer these five questions on paper (even just jotting a word or two next to each one):
The 5 Key Questions
1. What are the INPUTS? → What data does the program need to receive?
2. What are the OUTPUTS? → What must the program display or return?
3. What PROCESSES take place? → What calculations/logic happen in between?
4. What CONSTRUCTS will I need? → Sequence, selection (IF), iteration (loops)?
5. Do I need SUBPROGRAMS? → Built-in functions, or my own procedures/functions?
Why does this work so well? Because it forces you to plan the shape of your answer before you commit to writing it. Think of it like a builder who marks out the foundation of a house before laying a single brick — skip that step and the walls end up crooked, even if each individual brick was laid correctly.
Worked Example — walking through the 5 questions
Original Question
The string operation SUBSTRING(Quote, Start, Number) returns a string from Quote beginning at position Start that is Number characters long. The first character in Quote is in position 1.
Write pseudocode statements to:
- store the string "Learning Never Exhausts The Mind" in Quote
- extract and display the words "The Mind" from the string
- output the original string in lower case. [5 marks]
Step-by-step reasoning:
1
Inputs: There's no user input here — the string itself is given to us. So the "input" is really just the literal string we need to store.
2
Outputs: Two outputs are needed — the extracted words "The Mind", and the original string converted to lower case.
3
Processes: We need to (a) assign a string to a variable, (b) extract a substring starting at a specific position, and (c) convert a string to lower case.
4
Constructs: Just simple sequence — one instruction after another. No loops or IF statements needed here.
5
Subprograms: Yes — two built-in string functions: SUBSTRING() and LCASE().
Working out the SUBSTRING parameters: The phrase "Learning Never Exhausts The Mind" — count the characters to find where "The Mind" starts. Position 1 is "L". Counting carefully, "The Mind" begins at character position 25, and it is 8 characters long ("The Mind" = T-h-e-space-M-i-n-d = 8 characters).
01Quote ← "Learning Never Exhausts The Mind"
02Start ← 25
03Number ← 8
04OUTPUT SUBSTRING(Quote, Start, Number)
05OUTPUT LCASE(Quote)
Why this earns full marks
Notice how every single line traces directly back to one of the three bullet points in the question. That's not a coincidence — it's what happens automatically once you've correctly identified inputs, outputs, and processes first. The pseudocode almost writes itself.
Practice Question
Try It Yourself
A program needs to ask the user for their first name and surname, then store and display their full name in UPPER CASE, joined by a space. Using the 5 key questions, identify the inputs, outputs, processes, constructs, and subprograms — then write the pseudocode.
2. How to Answer Trace Table Questions
What actually IS a trace table?
Imagine you're a computer with zero imagination and zero ability to "just know" what a program does — you can only follow instructions exactly, one at a time, in order. A trace table is the record you'd keep as you do that: every time a variable's value changes, or something gets output, you write it down in a new row.
It sounds simple, and mechanically it is — but it's also one of the easiest places to lose marks, because the skill being tested is discipline, not intelligence. A student who deeply understands loops can still get a trace table wrong by rushing, skipping a line, or forgetting that a variable resets.
Mindset shift
Don't try to trace a program "in your head" and just write down the final answer. That's a guessing strategy dressed up as understanding. Force yourself to go line by line — even lines that don't change anything are worth glancing at, because that's how you catch IF conditions being evaluated wrong.
Recognising what's being asked: Command Words
CIE trace table questions use precise command words. Each one expects a genuinely different type of answer — mixing these up (e.g. writing a full explanation when only a single value was asked for) wastes time and can even lose marks for being off-target.
| Command Word | What It Actually Means |
|---|
| Complete | Fill in the missing values in a trace table that's already partly set up for you |
| State | Give a single, direct value or result — usually just one word or one number, no explanation needed |
| Explain | Say why something happens or changes — this needs reasoning, not just a value |
| Identify | Spot where something goes wrong, or where the output doesn't match what was expected |
These questions are normally worth 3–6 marks, and they show up most often around iteration (loops), selection (IF statements), and arrays/lists — because those are the constructs where variable values actually change in interesting ways as the program runs.
The 5-Step Method for Tackling Any Trace Table
Step-by-step system
1
Read the code carefully. Understand what each line does before you touch the table. Look specifically for loops, IF statements, and any line that changes a variable.
2
Use the trace table provided. The headings and number of rows are a hint — if you're only filling 5 rows and there are 15 available, something is probably missing.
3
Work line by line. Simulate the program exactly as a computer would — no skipping ahead, no assuming.
4
Watch out for variable resets. Variables inside a loop can reset or update every single pass — never accidentally "carry over" a value from a previous iteration.
5
Show the final output clearly. If asked for output, write it exactly as it would appear on-screen — not a rough approximation.
Worked Example — Full Trace Walkthrough
Original Question
This algorithm inputs three numbers and calculates the total if they are greater than 10:
01total ← 0
02count ← 1
03WHILE count ≤ 3
04 number ← INPUT
05 IF number > 10 THEN
06 total ← total + number
07 ENDIF
08 count ← count + 1
09ENDWHILE
10OUTPUT total
Complete the trace table when the inputs are: 12, 8, 15.
Reading the code first:
- Line 1–2: total starts at 0, count starts at 1
- Lines 3–9: the loop runs while count ≤ 3 — that's exactly 3 passes
- Each pass: get a number, check if it's greater than 10, add it to total if so, then increase count by 1
- Line 10: output the final total once the loop ends
Now tracing line by line with inputs 12, 8, 15:
| Line | count | number | total | Output |
|---|
| 3 | 1 | – | 0 | – |
| 4 | 1 | 12 | 0 | – |
| 5 | 1 | 12 | 0 | – |
| 6 | 1 | 12 | 12 | – |
| 8 | 1 | 12 | 12 | – |
| 3 | 2 | – | 12 | – |
| 4 | 2 | 8 | 12 | – |
| 5 | 2 | 8 | 12 | – |
| 8 | 2 | 8 | 12 | – |
| 3 | 3 | – | 12 | – |
| 4 | 3 | 15 | 12 | – |
| 5 | 3 | 15 | 12 | – |
| 6 | 3 | 15 | 27 | – |
| 8 | 3 | 15 | 27 | – |
| 10 | – | – | 27 | 27 |
Notice what happened on pass 2
When number was 8, line 5's condition (8 > 10) was false — so line 6 never ran, and total stayed at 12. This is exactly the kind of moment where rushing leads to mistakes: it's tempting to assume every number gets added, but the IF statement is a genuine fork in the road.
Final answer: The output is 27 (12 + 15, since 8 was never greater than 10).
Practice Question
Try It Yourself
Trace this algorithm with the input values 5, 20, 9, 30 (count starts at 1 and the loop runs 4 times):
01highest ← 0
02count ← 1
03WHILE count ≤ 4
04 value ← INPUT
05 IF value > highest THEN
06 highest ← value
07 ENDIF
08 count ← count + 1
09ENDWHILE
10OUTPUT highest
What is the final value output by the program?
Exam Tips — Mistakes & Mark-Scheme Traps
Common Mistake #1
Jumping straight into writing pseudocode without identifying inputs/outputs/processes first. This often produces a program that's almost right but is missing a variable, or handles the wrong data type — an easy avoidable loss of marks.
Common Mistake #2
Skipping or misreading a line in a trace table — especially IF conditions. Students often assume a condition is true without actually checking the current variable value against it.
Common Mistake #3
Not adding a new row when a variable changes inside a loop, which causes the table to "lose" a step and throws off every value after it.
What examiners actually look for
- Correct CIE syntax — using the right keywords (WHILE, IF...THEN...ENDIF, OUTPUT) exactly as specified
- Logical completeness — every input/output mentioned in the question is handled somewhere in your answer
- Trace tables filled in every time a value changes, not just at the "interesting" moments
- Final output written exactly as it would appear on-screen — not paraphrased
Practical exam techniques
- You don't need to fill in ENDIF or ENDWHILE lines in a trace table — they just mark where a block ends
- Use a dash (–) in any table cell where a column isn't relevant for that row, rather than leaving it blank
- If writing by hand, annotate the margin briefly to explain any tricky changes — it helps you catch your own mistakes and can earn method marks even if the final value is wrong
- Keep trace tables neat — messy, hard-to-follow working genuinely costs marks even when the reasoning was correct