IB Computer Science HL common mistakes
IB Computer Science HL · Understand the traps and how to avoid them.
When asked to compare two storage or processing options, the candidate lists features of each option side by side ("RAM is volatile; ROM is non-volatile") without stating a criterion of comparison or a conclusion, so the answer never actually compares.
Candidates read "compare" as "describe both" and reproduce memorised definitions in two columns. IB command terms are graded against the command term, and a list of parallel facts does not demonstrate the relational thinking the mark scheme rewards.
What to do instead
Before writing, choose two or three explicit criteria (cost, speed, volatility, capacity, portability) and structure the answer by criterion, not by option: "On speed, RAM is faster because... whereas ROM...". Finish each criterion with a comparative judgement word (faster, cheaper, more suitable for X). Practise by rewriting past definition-style answers into criterion-first paragraphs.
The candidate answers a binary/hexadecimal or two's complement question with a final value but no working, and when working is shown the conversion is done digit-by-digit left to right (e.g. converting 1101 to decimal as 1+1+0+1) or negative numbers are converted by simply flipping the sign bit.
Candidates memorise the place-value table but not the direction of application, and two's complement is learned as a set of steps without the underlying idea that the most significant bit carries a negative weight. Under exam pressure the steps collapse into guessing.
What to do instead
Always show place values above the digits (8 4 2 1) and sum the weights of the 1-bits. For two's complement, practise the negative-weight method: for an 8-bit number the MSB is worth -128, so 1111 0000 = -128+64+32+16 = -16. Verify by adding the number to its negation and confirming the result is zero. Show the working even when the final answer is right, because method marks are awarded separately.
When drawing or interpreting a logic circuit or truth table, the candidate evaluates gates in reading order (left to right) rather than by operator precedence, and writes a truth table with too few rows (e.g. 4 rows for three inputs) or omits intermediate columns.
Boolean expressions look like arithmetic, so candidates apply left-to-right intuition; and truth tables are copied from memory of two-input examples without recounting inputs. The absence of intermediate columns makes an error invisible to the candidate.
What to do instead
Bracket the expression first (AND binds tighter than OR; NOT tightest) and redraw with explicit brackets before simplifying. For a truth table with n inputs, count rows as 2^n and write them in binary counting order before filling outputs. Add a labelled column for every intermediate sub-expression. Cross-check the final column against a Karnaugh map or a second simplification route.
In tracing an algorithm or writing code, the candidate confuses = (assignment) with == (comparison), or writes a loop that is off by one because the loop bound is tested after the body has already run one extra time. Traces show variable values only at the end, not per iteration.
Pseudocode taught in class often uses an arrow or a left-pointing assignment that hides the distinction, and candidates trace mentally rather than on paper. The end-state-only trace hides the iteration where the error occurred.
What to do instead
Use a trace table with one column per variable plus a column for output/condition, and fill one row per iteration, including the iteration where the loop exits. Write loop conditions explicitly (e.g. WHILE i < N, not WHILE i <= N unless intended) and test with N = 0, 1 and 2. In code, adopt a personal convention: assignment always written as := or <- in pseudocode, comparison always ==.
The candidate describes a stack, queue, linked list or binary tree only in terms of its abstract operations (push, pop, enqueue) and never mentions the underlying pointer or array mechanics, so questions asking why a linked list insertion is O(1) or why a queue implemented with a fixed array needs a circular buffer are answered with definitions instead of mechanisms.
HL data structures are often taught through library-style operations, so the memory representation is learned as a diagram to reproduce rather than a model to reason with. The candidate has no vocabulary (head pointer, next pointer, tail, front/rear indices) to explain cost.
What to do instead
For each structure, draw the memory picture: nodes with a data field and a next pointer, a head reference, and what changes on insert/delete. Then derive the complexity from the picture: inserting after a known node changes two pointers, so it is constant time regardless of list length; searching is linear because you must follow pointers. For the array-based queue, draw front and rear wrapping modulo the array size and show what happens on the (n+1)th enqueue.
On recursion questions the candidate writes a recursive method without a base case, or with a base case that is never reached because the recursive call does not move toward it; when asked to trace, they list the calls in the order written rather than the order of return.
Recursion is understood as "a method that calls itself" rather than as a stack of suspended frames. Candidates also confuse the call order (down the stack) with the return order (up the stack), which is exactly what output-producing recursion tests.
What to do instead
Write every recursive method with three labelled parts: base case, recursive case, and the reduction that guarantees progress toward the base case. Trace on paper as a stack of frames, writing each call downward and each return upward, and note the value returned at each level. Test with the smallest input (0 or 1) first, then one more.
When asked about memory management, the candidate defines virtual memory, paging or garbage collection but cannot explain what problem each solves, so answers to "why is virtual memory needed" restate "it gives the illusion of more memory" without linking it to process isolation, fragmentation, or the difference between paging and segmentation.
These topics are learned as vocabulary lists detached from the hardware and OS constraints that motivate them. Without the problem statement, the candidate cannot distinguish related mechanisms and writes circular definitions.
What to do instead
For each mechanism, write a three-line card: the problem (physical RAM is limited and shared; programs are written assuming a contiguous address space), the mechanism (pages mapped to frames via a page table; the MMU translates addresses), and the consequence (isolation between processes, no need for contiguous allocation, page faults when a page is not resident). Compare paging and segmentation on the axis of fixed versus variable size and on external versus internal fragmentation.
On control-system questions the candidate describes a sensor and an actuator but omits the controller, the comparison with a set point, and the feedback path, so an open-loop answer is given where closed-loop behaviour was asked for (e.g. a washing machine described as if it monitored cleanliness).
Everyday devices are described by what the user sees rather than by the control loop. Candidates also assume any system with a sensor is closed-loop, missing that feedback requires the output to influence the input.
What to do instead
Draw the loop explicitly: sensor → input signal → controller (compares with set point) → actuator → process → output, with an arrow back from output to sensor labelled feedback. State the set point and the error signal. Classify the example by asking whether the output is measured and used to adjust the input; if not, it is open-loop. Practise on toasters, washing machines, thermostats and autonomous braking, and name which component plays each role in each.
In the internal assessment, the candidate writes a solution that works but cannot be traced to the success criteria: the criteria are vague ("the system should be user-friendly"), there is no test plan mapping each criterion to specific test data, and the video or documentation shows features rather than demonstrating that each criterion is met.
Students build first and document afterwards, so the criteria are reverse-engineered from whatever was built. "User-friendly" feels like a criterion but cannot be tested, and without planned test data the candidate relies on the happy path only.
What to do instead
Write the success criteria before design, in the form "the system must [do X] when [condition] so that [client need]", each numbered and each testable by observation. Build a test plan table with columns: criterion number, test data (including normal, boundary and invalid data), expected result, actual result, and evidence location. Record the video against the test plan so each criterion is visibly demonstrated, and include at least one failed-then-fixed test to show iterative development.
On network questions the candidate answers with a protocol name only ("TCP ensures reliability") and never describes the mechanism, or confuses the layers of the TCP/IP model, placing HTTP at the transport layer or describing a MAC address as routable across the internet.
Protocols are memorised as labels attached to functions, and the layered model is learned as a list of names without the encapsulation idea. Without encapsulation, the candidate cannot reason about which address or header is used at which layer.
What to do instead
For each protocol, write what it does and how: TCP uses sequence numbers, acknowledgements and retransmission; IP uses best-effort routing on network addresses; Ethernet uses MAC addresses within a local segment. Draw encapsulation explicitly - application data → TCP segment (port numbers) → IP packet (source and destination IP) → frame (MAC addresses) - and place each protocol in the layer that adds its header. When asked about a scenario, walk the layers in order rather than naming a protocol.