Computer Science Level 3 common mistakes
Computer Science Level 3 · Understand the traps and how to avoid them.
When tracing a loop or recursive function, the candidate writes down only the final output and never records intermediate variable values, so they cannot detect that an accumulator was reset inside the loop body instead of before it.
Tracing is treated as a reading exercise rather than a simulation; working memory is used to hold state instead of a table on paper, and small state changes get lost after three or four iterations.
What to do instead
Build a trace table with one column per variable plus a column for the printed or returned value before attempting to answer. For recursion, draw the call tree and annotate each frame with its arguments and return value. Re-derive the answer from the table, not from memory.
The candidate analyses an algorithm's complexity by counting lines of code rather than counting how many times the dominant operation runs as a function of input size, and so labels a nested loop over the same array as O(n^2) without noticing the inner index starts at the outer index.
Big-O is memorised as a pattern-matching rule ('two loops means quadratic') rather than as a growth-rate argument, and the halving or triangular structure of the loop bounds is not examined.
What to do instead
For every loop, write the exact number of iterations as a sum, then simplify. Distinguish n^2/2 from n^2 and log n from n. Practise classifying a set of short code fragments by deriving the count first and only then naming the complexity class.
The candidate writes a condition that is off by one at a boundary, such as using < instead of <= when the problem statement says 'up to and including', or starting a search at index 1 in a zero-indexed array, and does not test the empty and single-element cases.
Boundary values are invisible in the typical middle-of-the-range example the candidate mentally tests, and inclusive versus exclusive wording in the specification is skimmed.
What to do instead
Before coding, list the boundary cases explicitly (empty, one element, first, last, maximum size) and hand-check the condition against each. After coding, run the same list as test inputs. Highlight the words 'inclusive', 'at most', and 'strictly' in the prompt.
The candidate confuses pass-by-value with pass-by-reference semantics, expecting a function that reassigns a parameter to change the caller's variable, or expecting a function that mutates a list not to affect the caller's list.
The distinction between rebinding a name and mutating the object a name points to is subtle, and many languages pass an object reference by value, which behaves like both at once.
What to do instead
State the language's rule in one sentence before answering, then classify the operation as 'rebind the parameter' or 'mutate the referenced object'. Write a two-line experiment mentally: assign a new value to the parameter versus call a mutating method, and predict each caller-visible effect.
When asked to choose a data structure, the candidate picks the one with the most familiar name rather than reasoning from the required operations, for example choosing a sorted array for frequent middle insertions or a linked list for frequent index-based access.
Structures are learned as definitions (what a stack is) rather than as cost profiles (what a stack costs per operation), so the operation mix in the scenario is never matched against a cost table.
What to do instead
Extract the required operations and their frequencies from the prompt, then fill a small table of average costs for each candidate structure across those operations. Choose the structure that minimises the dominant operation, and state the trade-off explicitly.
The candidate describes a hash table lookup as O(1) without qualification in a question that involves many collisions or a poor hash function, and so predicts constant time where the expected behaviour degrades to linear.
The average-case result is memorised as an unconditional fact, and the assumption of a uniform hash with bounded load factor is never surfaced.
What to do instead
Always state the assumption alongside the claim: O(1) expected under uniform hashing and a bounded load factor, O(n) worst case. When a scenario mentions clustering, a constant hash, or a load factor near one, reason about chain length rather than quoting the average.
The candidate converts between binary, decimal, and hexadecimal by pattern-matching digits instead of grouping bits, producing errors such as writing 0b1011 as 0xB or misreading a two's complement negative value as a large positive one.
Place values are recited but not used, and the four-bits-per-hex-digit grouping rule is applied from the wrong end of the number or without padding.
What to do instead
Convert via grouping: pad binary to a multiple of four from the right, then map each nibble to one hex digit. For two's complement, check the sign bit first and, if set, invert and add one to recover the magnitude. Verify by converting back.
The candidate answers a subnetting or addressing question by recalling a default mask rather than deriving the network and broadcast addresses from the prefix length, so the usable host range is off by one at each end.
The arithmetic of block size and host bits is skipped in favour of memorised class-based masks, and the rule that network and broadcast addresses are unusable is forgotten.
What to do instead
For a /p prefix, compute host bits as 32 minus p, block size as 2 to that power, and usable hosts as block size minus two. Write the network address, first usable, last usable, and broadcast explicitly before selecting an answer.
The candidate reads a summary statistic or a chart as if it established a causal relationship, or compares group averages without checking group sizes, spread, or how the data were collected, and concludes that one treatment caused the observed difference.
Charts and summary tables invite a fast narrative, and the distinction between association and causation plus the effect of confounding variables is not applied as a routine checklist.
What to do instead
For every data conclusion, ask three questions in writing: was assignment random, what else differs between the groups, and how variable is each group. Report spread alongside the mean, and phrase conclusions as associations unless a controlled design supports causation.
The candidate treats a legal or ethical question as a purely technical one, answering 'the system can do it' or 'the terms of service allow it' when asked whether a design decision is appropriate, and ignores consent, bias, and the effect on affected users.
Technical framing dominates the candidate's preparation, and ethical reasoning is assumed to be subjective and therefore ungraded, so no structured analysis is attempted.
What to do instead
Answer such questions with a structured analysis: identify the stakeholders, the harm or benefit to each, the relevant obligation (consent, transparency, fairness, safety), and the least harmful alternative. State the trade-off rather than declaring the decision obvious.