WACE Computer Science common mistakes
WACE Computer Science · Understand the traps and how to avoid them.
When asked to trace a recursive function, the candidate writes only the final return value and omits the intermediate calls, so partial credit is lost even when the answer is correct.
Recursion is taught as a definition rather than a call-stack process, so candidates collapse the unwinding into a single mental step and never record the base case or each return as it resolves.
What to do instead
Practise drawing a call tree for every recursive trace: write each call with its arguments, mark the base case hit, then unwind with an arrow per return. Do five traces of factorial, Fibonacci and a list-reversal by hand until the layout is automatic.
The candidate describes what a program does in general prose instead of stating the algorithm's steps in order, so a 'describe the algorithm' question earns little credit.
Candidates confuse explanation with narration and assume the marker will infer the logic; they also lack a vocabulary for control structures, so they avoid naming loops, conditions and termination.
What to do instead
Answer algorithm questions as numbered pseudocode steps, each beginning with a verb (initialise, read, compare, increment, return). After writing, check that every step names a variable and that the loop's termination condition is explicit.
When converting between data representations (binary, hexadecimal, two's complement, floating point), the candidate drops leading zeros or misplaces the sign bit, producing answers that are off by a place value.
Candidates work left to right from memory without writing place-value headings, and they treat two's complement as 'flip the bits' without adding one or fixing the bit width.
What to do instead
Always write the place-value row (128, 64, 32, 16, 8, 4, 2, 1) before converting and state the fixed width at the start. For negatives, show the three steps separately: magnitude in binary, invert, add one, then verify by converting back.
The candidate writes SQL or pseudocode that ignores the stated edge case (empty table, duplicate keys, null values, zero-length input) and so fails the test data in the question.
Candidates test mentally with one typical example and stop; they do not habitually enumerate boundary conditions, and exam pressure rewards finishing quickly over checking.
What to do instead
Before finalising any query or algorithm, list three test cases: smallest valid input, largest, and an invalid or empty one. Trace each through the written logic and note the result beside the answer.
In questions on networks, the candidate names a protocol or device but cannot say which layer it belongs to or what problem it solves, so comparison marks are lost.
Protocols are memorised as a list of acronyms without a model to attach them to, and the OSI or TCP/IP layers are recalled as labels rather than as a division of responsibilities.
What to do instead
Build a one-page table with columns for layer, function, protocol, addressing unit and example device, and fill it from memory weekly. When answering, always state the layer and the specific job the protocol performs before naming it.
The candidate gives a definition of a hardware or system concept but no worked example of how it operates in a real system, so application marks are missed.
Revision focuses on glossary terms, and candidates do not rehearse linking a concept to a scenario such as cache in a CPU pipeline or virtual memory in multitasking.
What to do instead
For each key concept, prepare a two-sentence scenario: one naming the component and its role, one describing what happens when it is absent or too small. Practise inserting the scenario into answers even when the question says 'describe'.
In a database design question, the candidate draws an entity-relationship diagram with repeating groups or without resolving a many-to-many relationship, then produces tables that are not in third normal form.
Candidates copy the scenario's paper form directly into tables, keeping multi-valued attributes such as a list of phone numbers in one column, and they do not test each table against the normal-form questions.
What to do instead
Apply a checklist to every design: does each cell hold one value, does every non-key attribute depend on the whole key, and are there any non-key dependencies? Convert each many-to-many link into a junction table with a composite key and show it explicitly.
The candidate describes a security threat only by naming it (for example 'phishing' or 'SQL injection') without explaining the mechanism, the vulnerable point and a specific mitigation.
Security is revised as a vocabulary list, and candidates do not practise the three-part structure the marking key expects: how the attack works, what it exploits, and how it is prevented.
What to do instead
Answer every security question in three sentences: mechanism, vulnerable component, control. For each threat on the syllabus, memorise one concrete control (parameterised queries, input validation, hashing with salt, multi-factor authentication) and be ready to justify it.
The candidate writes code that runs but ignores naming, indentation and comments, and then cannot explain their own variable names when a later part asks them to modify the program.
Candidates treat style as cosmetic and write under time pressure, using single letters and deep nesting; this also makes debugging and extension questions harder for them.
What to do instead
Adopt a fixed convention before the exam: meaningful camel-case names, one statement per line, consistent indentation, and a comment for each function stating purpose and parameters. Rehearse refactoring a short program under timed conditions.
The candidate answers an 'evaluate' or 'discuss' question with a one-sided list of advantages and no judgement, so the highest band is not reached.
Candidates do not distinguish command words, treating 'discuss' as 'describe', and they run out of time before writing a conclusion.
What to do instead
Underline the command word first and match the structure: describe, then compare, then a stated recommendation with a reason and a condition under which it would change. Allocate the last two minutes of any extended response to writing an explicit judgement sentence.