BSEH Secondary Computer Science common mistakes
BSEH Secondary Computer Science · Understand the traps and how to avoid them.
When converting between binary, octal, decimal, and hexadecimal, students mix positional weights across bases, for example computing 1101₂ as 1×2³ + 1×2² + 0×2¹ + 1×2⁰ but then writing the answer as if the digits were decimal place values, or converting 2A₁₆ by treating A as 1.
The digit-to-value mapping is memorised as a table rather than understood as a positional system, and students practise mostly on decimal-to-binary conversions in one direction, so reverse and non-decimal-base conversions expose the gap. Hex letters A–F are especially error-prone because they look like decimal digits.
What to do instead
For every conversion, write the place-value headings above the digits before computing (e.g., 16² 16¹ 16⁰ for hex). Convert hex letters to their decimal values on a separate line first (A=10, B=11, ... F=15). Always check by converting the result back to the original base, and practise all twelve direction pairs (bin↔oct, bin↔hex, etc.), not just decimal pairs.
Students state that ROM is volatile, that RAM retains data when power is off, or that cache is larger and slower than main memory; they also confuse the roles of RAM, ROM, cache, and secondary storage when asked which holds the bootstrap loader or the currently running program.
The terms are learned as a list of acronyms with one-line glosses rather than as a memory hierarchy defined by speed, cost per bit, volatility, and size. Exam questions often test the hierarchy indirectly (e.g., 'where is the OS loaded from at boot?'), so a rote definition is not enough.
What to do instead
Build a single table with columns: volatility, approximate speed, approximate size, typical contents, and example. Fill it from fastest/smallest (registers, cache) to slowest/largest (magnetic/SSD). Then trace the boot sequence explicitly: ROM/BIOS → POST → load OS from secondary storage into RAM. Re-derive the table from memory before each revision session.
When explaining or writing code, students produce off-by-one errors in loops and array/list indexing: using <= with an index that should stop before length, accessing arr[n] on an n-element array, or looping range(1, n) when range(n) was intended, and then failing to notice the resulting wrong output or crash.
Mixing 1-based counting from mathematics with 0-based indexing in Python/C++, plus the inclusive/exclusive boundary of range() and of loop conditions, creates a persistent mental mismatch. Students also test only with small or convenient inputs where the bug does not show.
What to do instead
Adopt a fixed convention and write it down: 'valid indices are 0 to n−1'. Before coding a loop, write the first and last index values on paper. Trace the loop manually for n=1, n=2, and n=3. In Python, prefer for x in lst or enumerate when the index itself is not needed, which removes the boundary decision entirely.
Students confuse = with == (and forget that in C++ an assignment inside a condition evaluates to the assigned value), misuse operator precedence in expressions such as a + b * c > d, and write conditions that combine and/or without parentheses, producing logic that runs but gives the wrong branch.
Assignment and equality look almost identical, and precedence tables are rarely internalised because students write short expressions that happen to work. Errors are silent: the program compiles and runs, so the mistake survives testing.
What to do instead
Always parenthesise compound conditions: if ((a > 0) and (b > 0)). When comparing a variable to a constant in C++, write the constant first (if (5 == x)) so a stray = becomes a compile error. Before running, evaluate each sub-expression and write its value beside it. Add at least one test case designed to hit each branch of every condition.
Students declare variables with the wrong type or scope: using an integer variable for division and losing the fractional part (7/2 giving 3), reading input without converting it from string in Python, or referencing a variable outside the block or function where it was defined (including C++ block scope and Python's local/global distinction).
Dynamic typing in Python hides type errors until runtime, while C++ requires declarations that beginners copy without understanding. Integer division and input-as-string are classic silent failures that produce plausible-looking but wrong answers.
What to do instead
For each variable, write its intended type and range before coding. In Python, wrap input explicitly (int(input()), float(input())) and use / or // deliberately. In C++, choose int, double, or char consciously and initialise at declaration. Keep variable declarations close to first use, and if a name is needed outside a block, declare it in the enclosing scope.
Students describe a database as a single table or a file, and cannot distinguish a primary key from a foreign key, a field from a record, or DDL from DML. Asked to design tables for a simple scenario, they store repeated data in one table and create update anomalies, or pick a name as primary key when names can repeat.
Database concepts are memorised as vocabulary without practising design. The relational model is usually taught through definitions rather than through a small worked schema, so the purpose of keys and normalisation never becomes concrete.
What to do instead
Practise with a two-table schema (e.g., Students and Marks, linked by StudentID) and write out sample rows. For every proposed primary key, ask 'can two records share this value?'. Identify foreign keys by asking 'which column points to another table's primary key?'. Classify each SQL statement you meet as DDL (CREATE, ALTER, DROP) or DML (SELECT, INSERT, UPDATE, DELETE).
Students mix up the OSI/TCP-IP layers and place devices or protocols at the wrong layer: calling a switch a Layer 3 device, putting IP at the transport layer, or saying TCP is used for streaming video and UDP for file download. They also confuse an IP address with a MAC address and a hub with a switch.
Layering is taught as a list to memorise, and the device/protocol mapping is learned separately from the layer definitions. Without a mental model of what each layer actually does, the associations are arbitrary and easily swapped under exam pressure.
What to do instead
Learn each layer by its job and its data unit: physical (bits), data link (frames, MAC, switch), network (packets, IP, router), transport (segments, TCP/UDP, ports), application (HTTP, DNS, SMTP). For each protocol, ask 'what does it guarantee and what does it carry?' to place TCP versus UDP. Draw the encapsulation diagram (data → segment → packet → frame → bits) from memory once per revision.
Students answer cyber-safety questions with generic advice such as 'be careful online' or 'use a strong password', and cannot name the specific mechanism: they cannot explain how phishing differs from pharming, what a digital footprint is, why HTTPS matters, or what to do first after an account compromise. They also treat plagiarism and copyright as the same issue.
These topics are often revised by skimming lists of tips rather than by analysing scenarios. Examiners ask situational questions ('a link in an email asks you to re-enter your password'), and a vague slogan does not answer them.
What to do instead
For each threat, write a one-line definition, a concrete example, and a specific countermeasure (phishing → verify sender domain and never follow credential links → report and delete). Learn the incident-response order: disconnect, change passwords from a clean device, enable 2FA, report. Distinguish plagiarism (unattributed use of others' work) from copyright infringement (unauthorised use regardless of attribution).
Students describe emerging technologies with hype rather than mechanism: saying AI 'thinks like a human', cloud computing 'is the internet', or blockchain 'is Bitcoin', and being unable to state one real benefit and one real limitation of each technology in a given application.
These topics are learned from news headlines and marketing language, and the syllabus usually tests them through application scenarios rather than definitions. Without a mechanism, students cannot match a technology to a use case.
What to do instead
For each technology (AI/ML, cloud, IoT, blockchain, AR/VR, big data), write a three-part card: what it does mechanically, one suitable application, one limitation or risk. For example, cloud: remote servers providing on-demand computing; suitable for scalable storage and collaboration; risk of dependency on connectivity and data-location concerns. Practise matching scenarios to technologies using these cards.
In practical work and projects, students submit code that runs only on the exact input they tested, omit comments and meaningful variable names, ignore file-handling errors (opening a missing file without handling it), and cannot explain their own code when questioned. They also fail to close files or use context managers, leaving data unwritten.
Practical marks reward process and understanding, not just a working demo. Students optimise for 'it works once' and skip validation, documentation, and reflection, which are exactly what the laboratory and project criteria assess.
What to do instead
Adopt a checklist before submission: test with normal, boundary, and invalid input; use with open(...) as f for all file operations; add a short comment for each function explaining its purpose; name variables descriptively. Keep a brief project log recording what you tried and what failed. Before the viva, walk a partner through your code line by line and answer 'why did you choose this approach?'.