NCEA Level 3 Digital Technologies common mistakes
NCEA Level 3 Digital Technologies · Understand the traps and how to avoid them.
The candidate describes what a system or program does at a surface level ("it stores the data and then shows it") without identifying the specific digital technology concept being assessed, such as the difference between data, information and knowledge, or between input, processing, storage and output, so the answer never engages the achievement standard's key idea.
Candidates write from everyday use of apps and devices rather than from the vocabulary of the subject. They assume the marker will infer the concept from their example, but NCEA Level 3 evidence must show the concept explicitly, and a narrative of user actions does not demonstrate understanding of the underlying model.
What to do instead
Before writing, state the concept in one sentence in the answer (for example "this is an example of redundancy in a relational database because the customer address is repeated in every order record"), then attach the example to it. Practise converting each example into the pattern "concept name + definition in own words + this example + why it fits".
When asked to explain, the candidate gives a description of a sequence of steps ("first you log in, then you click save, then the record appears") instead of explaining cause and effect, trade-offs or consequences, so the response stays at Achieved level and never reaches Merit or Excellence.
The verb in the question is often overlooked. Candidates answer the question they expect ("what happens?") rather than the one asked ("why does it happen, and what is the result?"). Explanation requires a because/so chain that many candidates never construct.
What to do instead
Underline the command word in every question and match the structure to it: describe = what; explain = what + why + consequence; evaluate/discuss = both sides + judgement. For every explanation sentence, force a "because" and a "which means that" clause, and check each paragraph contains at least one of each.
The candidate writes a generic evaluation ("it is faster and more convenient but there are privacy risks") that could apply to any technology, with no reference to the specific context, stakeholders, constraints or data given in the question.
Generic pros and cons are easy to memorise and feel safe under time pressure. Candidates do not extract the specific scenario details, so the judgement is not grounded and cannot be credited as an evaluated decision about this system for these users.
What to do instead
Before writing, list the named stakeholders, the constraints and the data from the scenario. Build each point as "for [named stakeholder], [specific effect], because [mechanism], which matters more/less than [competing factor] because [criterion]". End with an explicit recommendation tied to those criteria.
In programming answers, the candidate writes pseudocode or code that does not match the stated algorithm or specification: off-by-one loop bounds, wrong comparison operator, missing initialisation of an accumulator, or a function that does not return the required value.
Candidates translate their mental model straight to code without tracing it against the specification or a test case. Boundary conditions and initial values are the parts most often skipped because they are not visible in the happy-path example.
What to do instead
After writing code, hand-trace it with the smallest input, an empty input, and one boundary value (first and last element). Check three things explicitly: every variable is initialised before use, loop bounds match the number of items, and every function returns what the spec says. Write the trace table in the answer space; markers credit correct working.
The candidate tests only the normal case. When asked to design or evaluate test data, they supply one typical input and omit invalid, boundary and extreme cases, and do not state the expected output for each test.
Testing is conflated with "checking it works". Candidates have rarely been required to justify test cases, so they do not think in equivalence classes or boundaries, and they leave out expected results because they assume the marker knows what should happen.
What to do instead
For every input, produce a table with columns: test data, type (typical / boundary / invalid / extreme), expected output, reason. Justify each row by naming the equivalence class or boundary it covers. Aim for at least one invalid and two boundary cases per input, and always write the expected result.
The candidate describes a database or information system without distinguishing entities, attributes and relationships, or draws a schema that stores the same fact in multiple places and then cannot explain the resulting update or insertion anomaly.
Candidates model from the screen layout of an app rather than from the data. Repeated fields look natural because they appear together on a form, and normalisation is treated as a vocabulary list rather than a fix for a concrete anomaly.
What to do instead
Identify entities as the things that exist independently (each gets its own table), attributes as facts about one entity, and relationships as links between entities. Then test the design by asking: if this value changes, how many rows must I update? More than one means the fact is stored twice. Explain anomalies with a worked example using actual values from the scenario.
When discussing networks, security or protocols, the candidate names a control or protocol without saying what threat it addresses, how it works, or what its limitation is ("use encryption and a firewall for security").
Lists of security terms are easy to recall and feel like sufficient coverage. Candidates do not link each control to a specific threat in the scenario, so the answer shows recall but not understanding of mechanism or residual risk.
What to do instead
Use a threat-control-residual structure for every security point: name the specific threat in this scenario, name the control, explain the mechanism in one sentence, then state what the control does not stop and what additional control covers that gap. Repeat for at least two distinct threats.
The candidate ignores the implications of digital technologies for people and society beyond a token mention, or states an ethical position without identifying the competing values (for example privacy versus safety, or accessibility versus cost) and without considering the perspective of a group other than the end user.
Social and ethical material is often treated as an add-on paragraph at the end. Candidates default to their own viewpoint and do not systematically consider other stakeholders, so the response lacks the balanced reasoning the standard rewards.
What to do instead
Build a short stakeholder table before writing: group, what they gain, what they risk, what they value. Then write the discussion around the tension between at least two groups, and finish with a justified position that acknowledges the trade-off rather than dismissing one side.
The candidate uses technical terminology imprecisely or interchangeably, for example mixing up data and information, internet and web, authentication and authorisation, or compiler and interpreter, and the imprecision changes the meaning of the answer.
Everyday usage blurs these terms, and candidates have read definitions but not applied them in contrasting examples. Under exam pressure the first word that comes to mind is used, and the marker cannot credit a statement that is technically wrong.
What to do instead
Maintain a personal glossary of confusable pairs, each with a one-line definition and a concrete contrasting example. Before the exam, write each pair into a single sentence that uses both correctly. In answers, define a term the first time it is used if there is any risk of ambiguity.
The candidate runs out of time because they spend too long on early descriptive questions and leave the extended response, which carries the most Merit and Excellence credit, with only a few minutes or unfinished.
Early questions feel safe and are over-written, while the extended response is avoided because it requires judgement. Candidates do not check the mark allocation or plan the paper, so effort is distributed by comfort rather than by value.
What to do instead
In the first two minutes, scan the whole paper and note the mark value and command word of each question. Allocate minutes roughly in proportion to marks, with a hard stop per question. Answer the extended response with a five-minute plan (stakeholders, criteria, judgement) before writing, and keep at least the proportional time for it.