MATSEC SEC Computing common mistakes
MATSEC SEC Computing · Understand the traps and how to avoid them.
When converting between binary, denary and hexadecimal, the candidate reads the digits left to right and treats each position as worth 1, 2, 3... instead of powers of the base, so 1101₂ is written as 1+1+0+1 = 3 rather than 13.
Place value is taught first in denary, and many candidates never replace the familiar 1, 10, 100 pattern with 1, 2, 4, 8 for binary or 1, 16, 256 for hexadecimal. Under exam pressure they fall back on the denary habit. The mistake also appears in reverse when converting denary to binary: candidates subtract the wrong power because they start from the largest bit position they remember rather than from the value itself.
What to do instead
Before every conversion, write the place-value row above the digits: 8 4 2 1 for a 4-bit binary number, 16 1 for a two-digit hex number. Then work digit by digit, multiplying each digit by its place value and adding. For denary to binary, repeatedly divide by 2 and read the remainders bottom to top, and check the answer by converting it back. Practise five conversions in each direction per session until the place-value row is automatic.
When asked to explain the fetch-decode-execute cycle or the role of a register, the candidate names the components ('the PC, the MAR, the MDR, the accumulator') without describing what happens to the data or in what order, so no marks are awarded for the process.
Register names are easy to memorise as a list, and revision cards usually present them that way. Candidates learn the vocabulary without building a mental model of data moving between memory and the CPU, so they cannot produce the sequence of steps an explanation question requires. The same gap appears in questions about pipelining or the purpose of cache.
What to do instead
Learn the cycle as a story with named actors: the PC holds the address of the next instruction, that address goes to the MAR, the instruction arrives in the MDR via the data bus, the PC increments, the control unit decodes, and the ALU executes. Write the cycle from memory in six numbered steps, then answer past-style questions in full sentences using those steps. For each register, write one sentence saying what it holds and when it is used.
When describing how a network delivers data, the candidate treats the OSI or TCP/IP layers as a list to be named rather than explaining what each layer does to the data, and cannot say where encapsulation, routing or error checking happens.
Layer models are often presented as a diagram to be labelled, so candidates memorise the names in order. Questions that ask 'describe what happens at the transport layer' or 'explain the role of the network layer in routing' then expose that no functional understanding exists. The mistake is compounded by confusing the two models, so a layer from one is placed in the other.
What to do instead
For each layer, write a one-sentence job description and a concrete example of the data unit it handles (frame, packet, segment). Then trace a single request, such as loading a web page, down the sender's stack and up the receiver's, naming at each step what is added or read. Answer layer questions by stating the function first, then the example, rather than listing names.
When asked to compare a circuit-switched and a packet-switched network, or a LAN and a WAN, the candidate gives two separate descriptions instead of making point-by-point comparisons, and omits the criterion (latency, cost, reliability) that the comparison should be judged on.
Candidates read 'compare' as 'describe both things' and write two paragraphs that never meet. They also lack a framework of comparison criteria, so they repeat the same feature twice. Mark schemes award comparison marks for paired statements against a named criterion, which this structure cannot earn.
What to do instead
Use a two-column table with the criteria as row headings: setup, path, delay, cost, failure behaviour, suitability. Fill both columns for each row, then convert each row into one comparative sentence ('packet switching shares links so it is cheaper, but packets may arrive out of order'). Practise by writing three paired sentences for any two technologies before writing any prose.
When tracing a sorting or searching algorithm by hand, the candidate writes only the final sorted array or the found index, skipping the intermediate states that the question asks for, and loses the trace marks even when the answer is right.
Candidates see the algorithm as a means to an answer rather than as a process to be demonstrated. They also run out of time and compress the trace. Because the final state is easy to check mentally, they assume it is what is being marked, when the marks are usually allocated per pass or per comparison.
What to do instead
Read the command word: 'trace', 'show each pass' and 'complete the table' all require every intermediate state. Use a table with one row per pass or comparison and fill every cell, even repeated values. Before the exam, trace bubble sort, insertion sort, merge sort, linear search and binary search on the same small list, and count how many rows each produces so you know the expected volume of working.
When asked for the efficiency of an algorithm, the candidate writes 'it is fast' or 'it is slow' instead of naming the complexity class, and cannot distinguish the best, average and worst case for the same algorithm.
Big-O notation is often introduced late and treated as an optional extra, so candidates fall back on informal adjectives. They also conflate the number of comparisons with the number of operations, and do not realise that binary search has a best case of one comparison but still a logarithmic worst case.
What to do instead
Memorise a short table: linear search O(n), binary search O(log n), bubble and insertion sort O(n²), merge sort O(n log n). For each, write one sentence on the best, average and worst case with the reason (for example, insertion sort is O(n) on already sorted data because no shifts are needed). Answer efficiency questions with the notation first, then the justification.
When writing pseudocode or program code, the candidate uses the wrong loop for the job (a for loop when the number of repetitions is unknown), or mixes constructs from different languages in one answer, producing code that would not run.
Candidates choose loops by habit rather than by the termination condition, and pseudocode guidance in different textbooks uses different keywords, so mixed syntax looks acceptable to them. Under time pressure they also omit initialisation of counters and accumulators, which is the most common cause of a program that runs but gives wrong output.
What to do instead
Before writing any loop, state in one line whether the number of repetitions is known; if it is, use a counted loop, otherwise use a condition-controlled loop. Pick one pseudocode convention at the start of the paper and apply it throughout. After writing, dry-run the code with a small input, writing each variable's value line by line, and check that every counter and accumulator is initialised before the loop.
When asked to test a program, the candidate supplies only normal or typical data and omits boundary values, invalid data and erroneous data, so the test plan earns only a fraction of the marks.
Candidates test the way they would use the program themselves, with sensible inputs, because that is the only use they have seen. They do not think of a test as an attempt to make the program fail, and they do not systematically derive categories from the specification's stated ranges.
What to do instead
For every input with a stated range, generate at least four tests: a typical value inside the range, the lower boundary, the upper boundary, and a value just outside the range. Add one test for wrong data type and one for missing input. Present tests in a table with input, expected output and reason for choosing that input, so the examiner can see the category being covered.
When designing a database, the candidate puts all attributes in one table, or creates a table with no primary key, and then cannot explain why the resulting design causes update, insert and delete anomalies.
Candidates model the form they were given rather than the entities behind it, so a single 'order' form becomes a single table. Normalisation is learned as a set of definitions rather than as a repair procedure, so the candidate can recite 'second normal form removes partial dependencies' but cannot spot one in their own design.
What to do instead
Start by listing the entities (the nouns that exist independently) and the relationships between them, then give each entity its own table with a primary key. Test the design by asking what happens when one fact changes, when a new row is inserted and when a row is deleted; if any answer requires changing or losing more than one row, split the table. Then practise taking a flat table to third normal form by removing repeating groups and partial dependencies step by step.
When asked about a current or emerging technology such as cloud computing, artificial intelligence or the Internet of Things, the candidate writes a general description of the technology and never addresses the specific issue in the question, such as security, privacy, bandwidth or legal responsibility.
These topics are often revised from news articles, which supply enthusiasm and examples but not the trade-offs the syllabus expects. The candidate recognises the keyword and reproduces what they know, without checking what the question actually asks about it.
What to do instead
For each emerging technology, prepare a four-part note: what it is, one concrete benefit, one concrete risk, and one mitigation or regulation. Underline the focus of the question (security, cost, ethics) before writing, and make every sentence connect to that focus. Where a scenario is given, name the specific data or device involved rather than speaking about the technology in general.