NCEA L1 Digital Tech common mistakes
NCEA L1 Digital Tech · Understand the traps and how to avoid them.
Writing the program logic but never testing it against the examples given, so the code is submitted with syntax errors, off-by-one counting, or a loop that runs once too few or too many times.
Candidates treat 'writing code' as the whole task and skip the run-and-check step, often because they are used to reading code rather than executing it, or they run out of time and submit untested work.
What to do instead
Before writing anything, copy the given input/output examples into a table. After writing the code, hand-trace it line by line for the first example, then actually run it if a machine is available. Check boundary cases: the smallest input, an empty list, and a value exactly at the limit. Testing is part of the answer, not an optional extra.
Using vague variable names like x, num, or thing, and mixing naming conventions (myVar, my_var, myvar) within the same program.
Candidates write quickly under time pressure and pick short names to save keystrokes, and they may have copied snippets from different sources without noticing the inconsistency.
What to do instead
Name a variable for what it holds: total_score, student_count, is_valid. Pick one convention (lower_snake_case or camelCase) and apply it throughout. Ask of each name: 'could another reader tell what this stores without seeing where it was set?' If not, rename it.
Confusing == with =, or using a single = inside a condition, producing an assignment where a comparison was intended.
The two symbols look nearly identical, and in some languages the assignment form inside a condition is legal syntax, so no error appears until the logic silently misbehaves.
What to do instead
When writing a condition, read it aloud as a question ('is count equal to zero?') and use the comparison operator that matches. After writing each if/while condition, check it contains a comparison operator, not an assignment. If the language allows the assignment form, test that branch with a value that should be false.
Describing a circuit or embedded system only at the block level ('the sensor sends data to the microcontroller') without naming the actual components, pins, or signal direction.
Candidates learn the big picture from diagrams but never practise translating it into component-level detail, so they default to generic phrasing that earns little credit.
What to do instead
For every connection, state three things: the component and pin, the direction of signal or power, and what it carries (for example, 'the LDR output connects to analogue input A0; the microcontroller reads a voltage that falls as light rises'). Practise redrawing a circuit from memory and labelling every pin and arrow.
Treating input and output devices as interchangeable, e.g. listing a buzzer as an input or a button as an output, or forgetting that some components (like an LED with a resistor) need supporting parts.
Candidates memorise device names without linking each to whether it converts a physical quantity into a signal (input) or a signal into a physical effect (output), and they skip the supporting-component detail.
What to do instead
Sort every component in the system into input, processing, or output, and justify each with 'it converts X into Y'. For each output, note the required series resistor or driver. Check the sort again at the end: a buzzer converts a signal into sound, so it is an output.
Confusing data with information, or describing a database as a single table without explaining the fields, records, or how tables relate.
The terms are used loosely in everyday speech, and candidates often have only used flat spreadsheets, so relational structure and the data-to-information distinction feel abstract.
What to do instead
Define data as raw recorded values and information as data processed into meaning for a purpose, and give one concrete example of each from the scenario. When describing a database, list each table, its fields and key, and state the relationship ('each order record links to one customer via customer_id').
Ignoring the purpose and audience of an information system, and proposing a solution (e.g. a spreadsheet or a web form) without saying what problem it solves or who uses it.
Candidates jump straight to the tool they know best rather than analysing the need, so their answers describe features instead of fitness for purpose.
What to do instead
Before proposing a solution, write one sentence each for: who the users are, what they need to do, and what currently goes wrong. Then justify each design choice against those sentences. If a choice cannot be linked to a stated need, cut it or explain why it is still required.
Describing a media outcome only in terms of the software used ('I made it in Photoshop') rather than the design decisions, techniques, and their effect on the audience.
Candidates equate tool use with skill, and assessment language rewards describing choices and their impact, which they have not practised articulating.
What to do instead
For each element, state the technique, the reason, and the effect: 'a shallow depth of field keeps the subject sharp and blurs the background so attention stays on the face'. Replace every 'I used tool X' with what the tool achieved and why it suits the purpose and audience.
Submitting media work that ignores technical requirements such as file format, resolution, aspect ratio, or file size, or that breaches copyright by using unlicensed images or music.
Candidates focus on the creative content and leave export settings and source attribution to the last minute, or assume anything online is free to use.
What to do instead
Write the technical specification (format, dimensions, duration, size limit) as a checklist before starting, and verify the exported file against it. Keep a source log recording where each asset came from and its licence; if a licence is unclear, replace the asset with one that is clearly licensed or original.
Answering a 'justify' or 'explain why' question with a description of what was done, giving no reason or trade-off, so the response earns description marks but not the higher-level ones.
Candidates read the command word as 'describe' and write what they did rather than why, often because they have not been taught to notice command words or to weigh alternatives.
What to do instead
Underline the command word in every question. For 'justify' or 'explain', use the pattern: state the choice, give the reason linked to the context, then name a trade-off or alternative rejected and why. One sentence of reasoning per claim, checked against the command word before moving on.