LC Computer Science common mistakes
LC Computer Science · Understand the traps and how to avoid them.
Writing one sentence for a question that says "Give two reasons" or "Describe two impacts", leaving half the marks untouched.
Candidates answer the topic rather than the task: they read the stem, recall what they know about the topic, and write until it feels answered, ignoring the command word and the mark tariff as a signal of how many distinct points are required.
What to do instead
Before writing, underline the command word and any number in the stem, then number your response points to match. As a habit, budget roughly one distinct, developed point per mark and check the count before moving on.
Rewriting a code snippet line by line in English ("it sets x to 0, then it adds 1") instead of explaining what the algorithm achieves or why it is written that way.
A line-by-line translation feels safe because it is obviously true, and candidates worry that an interpretation might be wrong. But translated code earns little credit because it shows the examiner nothing the examiner cannot already read.
What to do instead
Practise the two-sentence pattern: first state the purpose in one sentence ("this counts how many scores exceed the average"), then justify one design choice or one consequence. Only quote specific lines to support that claim.
Using "parameter" and "argument", or "variable" and "constant", interchangeably in written answers and in code comments.
Everyday speech treats these as synonyms, and the confusion survives because code still runs when the words are misused. It only costs marks in the written paper, where precise terminology is what is being assessed.
What to do instead
Build a definition card for each pair and write a single line of code that demonstrates the difference (a parameter in a def line, an argument at the call site; a constant declared once and never reassigned). Use the exact word in every comment and answer for a week.
Tracing a loop and reporting the value after the second-to-last iteration, or stating a loop runs n-1 times when it runs n times.
Trace tables are done in the head rather than on paper, and the final iteration is the one most likely to be skipped because the condition has already been seen to be true several times.
What to do instead
Draw a table with one column per variable plus a condition column, and write a row for the final failing test, not just the passing ones. Sanity-check by asking what happens on the very first and very last pass.
Treating bits, bytes and characters as the same unit, or assuming ASCII and Unicode are interchangeable when reasoning about how text is stored.
Storage sizes are quoted loosely in everyday use ("a 5 MB photo"), so the distinction between the number of characters in a string and the number of bytes it occupies never gets forced into focus.
What to do instead
Work through concrete examples: a five-character ASCII string occupies 5 bytes; the same five characters in UTF-8 may occupy more. Do a handful of conversions between binary, decimal and hexadecimal until the byte/bit relationship is automatic.
Declaring an algorithm "more efficient" or "O(n)" without saying which input measure n counts and which case (best, average, worst) is being described.
Complexity notation is learned as a label to attach to code rather than as a claim about growth. Candidates reproduce the notation without the operational definition, so the justification never appears.
What to do instead
Always write the claim in the form: "n is the number of elements; in the worst case the loop runs n times, so the time grows linearly". Name what n counts, name the case, then name the growth.
Answering an ethics or legal question with "they should keep data safe" or "they need permission" without naming the specific obligation, the stakeholder affected, or the mechanism.
These questions invite moralising, and general goodwill statements feel responsive. Naming a specific legal duty or a concrete technical control requires recall that is easy to skip under time pressure.
What to do instead
Prepare a small set of named anchors: lawful basis and data minimisation for personal data, retention limits, attribution and licence terms for reused code, and accessibility obligations. For each, memorise one sentence linking the duty to a named stakeholder.
Writing a SELECT that filters aggregated results in WHERE instead of HAVING, or describing a join as "combining two tables" without distinguishing inner, left and full behaviour.
Most practice queries filter individual rows, so WHERE becomes the default mental tool. Aggregate filtering appears rarely in beginner material, and the joins are taught with diagrams rather than with the rows that survive.
What to do instead
For each query, state in words whether the condition applies before or after grouping, then choose WHERE or HAVING accordingly. For joins, draw the two small tables and list which rows appear for each join type, including unmatched ones.
Submitting a coursework artefact that works but whose report shows no evidence of iteration: one final version of the code, no test log, no record of a bug found and fixed.
Candidates develop privately and clean up before documenting, believing the report should present the finished product. The specification rewards the process, so tidying away the evidence removes the marks.
What to do instead
Keep a dated development log as you work, not afterwards: one entry per session recording what was attempted, what failed, what changed and how it was tested. Export screenshots of failing tests and the fix as you go.
Choosing a coursework project that is too large to finish, so the artefact stalls at a partly working prototype and the report never links the finished features back to the brief and to computer science concepts.
Ambition is rewarded in the planning phase but the calendar is not. Candidates also treat the report as a diary rather than as an argument connecting requirements, design decisions, testing and evaluation.
What to do instead
Scope to the smallest version that fully satisfies the brief with one clear extension, and freeze the scope early. Structure the report around the requirements list, showing for each requirement the design choice, the test evidence and the evaluation.