SACE Stage 2 Digital Technologies common mistakes
SACE Stage 2 Digital Technologies · Understand the traps and how to avoid them.
When asked to decompose a problem, the candidate lists the features of the final product (e.g. 'login page, dashboard, database') rather than the sub-problems that must be solved and how they relate, so no structure or ordering is shown.
Students equate 'break it down' with 'list the screens'. They have practised building apps but rarely articulate the hierarchy of a problem, so they default to a components list that looks organised but shows no decomposition logic.
What to do instead
Practise rewriting feature lists as a labelled hierarchy: state the top-level problem, then 3-5 sub-problems, then for each sub-problem one sentence naming its inputs, its output and which other sub-problem depends on it. Check every sub-problem is a question to be solved, not a screen or file.
The candidate writes pseudocode or an algorithm that is ambiguous at branch points: loops with no explicit termination condition, conditionals that omit the else case, or steps whose order is left to the reader.
Students write algorithms while holding the solution in their head, so they skip steps that feel obvious. They also confuse pseudocode with a rough sketch and do not test it against a sample input before moving on.
What to do instead
After writing any algorithm, dry-run it with one normal input and one edge input (empty, zero, maximum), writing each variable's value line by line. Require every loop to state its start, its continuation test and its update, and every conditional to state what happens when the test is false.
When tracing code or a data structure by hand, the candidate records only the final output and omits the intermediate states of variables, counters or pointers, so partial credit for method is lost and errors cannot be located.
Students treat tracing as 'work out the answer' rather than 'show the machine's state'. Under time pressure they collapse several iterations into one line and lose track of a variable that changes inside the loop.
What to do instead
Use a fixed trace table with one column per variable plus output, one row per iteration or step, and cross out the old value when it changes. Never write a value without the step number that produced it, and finish by stating the final output separately.
The candidate answers a design question with a generic statement ('I used a clean layout and good colours') instead of naming the specific design decision, the alternative rejected, and the reason tied to the stated user or purpose.
Students believe design justification is about expressing personal taste. They have not been taught that the marker needs a decision, an alternative and a criterion, so they produce adjectives rather than reasoning.
What to do instead
Use a three-part sentence for every design choice: 'I chose X rather than Y because [criterion from the brief, e.g. readability for older users / load time on mobile]'. Aim for at least three such sentences covering layout, navigation and one accessibility feature, each naming the rejected option.
In the development question, the candidate describes what the finished system does but never explains how it was built, tested or revised, so the iterative nature of development is invisible.
Students conflate 'development' with 'product description'. Their project logs record screenshots of finished screens rather than decisions, bugs found and changes made, so they have nothing to draw on in the exam.
What to do instead
Rehearse a three-cycle development narrative: cycle 1 what was built and which test failed, cycle 2 what was changed in response and the evidence it improved, cycle 3 what remained and why it was accepted or deferred. In the exam, write it as cause and effect, not as a feature list.
The candidate describes a validation or verification technique without distinguishing the two, or claims data is 'validated' when only a data-type check was applied to a field that needed a range, uniqueness or referential check.
The terms sound interchangeable in everyday use, and students memorise a list of checks without mapping each check to the kind of error it actually prevents. They also forget validation cannot confirm the data is true.
What to do instead
Learn a two-column table: validation (is the input acceptable? type, range, length, format, presence, uniqueness, referential integrity) versus verification (is the data accurate? double entry, visual check, check digit, hash). For each scenario, name the specific check, the error it catches, and one error it cannot catch.
When interpreting a chart, table or query result, the candidate reports what the numbers are but draws no conclusion, or draws a conclusion the data cannot support (causal claim from a correlation, or a trend from too few points).
Students read data displays as comprehension tasks ('state the highest value') rather than as evidence for a decision. They are also untrained at spotting sampling, missing-data and axis problems.
What to do instead
Answer in three moves: state the pattern with a figure and its units, state one limitation of the data (sample size, missing values, time period, axis scale), then state a decision or further question the pattern justifies. Ban the words 'proves' and 'causes' unless the question supplies an experiment.
The candidate describes how a component works (e.g. 'the router sends packets') without linking it to the layer, protocol or purpose in the system being asked about, so the answer is a definition rather than an explanation of the system.
Students revise components in isolation as glossary items. When a question asks how a system achieves a function, they retrieve the definition they memorised rather than tracing the path through the system.
What to do instead
For each system studied, draw a request-to-response path (client, network, server, storage) and label each hop with the device, the protocol and the data format. In the exam, answer by walking that path in order and stating what each stage contributes to the requested function.
On impacts questions, the candidate lists only benefits or only risks, and gives generic social effects ('it saves time', 'it invades privacy') with no named stakeholder, no mechanism and no trade-off.
Students treat impacts as opinion writing and reach for familiar phrases. They do not identify who is affected or trace the causal chain from the technology to the effect, so the answer cannot be credited as analysis.
What to do instead
Use a stakeholder grid: for two named groups (e.g. workers, customers, a regulator), state one benefit and one harm each, the mechanism by which it occurs, and one mitigation with who is responsible. Finish with a one-sentence judgement naming the group that bears the most risk and why.
The candidate leaves ethical, legal and security answers at the level of principle ('they should be ethical', 'the law says protect data') without naming the specific obligation, the control that meets it, or the consequence of failing.
These topics are taught as discussion, so students absorb the vocabulary of concern but not the concrete instruments: consent, purpose limitation, access control, encryption, audit logs, breach notification.
What to do instead
Build a matching drill: for each obligation (consent, data minimisation, security, retention, disclosure), write the technical or procedural control that satisfies it and the harm that follows if it is missing. In the exam, answer with obligation, control and consequence in that order.