MATSEC IM Computing common mistakes
MATSEC IM Computing · Understand the traps and how to avoid them.
When asked to convert between binary, denary and hexadecimal, the candidate converts in one direction only and then writes the reverse answer by inspection, producing digits that do not check out (e.g. stating 1101₂ = 13 but then writing 15 for 1111₂ because they counted the four 1 bits).
Candidates learn a single worked method (repeated division or place-value addition) and rush the reverse step without re-applying it, relying on pattern-matching from practice questions rather than the algorithm.
What to do instead
Always convert back to verify: after producing a hex or binary answer, convert it once more in the opposite direction and compare. Practise place-value addition for binary-to-denary and repeated division by 16 for denary-to-hex until both directions are automatic; show the place-value headings (128 64 32 16 8 4 2 1) in the working so the examiner can see the method and partial credit is available.
Explaining the role of the fetch-decode-execute cycle or of a named register by giving a one-word label ('the PC holds the address') without saying what is fetched, from where, in what order, or what happens to the value afterwards.
Candidates memorise register names as a list and treat the cycle as vocabulary rather than a sequence of transfers; the syllabus wording is terse, so they assume the label alone earns the mark.
What to do instead
Write the cycle as a numbered sequence of transfers, naming source and destination each time: PC holds address of next instruction → address copied to MAR → instruction fetched to MDR → copied to CIR → decoded by the control unit → PC incremented. For each register, state what it stores, its size implications, and one consequence of it (e.g. why the PC must increment before execution of a jump).
Confusing the properties of primary and secondary storage, or of RAM and ROM, in a comparison question - for example claiming RAM is non-volatile, that ROM is directly writable by programs, or that cache is larger than main memory.
Everyday use of the words 'memory' and 'storage' blurs the distinction, and revision lists present RAM/ROM as a table of adjectives that candidates recall in the wrong order under time pressure.
What to do instead
Anchor each property to a consequence rather than a label: RAM is volatile because it needs constant power to hold charge, which is why work is saved to secondary storage before shutdown; ROM is non-volatile and read-only because it holds the bootstrap loader that must survive power-off. Use a comparison grid with the axes volatility, writability, typical capacity, cost per byte, and proximity to the CPU, and fill it from first principles each time rather than reciting it.
Writing pseudocode that is logically correct in the candidate's head but syntactically ambiguous on paper - undeclared variables, assignment written as '=', loops with no explicit termination condition, or indentation that does not match the intended block structure.
Candidates draft algorithms as prose-like sketches and never trace them line by line; because they know what they meant, they cannot see the ambiguity a marker will see.
What to do instead
Adopt one fixed pseudocode convention (declare variables, use ← for assignment, explicit ENDWHILE/ENDFOR, indented blocks) and use it in every answer. Before moving on, hand-trace the algorithm with a table of variable values for at least two inputs, one of which triggers the loop's exit condition; if the trace needs a value that was never initialised, the answer is incomplete.
When asked to find or fix an error in a given algorithm, the candidate rewrites the whole algorithm from scratch instead of identifying the specific faulty line and explaining the effect of the fault.
Candidates are more confident writing their own solution than reading someone else's code, and the question format ('the algorithm contains an error') invites a full rewrite; they also fear that pointing at one line looks too short an answer.
What to do instead
Answer in three parts: quote the faulty line, state what it does now, state what it should do and the observable symptom (e.g. 'the loop runs one time too many because the condition uses < rather than <=, so the last element is never processed'). Then give the minimal corrected line only. Practise by taking working algorithms and injecting single faults (off-by-one, wrong operator, swapped variables) and describing each in one sentence.
Describing a standard algorithm (linear search, binary search, bubble sort) by name and purpose but omitting the precondition or the step-by-step behaviour - for example recommending a binary search on an unsorted list, or describing a bubble sort without mentioning the repeated passes and swaps.
Candidates learn algorithms as definitions to be recognised rather than procedures to be executed, so the sorted-input precondition and the pass structure are the first details lost.
What to do instead
For each algorithm, memorise four things: precondition, the loop structure in one line, best and worst case, and one worked trace on a five-item list. State the precondition explicitly whenever you name the algorithm ('binary search requires the list to be sorted; on an unsorted list it may discard the target'). Write out the trace with the list after each pass so the marker sees the swaps.
Designing a database table that stores repeating groups in one field (e.g. a single 'modules' column holding several module codes), then claiming the design is normalised because each row has a primary key.
Candidates equate 'has a primary key' with 'is normalised' and build tables from the flat spreadsheet view of the data they were given, without testing each field for atomicity and dependency on the whole key.
What to do instead
Test every field against three questions: is it atomic (one value only)? does it depend on the whole primary key, not part of it (2NF)? does it depend on anything other than the key (3NF)? Split repeating groups into a separate table with a composite or surrogate key and a foreign key back to the parent. Show the before-and-after schemas side by side so the decomposition is visible.
Writing a SELECT query that returns the right columns but the wrong rows - using WHERE on an aggregated value, omitting GROUP BY when an aggregate is used with a plain column, or using = NULL instead of IS NULL.
Candidates translate the English question word by word into SQL clauses without considering evaluation order, and they have usually practised only single-table queries without aggregates.
What to do instead
Write queries in evaluation order: FROM/JOIN, then WHERE (row filtering, before grouping), then GROUP BY, then HAVING (group filtering, after aggregation), then SELECT, then ORDER BY. Check that every non-aggregated column in SELECT appears in GROUP BY. Use IS NULL / IS NOT NULL for null tests. Run each query mentally against a three-row sample table and confirm the row count matches the question.
Answering a scenario question about a real system (a school's attendance system, a hospital's records, a retailer's stock) with generic textbook statements about 'efficiency' and 'accuracy' rather than naming the specific data, stakeholder, and consequence in the scenario.
Candidates revise topics in isolation and treat context questions as an invitation to dump everything they know about the topic; they do not extract the named entities from the scenario before writing.
What to do instead
Before writing, underline the stakeholders, the data items, and the stated problem in the question, then structure the answer as: what the current situation is, what the proposed change does to each named stakeholder, and one concrete benefit and one concrete risk with a consequence ('if the barcode is misread, stock levels drift and reordering is triggered too late'). Every sentence should mention something from the scenario.
Discussing the social, legal or ethical implications of a computing system by listing only advantages, or by treating 'privacy' and 'security' as interchangeable, with no mention of the legislation or of who is accountable.
Candidates see these questions as opinion questions where any reasonable point scores, so they write a one-sided list and use technical and legal vocabulary loosely.
What to do instead
Answer in balanced pairs: for each benefit, state the corresponding risk and who bears it. Keep definitions sharp - privacy is control over who sees personal data, security is protection against unauthorised access - and name the relevant legal principle (data minimisation, purpose limitation, right of access, consent) rather than a bare statute name. Close with a judgement sentence naming the party responsible for mitigation and the measure they would take.