ASSEB HS Computer Science and Application common mistakes
ASSEB HS Computer Science and Application · Understand the traps and how to avoid them.
When converting between binary, denary, and hexadecimal, candidates convert the whole string as one number (for example reading binary 1101 as 'one thousand one hundred and one') instead of treating each position as a power of two, and they drop leading zeros when writing the final answer.
School arithmetic trains decimal place value so strongly that candidates read digit strings left-to-right as decimal magnitudes, and they treat leading zeros as 'nothing' rather than as significant bit positions that determine the value and the required register width.
What to do instead
Always annotate place values above the digits (128 64 32 16 8 4 2 1) before adding, group binary into nibbles from the right when converting to hex, and state the bit width explicitly (for example '0000 1101 in 8 bits = 0D'). Practise 20 conversions per session and mark your own work against the place-value table.
Candidates build a truth table or Karnaugh map for a logic circuit but fill in output columns by guessing from the circuit diagram's overall 'look' rather than evaluating gate by gate, and they forget that NAND and NOR are inverted outputs, producing a table that is internally inconsistent.
Circuit diagrams are read visually as flow, so candidates trace a path once and generalise; the negation in NAND/NOR is easy to lose because the bubble is a small symbol and the intermediate column is usually omitted.
What to do instead
Insert an explicit intermediate column for every gate output, label each column with the wire name, and evaluate row by row using only the previous columns. Verify by checking that a NAND column is the exact inverse of the corresponding AND column for every row.
On tracing questions, candidates execute a loop or recursive call once or twice, then write down the value they expect at the end instead of maintaining a table of variable values for every iteration, so off-by-one errors at the loop boundary and accumulator initialisations go undetected.
Tracing feels slow and candidates believe they can 'see' the pattern; loops that run n versus n-1 times and accumulators initialised to 1 instead of 0 produce plausible-looking but wrong answers.
What to do instead
Use a dry-run table with one column per variable and one row per iteration, including the final failed test that exits the loop. Circle the boundary iterations (first, last, and the one that terminates) and compare your final value against a hand-computed small case such as n=3.
Candidates describe an algorithm's efficiency only as 'faster' or 'slower' without identifying growth in terms of input size, and they claim a linear search is better than a binary search because it needs no sorting, without stating the precondition or the comparison counts.
Efficiency is taught informally as speed on a particular machine, and candidates conflate implementation convenience with asymptotic cost; the sorting precondition of binary search is often memorised as a phrase rather than understood as a requirement.
What to do instead
For every algorithm question, state the input size n, count the key operation, and give the order of growth with a one-line justification (for example 'each comparison halves the search space, so at most log2 n comparisons'). When comparing, specify the scenario: unsorted data, one-off search, or repeated searches after a single sort.
Candidates confuse a stack with a queue and implement the wrong end: they push and pop at the same end for a queue, or they describe a queue as LIFO, then produce a trace that contradicts their own description.
The abstract behaviour is memorised as two acronyms (LIFO, FIFO) without being tied to a concrete operation sequence, and both structures are drawn as the same box with arrows, so the diagram does not force the distinction.
What to do instead
Anchor each structure to a physical analogy and a mandatory trace: stack as plates (push/pop at the top only), queue as a bus queue (enqueue at the rear, dequeue at the front). For every question, write the operation sequence and the resulting contents after each step before answering.
When asked to normalise a relation or identify a primary key, candidates pick an attribute that is unique in the sample data shown rather than one that is guaranteed unique by the domain, and they leave repeating groups in first normal form.
Sample rows make any column with distinct values look like a key, and normalisation is memorised as definitions (1NF, 2NF, 3NF) rather than applied as a test on functional dependencies.
What to do instead
For each candidate key, ask whether the business rules forbid duplicates ever, not whether the sample has duplicates. Write the functional dependencies explicitly (A -> B), then test each normal form in order: no repeating groups (1NF), no partial dependency on part of a composite key (2NF), no transitive dependency (3NF).
Candidates describe the TCP/IP layering or the role of a router, switch, and hub using only the word 'sends data', without naming the addressing used at that layer or the device's decision rule, so answers cannot be distinguished from one another.
These topics are learned as vocabulary lists, and the exam expects the mechanism (IP address versus MAC address, forwarding table versus MAC address table), which candidates never practise articulating.
What to do instead
For each device and layer, memorise a three-part sentence: what it addresses, what table or rule it uses, and what it does with an unknown destination. For example: a switch forwards by destination MAC using its MAC address table and floods if the address is unknown; a router forwards by destination IP using its routing table and drops if there is no route.
Candidates answer security scenarios by naming a control ('use a firewall', 'encrypt it') without stating the threat it addresses, where it sits, and what it does not protect against, so the answer is generic and misses the marks for the specific attack described.
Security is revised as a list of technologies, and candidates do not practise mapping threat to control; they also conflate authentication with authorisation and encryption with hashing.
What to do instead
Use a fixed answer frame: threat, asset, control, placement, residual risk. Distinguish hashing (integrity, one-way) from encryption (confidentiality, reversible with a key) and authentication (who you are) from authorisation (what you may do) every time you write an answer.
In software development questions, candidates list the stages of a lifecycle model as a sequence of names but cannot say what artefact each stage produces or how iteration changes the order, and they recommend a model without linking it to requirement volatility or team size.
Lifecycle models are memorised as flowcharts, and the exam often asks for a justified choice; candidates reproduce the diagram instead of reasoning about risk, feedback, and deliverable timing.
What to do instead
For each model (waterfall, iterative, agile), memorise the deliverable per stage and the condition under which it is preferred. Practise writing two-sentence justifications that name the project characteristic (fixed requirements, high uncertainty, small co-located team) and the resulting benefit.
Candidates treat ethical and societal questions as opinion pieces, giving an unsupported view or restating the scenario, instead of identifying the stakeholders, the competing values, and a relevant legal or professional obligation before reaching a judgement.
These questions look like free marks, so candidates write a paragraph of general agreement; the mark scheme rewards structured reasoning about impact on named groups and reference to codes or law.
What to do instead
Use a stakeholder-impact frame: list at least three stakeholders, state the benefit and harm to each, name the relevant principle (privacy, consent, accessibility, intellectual property) or law, then give a balanced conclusion with one condition that would change your view.