NCEA Level 2 Digital Technologies common mistakes
NCEA Level 2 Digital Technologies · Understand the traps and how to avoid them.
Writing a program's output using print/console statements but never testing with the boundary and invalid inputs the assessment brief specifies (e.g. empty string, zero, negative number, maximum length), so the program only works for the sample data given.
Candidates test with the example data supplied in the task and stop as soon as it 'works'. They treat testing as proving the program runs, not as probing where it breaks, and often have no habit of listing expected inputs before coding.
What to do instead
Before coding, write a short test table: at least one valid, one boundary, and one invalid input per variable, with the expected output for each. After coding, run every row and record actual output. Add explicit checks in code (e.g. range checks, type checks) and show the error message or default behaviour for invalid input.
Using variable names like a, b, x1, temp, or flag throughout a program, and copying and pasting the same block of code with small edits instead of writing a function or loop.
Candidates focus on getting the logic to run and treat naming and structure as cosmetic. Copy-paste feels faster under time pressure, and many have not practised identifying repeated patterns and extracting them into a function.
What to do instead
Adopt a naming rule: nouns for data (student_mark, total_score), verbs for functions (calculate_average, validate_input). Before submitting, scan for any block of three or more near-identical lines and replace it with a function or loop that takes the changing values as parameters. Comment each function with its purpose in one line.
Describing what a circuit or program does ('the LED turns on when the button is pressed') without explaining the underlying concept or justifying design choices (why a pull-down resistor, why that threshold, why that sensor).
Candidates answer the 'what' because it is visible in their work, but exam questions ask for the 'why'. They have often assembled a working circuit from a diagram without understanding each component's role, so they cannot explain it.
What to do instead
For every component and every line of code, be able to answer: what would go wrong if this were removed or changed? Practise writing two-sentence explanations in the form 'X is used because... without it ... would happen'. In answers, always link the component or code to the behaviour it produces.
Ignoring hardware constraints: assuming unlimited power, no debounce on a mechanical switch, no consideration of analogue vs digital pins, or reading a sensor without converting the raw value to a meaningful unit.
Simulators hide real-world problems, and candidates often have not worked with physical components. Switch bounce, voltage limits, and sensor resolution are invisible in a tidy simulation, so they are never considered.
What to do instead
Keep a checklist for every embedded design: power source and voltage, pin type (analogue/digital/PWM), input conditioning (debounce delay or capacitor), and unit conversion with the formula shown. State the checklist explicitly in written answers, e.g. 'a 20 ms debounce delay is needed because a mechanical switch bounces for several milliseconds'.
Treating a database or spreadsheet as a flat list: storing the same information in multiple places, using free text where a code or lookup would do, or failing to define a primary key, leading to inconsistent or duplicate records.
Candidates design from the screen they want rather than from the data. They have rarely normalised a table by hand, so redundancy and update anomalies are abstract ideas rather than something they have seen break.
What to do instead
Before building, list the entities (e.g. student, course, enrolment) and what uniquely identifies each. Split repeating groups into separate tables linked by keys. Test the design by asking: if this value changes, how many places must I edit? If more than one, restructure.
Answering questions about privacy, security, and legal requirements with vague statements ('it is secure', 'they need permission') instead of naming the specific mechanism, legislation, or risk and who is affected.
These topics are often taught as a list of terms to memorise, so candidates recall the label but not how it applies. They also avoid specifics because they are unsure of exact legal names and fear being wrong.
What to do instead
For each scenario, write three lines: the data involved and who owns it, the specific control (encryption at rest, access roles, hashing passwords, retention period), and the consequence if it fails. Learn the purpose of the main privacy principles (collection, storage, access, correction, disposal) rather than only their names, and apply them to the given scenario.
Submitting a media outcome where the design choices are invisible: no evidence of planning, file formats chosen by default, and no explanation of why a colour, font, layout, or compression setting was used.
Candidates spend all their time in the editing tool and treat planning documents as paperwork. Export settings are left at whatever the software suggested, so they never learn the trade-off between file size and quality.
What to do instead
Keep a short design log with date, decision, reason, and alternative rejected. For every export, record format, dimensions, and compression level, and state the trade-off in one sentence (e.g. 'JPEG at 80% quality keeps the image under 200 KB for web use; PNG was rejected because the file was four times larger'). Reference these decisions directly in written answers.
Using media assets without checking licensing or attribution, or using low-resolution or incorrectly proportioned assets that are then stretched, producing a visibly poor outcome.
Search engines make images easy to grab, and candidates do not distinguish between 'free to view' and 'free to reuse'. Resizing is done by dragging handles rather than by setting dimensions, which distorts the image.
What to do instead
Keep a source list for every asset: URL or creator, licence (e.g. Creative Commons type), and attribution text. Prefer assets whose licence permits the intended use, or create your own. When resizing, lock the aspect ratio or crop rather than stretch, and check the pixel dimensions meet the output requirement before placing the asset.
Not reading the command words in the question: writing a description when asked to justify, compare, or explain, or giving a single example when asked for two, so marks are lost despite knowing the content.
Under time pressure candidates start writing immediately from the first familiar word in the question. Command words are treated as interchangeable, and few have practised matching answer structure to the verb.
What to do instead
Underline the command word and the number of points required before writing. Use fixed structures: describe = what it is; explain = what plus how/why it works; justify = claim plus reason plus evidence from the scenario; compare = both items plus the difference. Count your points against the number asked before moving on.
Leaving out the iterative development evidence: no record of testing, no errors found and fixed, no version history, so the final product appears without the process the assessment rewards.
Candidates see testing and debugging as things that happen incidentally rather than as evidence to capture. Once a bug is fixed, they delete the broken version and lose the record of the problem and the reasoning.
What to do instead
Keep a running log with columns: date, what was tested, expected result, actual result, change made, retest result. Save versions (v1, v2, v3) rather than overwriting. At the end, summarise two or three significant problems and how the fix improved the outcome, linking each to the relevant requirement in the brief.