Matura Computer Science common mistakes
Matura Computer Science · Understand the traps and how to avoid them.
When asked for a loop invariant or a correctness argument, the candidate restates the loop condition or the task description (e.g. "the loop runs until i = n") instead of stating a property that holds before and after every iteration and that implies the final result.
School teaching often stops at tracing loops with sample inputs, so invariants are learned as a definition to recite rather than as a tool. Candidates also confuse termination conditions with invariants because both mention the loop variable.
What to do instead
Practise writing invariants in a fixed template: "before iteration k, the first k elements are processed and X holds for them". Check it on the initialisation, on one arbitrary iteration, and at exit, then show how it yields the postcondition. Do this for binary search, linear search, and prefix-sum loops until the template is automatic.
In algorithm-complexity questions the candidate counts operations on a specific input ("for n = 8 the loop runs 3 times, so it is O(3)") or drops the wrong term, giving O(n) for a nested double loop or O(n^2) for a single loop with a halving counter.
Complexity is usually introduced by counting steps on concrete examples, and candidates never make the jump to the growth-rate definition. Nested loops look like "one loop inside another, so multiply by 2" rather than "n iterations each doing n work".
What to do instead
For every algorithm, derive the count symbolically first: inner loop cost times number of outer iterations, then keep only the dominant term. Memorise the three canonical patterns (single loop over n = O(n); loop with i = i/2 = O(log n); nested loops over n = O(n^2)) and re-derive each from the symbolic count before answering.
The candidate converts between number bases or representations incorrectly in edge cases: negative numbers in two's complement, sign extension when widening, or binary fractions with a non-terminating expansion such as 0.1. They compute the magnitude correctly but forget to invert and add 1, or truncate instead of extending the sign bit.
Base conversion is drilled on positive integers, where the school method (repeated division) always works. Negative values and fractional values require different procedures, and candidates reuse the positive-number routine.
What to do instead
Adopt fixed procedures: for two's complement of -x with n bits, write x in binary, invert all n bits, add 1, and verify by adding back to get zero. For fractions, multiply the fractional part by 2 repeatedly and record the integer parts, and state explicitly that some values cannot be represented exactly in a finite number of bits.
When asked to choose or justify a data structure, the candidate names one ("use a hash table") without linking the choice to the required operations and their costs, and without noting the trade-off (e.g. no ordered traversal, worst-case degradation, extra memory).
Candidates learn structures as definitions (stack = LIFO, queue = FIFO) and answer with the label. Exam questions that ask "which structure and why" reward the mapping from operations to costs, which is rarely practised in class.
What to do instead
Answer in a three-part form: list the operations the problem needs with required frequencies, give the cost of each operation for the proposed structure, then state one drawback and why it is acceptable here. Rehearse this for array vs linked list vs hash table vs balanced tree vs stack/queue.
In SQL the candidate writes a query that runs but answers a different question: filtering rows in WHERE when the condition belongs in HAVING with an aggregate, using WHERE instead of ON for an outer join, or grouping by a column that was not selected and losing rows through NULL comparisons (col = NULL instead of IS NULL).
The logical order of evaluation (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY) is often not taught explicitly, so candidates write clauses in the order they think of them. NULL semantics are counter-intuitive because NULL = NULL is unknown, not true.
What to do instead
Before writing SQL, annotate the task with the evaluation order and place each condition accordingly. Always test with a row containing NULL and with a group that should be excluded; rewrite col = NULL as col IS NULL and check outer joins by counting unmatched rows explicitly.
The candidate treats a relational schema as a spreadsheet: stores several values in one column, repeats the same fact across rows, or cannot explain why a table is or is not in third normal form because they cannot identify the functional dependencies.
Normalisation is often taught as a list of definitions (1NF, 2NF, 3NF) rather than as a procedure driven by dependencies, and candidates have more practice building flat tables than decomposing them.
What to do instead
For each table, list all functional dependencies explicitly (X determines Y), find candidate keys, then test each normal form against those dependencies. Practise decomposing one poorly designed table step by step and stating which anomaly (insert, update, delete) each decomposition removes.
In subnetting and addressing questions the candidate computes the network address or host range wrongly because they apply the subnet mask as a decimal subtraction, forget that the network and broadcast addresses are unusable, or treat a /26 as if it were a class C /24.
CIDR notation and masks are usually memorised as tables rather than derived, and candidates do not convert to binary when the mask is not on an octet boundary, which is exactly where the errors appear.
What to do instead
Always work in binary for the interesting octet: write address and mask, AND them for the network address, set host bits to all ones for broadcast, and derive usable hosts as 2^(host bits) - 2. Build a small table of /24 to /30 block sizes and check the answer against it.
The candidate confuses the layers of the TCP/IP and OSI models, placing e.g. IP at the transport layer, TCP at the network layer, or MAC addresses at the network layer, and mixes up what each protocol actually guarantees (TCP ordering and retransmission vs UDP best-effort).
Layer names are memorised as a list without a function attached, and the two models are taught side by side, so the mapping blurs. Encapsulation is rarely traced end to end, so candidates do not see which header is added where.
What to do instead
For each layer, write one sentence on its job and one example protocol plus the address or identifier it uses. Trace a single HTTP request down the stack and back up, naming the header added at each step, and state explicitly which guarantees TCP adds and UDP omits.
In number-representation and hardware questions the candidate mixes up units and storage: treating 1 KB as 1000 bytes when the question uses 1024, confusing bits and bytes, or computing memory size as number of cells times word length without converting to the requested unit.
Everyday decimal prefixes and the binary prefixes used in hardware coexist, and questions rarely state which convention applies. Candidates also drop the word-length factor because they count cells only.
What to do instead
Write the unit chain (bit, byte, KiB, MiB) at the top of the answer and convert only at the end, showing the factor used. For memory, always compute cells x bits per cell, then divide by 8 for bytes and by 1024 for KiB, and state the convention assumed if the question is ambiguous.
In software-engineering questions the candidate describes what the software does instead of answering the process question: giving a code sketch when asked for a test case or a requirement, or listing waterfall phases without saying what artefact each phase produces or how iteration differs in an agile model.
Candidates are more confident writing code than process prose, so they drift to the familiar activity. Process models are often learned as ordered lists of names rather than as sets of activities with inputs and outputs.
What to do instead
For each process question, answer with artefact, activity, and criterion: what document or test exists, who produces it, and how you know it is done. Practise writing one requirement, one black-box test case with input, expected output, and one boundary value, and one comparison of two lifecycle models in a fixed three-point format.