Cambridge IAL Computer Science common mistakes
Cambridge IAL Computer Science · Understand the traps and how to avoid them.
When asked to trace a recursive function, writes only the final return value instead of a call-by-call trace showing the argument values passed down and the values returned back up the stack.
Candidates treat recursion as a black box and mentally simulate it, losing track once depth exceeds two or three levels; the mark scheme awards method marks for the unwind sequence, not just the answer.
What to do instead
Practise drawing a stack of boxes: one box per call with its argument, an arrow down to the next call, and the returned value written back on the arrow as the stack unwinds. Do this for a factorial, a Fibonacci and a binary search, then compare against a run of the code. Always show the base case being reached explicitly.
Writes pseudocode that mixes constructs from several languages, uses indentation inconsistently, and omits declarations, so the logic cannot be followed or marked.
Candidates learn several languages and drift into whichever syntax feels familiar mid-answer; many also skip declaring variables because their IDE infers types.
What to do instead
Adopt one fixed pseudocode convention and use it in every practice answer: explicit variable declarations, consistent ENDIF/ENDFOR or braces, one statement per line, parameters named in headers. Before writing, sketch the algorithm in three or four numbered steps, then translate. Re-read the finished pseudocode as if executing it line by line and note where a variable is used before assignment.
Describes the difference between procedural, object-oriented and declarative paradigms only in terms of syntax, saying things like 'OOP uses classes and procedural uses functions', without discussing state, encapsulation, inheritance or how the problem is decomposed.
Teaching often introduces paradigms through code examples, so the visible surface features become the remembered definition; the deeper conceptual distinctions are never rehearsed in prose.
What to do instead
For each paradigm prepare a three-part answer: how the problem is decomposed, where data lives relative to the code, and what changes when requirements change. For OOP add encapsulation, inheritance and polymorphism with a one-line example each. Practise comparing two paradigms on a concrete task such as a student records system, naming which features each would use and why.
States that a compiler 'translates line by line' or confuses the roles of compiler, interpreter and assembler, and cannot say what a linker or loader contributes.
The terms are learned as a list without a pipeline, so the stages blur; the phrase 'line by line' is remembered but attached to the wrong tool.
What to do instead
Draw the full pipeline: source code, lexical analysis, syntax analysis, code generation, object code, linker, executable, loader. Annotate each stage with its input and output and the error type it detects. Then place the interpreter beside it and mark the two differences: whole-program translation versus statement-by-statement execution, and object code versus immediate execution.
When asked about error detection, describes a parity bit as being able to correct errors, or claims a checksum detects all errors, without distinguishing detection from correction or single-bit from burst errors.
Parity, checksums and CRCs are taught together and their capabilities merge; candidates also over-generalise from 'detects errors' to 'fixes errors'.
What to do instead
Build a comparison table with rows for single parity bit, block parity, checksum and CRC, and columns for what it detects, whether it corrects, and its weakness. State explicitly that a single parity bit detects an odd number of flipped bits and cannot correct; block parity can locate and correct a single bit; a checksum is weak against compensating errors. Write one sentence per method using this vocabulary.
Explains packet switching and circuit switching by listing advantages without describing what physically happens: no mention of packets carrying source and destination addresses, independent routing, reassembly, or the reservation of a dedicated path.
The topic is revised as a pros-and-cons list rather than as a process, so the mechanism, which is what the marks reward, is never articulated.
What to do instead
Write a numbered narrative for sending a file across a packet-switched network: split into packets, attach header with source, destination and sequence number, each packet routed independently by routers, packets may arrive out of order, receiver reorders using sequence numbers and requests retransmission of missing packets. Then contrast with circuit switching where a path is established before transfer and held for the duration. Answer scenario questions by applying the narrative, not the list.
Describes the fetch-decode-execute cycle vaguely as 'the CPU gets the instruction and runs it', omitting the program counter, memory address register, memory data register, the role of the control unit and where the increment of the PC happens.
Candidates memorise register names as a list without mapping each to its function in the cycle, and the sequence of register transfers is never practised.
What to do instead
Write the cycle as explicit register transfers: PC to MAR, memory read, contents to MDR, MDR to CIR, PC incremented, control unit decodes CIR, operands fetched, execute, status registers updated. Learn what each register holds and why. Then answer a question on pipelining or on a von Neumann bottleneck by referring to these transfers, since that is what earns the higher marks.
Treats cache as simply 'faster memory' and cannot explain hit rate, locality of reference, or why increasing cache size gives diminishing returns; similarly describes RISC and CISC only as 'fewer instructions' versus 'more instructions'.
These topics are summarised in single slogans during revision, and the quantitative or architectural reasoning behind them is skipped.
What to do instead
For cache, learn the terms hit, miss, hit rate and locality (spatial and temporal), and be able to explain that a larger cache raises hit rate but with diminishing returns and higher cost and access latency. For RISC and CISC, build a table covering instruction count, instruction complexity, addressing modes, pipelining suitability and compiler burden, and practise explaining why RISC suits pipelining.
Converts between denary and two's complement or between binary and hexadecimal but drops the sign bit, forgets to state the number of bits, or performs subtraction by ordinary binary subtraction and reports a positive result for a negative answer.
Candidates learn the flip-and-add-one procedure as a ritual without understanding the fixed width, so leading zeros and the sign bit get lost and range questions become guesswork.
What to do instead
Always state the word length first, for example '8-bit two's complement'. Write out all bits including leading zeros and leading sign bits. Check by converting back. Learn the range formula for n bits, minus two to the power n minus one up to two to the power n minus one minus one, and use it to sanity-check every answer. For subtraction, convert to adding the two's complement and discard the final carry with a note saying so.
Compares data structures by naming them, for example 'a linked list is better than an array', without linking the choice to the operations required: insertion, deletion, search, and access by index, or to memory layout and static versus dynamic sizing.
Structures are memorised as definitions with a vague advantage attached, and candidates do not rehearse justifying a choice against a stated scenario.
What to do instead
For each structure (array, linked list, stack, queue, binary search tree, hash table) write its memory layout, the cost of access by index, search, insertion and deletion, and one scenario where it is the right choice. When answering, quote the scenario's dominant operation and justify with that cost, for example frequent insertion at the front favours a linked list because no elements need shifting. Use the same reasoning to explain why a stack suits recursion or expression evaluation.