The question every Paper 2 student asks
You are sitting in the exam hall, you turn the page, and there it is: a problem you have never seen before, asking you to write an algorithm from scratch. Your pulse quickens. Where do you even start?
Here is the good news. Paper 2 is not about memorising content. It is about applying a set of skills you can practise and sharpen until they feel automatic. Every question on this paper follows patterns, and once you learn those patterns, that unfamiliar problem becomes a series of smaller steps you already know how to handle.
This guide will walk you through exactly what to expect, how to manage your time, what the mark scheme rewards, and how to avoid the mistakes that cost students marks every single session.
What Paper 2 looks like
IGCSE Computer Science Paper 2 (Algorithms, Programming and Logic) is 1 hour 45 minutes long and worth 75 marks. Every question is compulsory. Unlike Paper 1, which tests your theoretical knowledge, Paper 2 tests whether you can actually do things: write code, trace through algorithms, complete flowcharts, construct SQL queries, and solve Boolean logic problems.
The paper typically starts with shorter, more guided questions and builds toward longer algorithm-design tasks at the end. Those final questions carry the most marks and require the most thinking time, so you need a clear plan for your pacing.
Time management: why coding questions need extra room
With 105 minutes and 75 marks, you have roughly 1.4 minutes per mark on average. But here is something important that catches students off guard: coding and algorithm-design questions take longer per mark than trace tables or short-answer questions. You need to read the problem, plan your approach, write the code, and then check it line by line.
| Question type | Typical marks | Suggested time | Why |
|---|---|---|---|
| Trace table | 3-5 | 4-6 min | Methodical but predictable. One pass through the code, row by row. |
| Complete/correct pseudocode | 3-6 | 5-8 min | You need to read the existing code, understand its intent, then fill the gaps. |
| Write a program/algorithm | 5-8 | 8-12 min | Planning + writing + checking. This is where most time pressure hits. |
| Flowchart completion | 3-5 | 4-6 min | Read the existing flow, spot the logic, fill in boxes and decision diamonds. |
| Boolean logic / truth table | 3-6 | 4-7 min | Systematic but requires care. One wrong row loses that mark. |
| SQL query | 3-5 | 4-6 min | Read the table structure, translate the English request into SQL syntax. |
Question types and how to tackle each one
Paper 2 draws from a consistent set of question types. Knowing what each one demands puts you in control before you even read the specific problem.
Trace tables
You are given a piece of code (usually pseudocode) and a table with columns for each variable. Your job is to step through the code line by line and record every value change.
Your approach:
- Read the entire code snippet before you start filling in the table. Understand the loop structure and when variables change.
- Work through one iteration at a time. Write down the value of every variable at each step, even if it has not changed. Blank cells can cost you marks.
- Pay close attention to the loop condition. Know exactly when the loop ends. Off-by-one errors here are the most common way to lose marks.
- If the code includes an OUTPUT statement, there is usually a column or row for outputs. Do not forget to record them.
Writing and completing pseudocode
Some questions give you partial pseudocode with blank lines to fill in. Others ask you to write an entire algorithm from a problem description. Both reward clean, logical code.
Cambridge has its own pseudocode syntax, and the mark scheme expects you to follow it. Here are the conventions that matter most:
- Assignment: Use the arrow symbol or the syntax your exam paper shows. Read the instruction page at the front of the paper carefully.
- Loops:
FOR...TO...NEXT,WHILE...DO...ENDWHILE,REPEAT...UNTIL. Know when to use each. FOR loops are for known iterations. WHILE loops are for conditions checked at the start. REPEAT...UNTIL checks at the end (the body always runs at least once). - Selection:
IF...THEN...ELSE...ENDIFandCASE OF...OTHERWISE...ENDCASE. - Input/Output:
INPUTandOUTPUT(orPRINT). - String operations: Know LENGTH(), SUBSTRING(), UCASE(), LCASE(). These appear in string-manipulation questions regularly.
If you are completing partial pseudocode, read the surrounding lines first. The code above and below your gap tells you what variables exist, what the data types are, and what the algorithm is trying to do. Match the style and indentation of the existing code.
Writing program code
When a question says "write a program" or "write an algorithm," you can answer in Cambridge pseudocode or in any high-level programming language your school uses. The mark scheme accepts Python, Java, VB.NET, and others.
Whichever language you choose, the marks come from:
- Correct logic: Does your code solve the problem? This is the biggest chunk of marks.
- Appropriate variable declarations and data types: Use meaningful names. The mark scheme often awards a mark for declaring variables with sensible identifiers.
- Input and output matching the question: If the question says "output the total," your code must have an output statement that shows the total.
- Validation where specified: If the problem says "the user should only enter a positive number," you need a validation loop.
Flowchart completion
Flowchart questions give you a partially completed diagram and ask you to fill in missing process boxes, decision diamonds, or flow arrows. The key shapes you need:
- Oval: Start/End (terminator)
- Rectangle: Process (an action or calculation)
- Diamond: Decision (a Yes/No question)
- Parallelogram: Input/Output
Before you fill in any box, trace the entire flowchart from start to end. Understand what it does. Then identify what the missing step should be. Decision diamonds must always have two labelled exits (Yes and No), and every flow path must eventually reach the end or loop back.
Boolean logic
Boolean questions on Paper 2 typically involve truth tables, writing Boolean expressions from problem descriptions, or simplifying expressions. You might also need to draw or interpret logic gate circuits.
Your key tools:
- AND: Both inputs must be TRUE for the output to be TRUE.
- OR: At least one input must be TRUE for the output to be TRUE.
- NOT: Inverts the input.
- NAND, NOR, XOR: Know their truth tables. XOR is TRUE when inputs are different.
For truth tables, list every possible input combination systematically. For two inputs, that is four rows. For three inputs, eight rows. Missing a row means missing marks. Work column by column through intermediate expressions before calculating the final output.
SQL queries
SQL questions give you a database table (or tables) and ask you to write a query to retrieve specific data. The Cambridge IGCSE syllabus focuses on SELECT statements.
The building blocks you need:
SELECT field1, field2 FROM tableName- choose which columns to showWHERE condition- filter rowsAND,OR- combine conditionsORDER BY fieldName ASC/DESC- sort the resultsLIKEwith wildcards (%for any characters,_for a single character)SUM(),COUNT(),AVG()- aggregate functions
Read the question carefully. "Display the names of all students who scored above 80, sorted by name" translates directly into: SELECT Name FROM Students WHERE Score > 80 ORDER BY Name ASC. Each clause maps to a part of the English sentence. Practice this translation skill and it becomes second nature.
Algorithm design from problem descriptions
These are the big-mark questions, usually at the end of the paper. You are given a real-world scenario and asked to design a complete algorithm. This might involve arrays, file handling, counting, searching, sorting, or string processing.
Your step-by-step approach:
- Read the problem twice. On the first read, get the overall picture. On the second, underline every specific requirement (inputs, outputs, conditions, repetitions).
- List your variables. Before writing any code, jot down what data you need to store and what type each variable should be. This takes 30 seconds and prevents confusion later.
- Sketch the structure. Will you need a loop? A counter? An array? A nested IF? Decide on the skeleton before you flesh it out.
- Write the code. Use clear indentation. Start with input, then processing, then output. Add validation if the question asks for it.
- Dry-run your solution. Pick a simple test case and mentally trace through your code. Does it produce the right output? This takes one minute and catches most logical errors.
What the mark scheme rewards
Understanding how marks are allocated changes the way you write your answers. Here is what Cambridge examiners consistently look for across Paper 2:
| What earns marks | Example |
|---|---|
| Correct loop structure (type and condition) | Using WHILE when the number of iterations is unknown, with the correct termination condition |
| Initialising variables before use | Setting Total = 0 before a counting loop |
| Correct conditional logic | IF Score >= 50 THEN OUTPUT "Pass" (not just IF Score > 50 when 50 should pass) |
| Appropriate input/output statements | Using INPUT to read user data, OUTPUT to display results, in the right places |
| Meaningful variable names | StudentName rather than x, TotalScore rather than t |
| Validation loops | REPEAT INPUT Age UNTIL Age >= 0 AND Age <= 120 |
| Correct use of arrays | Declaring with the right size, accessing with correct indices (0-based or 1-based as per the question) |
Notice that the mark scheme does not penalise minor syntax errors in most cases. If you write print(total) instead of OUTPUT Total, you will still get the logic mark. But if your loop runs one too many times or your condition uses the wrong comparison operator, you lose the mark for that element. Logic first, syntax second.
The pitfalls that cost students marks every session
Examiner reports for IGCSE Computer Science Paper 2 highlight the same mistakes year after year. Knowing these in advance gives you a genuine edge.
- Forgetting to initialise variables. If you use a counter or a running total, it must start at 0 (or whatever the correct initial value is). Writing
Total = Total + Scorewithout first settingTotal = 0is an error the mark scheme catches. Make initialisation your first line inside any counting or totalling algorithm. - Creating infinite loops. If your WHILE loop's condition never becomes false, or your REPEAT loop's condition never becomes true, the algorithm runs forever. Always check: does something inside the loop change a value that will eventually trigger the exit condition?
- Off-by-one errors. A FOR loop from 1 TO 10 runs 10 times. A FOR loop from 0 TO 10 runs 11 times. If you are filling an array of 10 elements, make sure your loop matches. These single-mark losses add up fast.
- Ignoring the question's variable names. If the question defines a variable called
MaxTemp, useMaxTempin your answer, nothighestTemperatureormax. The mark scheme is written around the given names, and using different ones creates unnecessary confusion. - Mixing up pseudocode and programming language syntax. If you choose to answer in pseudocode, stick to Cambridge pseudocode conventions throughout. If you choose Python, write Python throughout. Mixing the two makes your answer harder to follow and can cost clarity marks.
- Not reading what the output should be. Some questions specify an exact output format: "Display the message 'Invalid entry' if the input is out of range." If you output "Error" instead of "Invalid entry," you may lose the output mark. Copy the wording from the question.
- Skipping validation. When a question says "the input must be between 1 and 100," it is asking for a validation loop. Simply adding an IF statement that checks once is not enough. The user should be re-prompted until they enter a valid value.
Structuring your answers for maximum marks
Presentation matters on Paper 2, not because the examiner cares about your handwriting, but because clear code is easier to mark (and easier for you to debug under pressure).
- Indent your code. Every line inside a loop or IF block should be indented one level. This makes the structure visible at a glance and helps you spot missing ENDIF or NEXT statements.
- One statement per line. Do not cram multiple operations onto a single line. The mark scheme awards marks per logical step, and separating them makes each mark point visible.
- Use blank lines between sections. If your algorithm has an input section, a processing section, and an output section, separate them visually. This helps you and the examiner.
- Label your outputs. Instead of just
OUTPUT Total, writeOUTPUT "The total is: ", Total. This matches what real programs do and shows the examiner you understand user-friendly output.
Your past paper practice strategy
Past papers are your best preparation tool for IGCSE Computer Science Paper 2. But the way you use them makes all the difference. Here is a progressive approach that builds your skills in layers.
Stage 1: Guided practice (6-8 weeks before the exam)
- Pick one question type per session. Monday is trace tables. Wednesday is pseudocode completion. Friday is algorithm design.
- Work through questions from two or three past papers, but keep your notes open. You are learning the patterns, not testing yourself yet.
- After each question, check the mark scheme. Pay close attention to the exact wording the mark scheme uses. Write down any marking points you missed.
Stage 2: Independent practice (4-5 weeks before the exam)
- Attempt questions without notes, but do not time yourself yet. Focus on accuracy.
- After marking, sort your errors into categories: logic errors, syntax confusion, incomplete answers, or time-related shortcuts. This tells you what to work on next.
- For any question type you consistently struggle with, go back and do five more questions of that type before moving on.
Stage 3: Timed full papers (2-3 weeks before the exam)
- Sit a complete past paper under exam conditions. 1 hour 45 minutes, no notes, no phone, no IDE.
- Mark it honestly against the mark scheme. Calculate your score.
- For every mark you lost, ask: was it a knowledge gap, a careless slip, or a time management problem? Track these in a simple log.
- Repeat with a different past paper. Watch your error categories shrink.
A few final strategies for exam day
You have done the preparation. Now make sure the exam itself goes smoothly.
- Read the front page. It shows the pseudocode conventions used in the paper. If you are answering in pseudocode, this is your reference sheet. Use it.
- Scan the whole paper first. Spend two minutes flipping through to see how many questions there are, where the high-mark questions sit, and whether any topics feel particularly comfortable. This gives you a mental map for pacing.
- Answer what you know first. If a question has you stuck after two minutes of thinking, move on. Come back to it later with fresh eyes. Do not let one difficult question eat into the time you need for questions you can answer well.
- Use the space provided. If the exam gives you half a page for a 6-mark answer, that is a hint about how much you should write. A three-line answer for a half-page space probably means you are missing detail.
- Never leave a question blank. Even a partial algorithm with the right input statement and loop structure can earn marks. An empty answer earns nothing. Write what you can.
- Dry-run your code. For any programming answer worth 4 or more marks, spend 60 seconds mentally stepping through your code with a simple input. This is your personal trace table, and it catches errors before the examiner does.
Paper 2 rewards students who practise actively, think methodically, and write clean, logical code. You do not need to be a coding prodigy. You need to be someone who reads carefully, plans before writing, and checks their work. Those habits, built through consistent past paper practice, are what turn a nervous exam hall moment into a confident, mark-earning performance. You have got this.
A hands-on exam technique guide for Cambridge IGCSE Computer Science Paper 2 (0478), covering how to approach trace tables, pseudocode, programming answers, flowcharts, Boolean logic, and SQL. Includes mark scheme patterns, time management for coding questions, common pitfalls, and a progressive past paper practice strategy.
Àsìkò méjì (Comment(s))