IB Computer Science SL common mistakes
IB Computer Science SL · Understand the traps and how to avoid them.
When asked to trace an algorithm or dry-run code, the candidate writes only the final output instead of a table showing each variable's value after every iteration or recursive call.
Past-paper mark schemes award method marks per row and per variable, and candidates assume the answer is the output rather than the working. Many also trace mentally and only write the conclusion, losing the process marks.
What to do instead
Before the exam, practise producing a trace table with one column per variable plus output, one row per iteration, and cross out or update values as they change. On any 'trace' or 'state the output' question, always draw the table first even if you can see the answer, then write the final output on a separate line.
The candidate describes a stack, queue, or linked list in generic prose ('it stores data in order') without naming the defining operations, pointer behaviour, or LIFO/FIFO property, and cannot apply the structure to a given scenario.
Abstract data structures are taught as definitions, so candidates memorise a one-line description and never map the structure to the operations (push/pop, enqueue/dequeue, head/tail pointers) that the question is testing. Scenario questions then feel unfamiliar.
What to do instead
Build a one-page reference for each structure listing: defining property, core operations with their effect on pointers/indices, one real scenario (e.g. queue for print spooling, stack for recursion/call stack), and one pseudocode implementation. Practise rewriting each from memory and answering 'which structure and why' for five scenarios.
In binary and data-representation questions, the candidate converts between binary, denary, and hexadecimal but drops leading zeros, misaligns bit positions, or forgets the sign bit and two's complement range when handling negative numbers.
Candidates learn the conversion algorithm mechanically and rush, so place-value errors and off-by-one range errors (e.g. claiming an 8-bit signed range of -128 to 128) slip through. Two's complement is often memorised as 'flip and add one' without understanding why.
What to do instead
Always write the place-value headings (128, 64, 32, 16, 8, 4, 2, 1) above the bits and pad to the stated width. For signed numbers, derive the range as -2^(n-1) to 2^(n-1)-1 and check with a worked negative example. Do ten mixed conversion drills under timed conditions and mark your own errors by type.
The candidate confuses logical and physical (syntax, runtime, logic) error categories and gives a vague correction such as 'fix the code' rather than naming the exact line and the precise change.
Error-type terminology is often learned as a list of words without contrasting examples, and candidates answer the spirit of the question rather than the command term. 'Identify the error and suggest a correction' is marked on line reference plus a concrete edit.
What to do instead
Memorise one canonical example of each error type (missing semicolon = syntax; division by zero = runtime; wrong comparison operator = logic) and for every practice question write: line number, what is wrong, and the corrected statement in code. Use the command term to decide whether to identify, describe, or explain.
When asked to construct a truth table or simplify a Boolean expression, the candidate omits intermediate columns, skips rows, or applies De Morgan's law incorrectly (e.g. writing NOT(A AND B) = NOT A AND NOT B).
Truth tables are done in a hurry with 2^n rows miscounted, and De Morgan's law is memorised without the swap of AND/OR. Candidates also forget that a full table needs a column for every sub-expression.
What to do instead
Use a fixed layout: list input rows in binary counting order (00, 01, 10, 11), add a column for each bracket and operator, and derive the output column last. For De Morgan, always write both forms side by side and test with one row. Verify any simplification by comparing the final truth table with the original.
In database questions, the candidate writes a query or schema that ignores the stated data types, primary and foreign keys, or referential integrity, and produces a SELECT that returns duplicate or wrongly filtered rows.
SQL is practised on toy examples without constraints, so candidates never internalise why keys exist or how WHERE, GROUP BY, and DISTINCT interact. Schema questions are answered as prose rather than as typed fields.
What to do instead
For every schema question, annotate each field with type, key status, and nullability before writing SQL. Practise queries against a small hand-built dataset and predict the result rows before running them mentally. Learn the key definitions as one-liners: primary key uniquely identifies a record; foreign key references a primary key in another table and enforces referential integrity.
The candidate describes how a computer or network component works in general terms but cannot explain the specific step or consequence the question asks for, such as what happens on a cache miss or why a switch reduces collisions compared with a hub.
Hardware and networking topics are revised as vocabulary lists, so candidates recognise terms like cache, RAM, switch, and router but cannot sequence the process or state the effect. The command term 'explain' requires a cause-and-effect chain.
What to do instead
For each component, write a three-step process chain (what happens, what it fetches/forwards, what happens next) and a one-sentence consequence. Practise 'explain' answers as 'because X, therefore Y' sentences. For networking, compare devices pairwise (hub vs switch, switch vs router) on one criterion at a time.
In the case-study or scenario question, the candidate gives a textbook-generic answer that could apply to any organisation instead of referencing the specific stakeholders, constraints, and data named in the stimulus.
Candidates treat the scenario as decoration and answer from memory. Mark schemes for scenario questions reward application to the given context, so generic answers cap the mark.
What to do instead
Before writing, underline every named entity in the stimulus (users, system, data, constraint) and force at least one reference to each in the answer. Use the pattern 'For [named stakeholder], this means [specific effect] because [named constraint]'. Rehearse with two past scenarios and self-mark against the requirement to mention the context.
The candidate answers a 'discuss' or 'evaluate' question with a one-sided list of advantages and never states a judgement or conclusion, or states a conclusion with no supporting reason.
Extended-response questions are treated like short-answer recall, and candidates run out of time so they drop the evaluative final paragraph. They also confuse 'describe' with 'evaluate'.
What to do instead
Use a fixed structure for evaluate/discuss: two points for, two against, each with a consequence, then a judgement that names the deciding criterion (cost, scale, security, usability). Allocate the last two minutes of any extended answer to writing the conclusion. Practise with a 6-mark question and check that your conclusion would still stand if one point were removed.
The candidate uses the command term loosely, writing a definition when asked to compare, or a list when asked to explain, and does not match the number of points to the mark allocation.
Command terms carry specific mark expectations, and candidates do not check the tariff before writing. A 4-mark 'explain' needs chained reasoning, not four bullet fragments, and a 'compare' needs both items addressed in each point.
What to do instead
Keep a command-term table (state, outline, describe, explain, compare, discuss, evaluate) with the expected depth, and before answering note the marks and plan that many distinct points. For 'compare', write paired sentences covering both items. Check answers against the mark tariff so the number of developed points matches the marks available.