BSEH SS Computer Science common mistakes
BSEH SS Computer Science · Understand the traps and how to avoid them.
When converting between binary, octal, decimal and hexadecimal, the candidate groups bits from the left (or from the decimal point outward) instead of grouping in threes or fours starting at the radix point, so 1101011₂ is written as 153₈ instead of 6B₁₆/153₈ being derived correctly from the right.
Textbooks show place values left to right and candidates mirror that visual order; they also forget that the fractional part is grouped rightward from the point, not leftward. Under exam time pressure they skip re-checking the grouping direction.
What to do instead
Before every conversion, draw the radix point and mark groups outward: for octal, groups of 3 bits going left from the point for the integer part and right from the point for the fraction; for hex, groups of 4. Practise ten mixed conversions and verify each by converting back to decimal and comparing.
The candidate computes 2's complement of a negative number by flipping bits but forgets to add 1, or adds 1 to the wrong bit position, producing off-by-one answers for ranges and subtraction questions.
The two operations (invert, then add 1) are taught together and candidates compress them into one step; carry propagation across a long bit string is also error-prone when done mentally.
What to do instead
Write the two steps on separate lines every time: line 1 original, line 2 inverted, line 3 inverted + 1 with the carry shown. Then check by adding the result to the original magnitude; the sum must be a power of two (e.g. 1000 0000 for 8 bits).
When tracing a short Python program, the candidate reads the code top to bottom and assumes each line runs once, missing that a loop body executes repeatedly and that variables keep their last value across iterations.
Novice readers treat code as a narrative rather than as state evolving over time; they also confuse printing inside a loop with printing after it. Exams often place the print statement at a different indentation level to test exactly this.
What to do instead
Trace with a table: one column per variable, one row per iteration, and a separate column for output. Fill a row only after executing the whole loop body. Circle the indentation level of every print to confirm whether it is inside or outside the loop before starting.
The candidate confuses list methods that mutate in place with those that return a new value: they write `x = mylist.sort()` or `mylist = mylist.append(4)` and then report None or the wrong list contents.
String methods like upper() return new values, so candidates generalise that all methods return results. The None return of sort() and append() is silent and produces no error message to warn them.
What to do instead
Memorise the short list of in-place mutators (append, extend, insert, remove, pop, sort, reverse) as returning None, and the non-mutating ones (sorted, reversed, slicing, +) as returning new objects. When reading code, annotate each call with 'returns None' or 'returns value' before predicting output.
When asked for the output of stack or queue operations, the candidate applies the operations in the order written on the page rather than the order in which the data structure releases elements, so a queue question is answered with LIFO behaviour or vice versa.
Both structures are drawn as linear lists, and the only difference is which end is used; candidates remember 'stack' and 'queue' as vocabulary but not the access rule under time pressure.
What to do instead
At the top of every such question write 'stack = LIFO, top only' or 'queue = FIFO, front out / rear in'. Then simulate with a drawn box and an arrow marking the active end, crossing out removed items rather than erasing them so the sequence can be checked.
The candidate writes SQL that returns rows but not the requested rows: they use WHERE instead of HAVING with aggregate conditions, or omit GROUP BY when an aggregate is mixed with a plain column, and then cannot see why the result is wrong.
WHERE and HAVING look interchangeable in simple examples, and many practice queries never combine aggregates with grouping. Candidates also test logic mentally instead of against sample data.
What to do instead
Apply the rule: filter individual rows with WHERE before grouping, filter groups with HAVING after grouping. Whenever SELECT contains an aggregate plus a plain column, write the GROUP BY clause first. Then test the query on a tiny hand-written table of three or four rows and check each output row by hand.
When identifying devices or protocols, the candidate labels anything that connects a network as a 'router' and treats switch, hub, bridge, modem and gateway as synonyms, or places protocols in the wrong layer of the TCP/IP or OSI model.
The devices are physically similar boxes and the exam wording ('connects two networks') is close to the wording for a switch ('connects devices within a network'). Layer placement is memorised as a list without a functional anchor.
What to do instead
Learn one discriminating question per device: does it forward by MAC address within one network (switch), broadcast to all ports (hub), or forward by IP address between networks (router)? For layers, attach a protocol and a unit to each: application (HTTP, message), transport (TCP, segment), internet (IP, packet), link (Ethernet, frame).
The candidate writes HTML with unclosed or improperly nested tags and then claims the page will not display, or uses deprecated presentational tags and inline styling where the question asks for structure and semantics.
Browsers are forgiving and render malformed markup, so candidates never see the consequence of bad nesting. Teaching examples often show bold and centre tags, which candidates copy as correct practice.
What to do instead
Adopt a closing-tag-first habit: type the opening tag, immediately type the closing tag, then fill the content. Nest by matching the most recently opened tag. For semantics, replace presentational tags with structural ones (headings, lists, emphasis, strong) and put appearance in CSS. Validate by reading the nesting aloud as brackets.
The candidate answers cyber-safety scenarios by naming a technology ('use a firewall', 'install antivirus') without identifying the specific threat or the specific user action, so answers are too vague to earn marks on phishing, strong passwords, or data-protection questions.
Safety content is often revised as slogans rather than as cause-and-effect. Candidates also conflate prevention with detection and response, and do not distinguish technical controls from user behaviour.
What to do instead
For each scenario, write three lines: the threat named precisely (phishing email, weak reused password, unpatched software), the mechanism by which harm occurs, and one control matched to that mechanism (verify sender domain; unique passphrase plus a password manager; apply updates). Rehearse with five realistic scenarios and mark which control addresses which threat.
In the practical or project component, the candidate writes the whole program before running it, then cannot locate errors, or submits a project without the required documentation of testing, so functional marks are lost despite working code.
School exercises often reward finished output rather than incremental testing, so candidates never build the habit. Project documentation requirements are read once at the start and forgotten by submission time.
What to do instead
Work in small increments: write one function or block, run it with a single test input, then continue. Keep a test log with input, expected output and actual output for each case, including one invalid input. Before submission, re-read the project brief and tick each required artefact (code, test log, user guide, limitations) against the list.