NZ Scholarship Digital Technologies common mistakes
NZ Scholarship Digital Technologies · Understand the traps and how to avoid them.
Producing a polished prototype or app walkthrough but never articulating the underlying digital technologies concepts (e.g. algorithm choice, data representation, complexity, abstraction) that the work demonstrates.
Candidates come from a project/portfolio habit where the artefact is the deliverable and assume a strong build 'speaks for itself'; the report then becomes a build diary rather than analysis, so the assessor cannot see conceptual understanding.
What to do instead
Before writing, list the 4–6 concepts your project actually exercises and, for each, write a paragraph naming the concept, justifying the specific technical decision, and evaluating alternatives rejected. Make the artefact evidence for the concept, not the subject of the report.
Treating the report as a chronological log ('first I did X, then I added Y') rather than an argued position with claims, evidence and reasoning.
School internal assessments often reward process documentation, and iterative development naturally produces a timeline; candidates transfer that structure without recognising the scholarship standard demands a reasoned argument.
What to do instead
Restructure around claims: each section should open with a proposition (e.g. 'A normalised schema was chosen because...'), then evidence from the build, then a counter-consideration. Move chronology into an appendix or one short timeline paragraph.
Making broad claims about 'efficiency', 'scalability' or 'usability' with no measurement, complexity analysis, or test data behind them.
Candidates know the vocabulary from internal standards but have rarely been required to quantify; they assume the assertion is sufficient and lack familiarity with Big-O, profiling output, or usability metrics.
What to do instead
Attach a number or a formal argument to every performance claim: state the time/space complexity of the chosen algorithm versus the rejected one, or report measured timings/error rates from your own tests. Delete any claim you cannot evidence.
Ignoring the social, ethical, legal or economic dimension of the digital technology, or bolting on a generic paragraph about 'privacy' or 'the digital divide' unrelated to the actual project.
Candidates read the technology as purely technical and treat the human-context strand as an add-on; generic ethics material is easy to find and superficially plausible, so it substitutes for genuine analysis of their own system.
What to do instead
Identify the specific stakeholders your system affects, the specific data it collects or exposes, and the specific harm or benefit that follows (e.g. who is misclassified, whose data is retained, who is excluded by the interface). Ground each point in a design decision you made or could have made.
Describing what the program does line by line instead of explaining why it was designed that way, what trade-offs were accepted, and how it would fail.
Code commentary habits from programming courses encourage explanation of mechanics; candidates also fear that omitting description will lose marks for 'understanding', so they over-describe.
What to do instead
For each significant component write: the problem it solves, the design chosen, the alternative rejected and why, and the conditions under which it breaks. Cut any sentence that only restates what the code visibly does.
Presenting a single solution as the obvious one, with no genuine consideration of alternative approaches or of the limitations of the chosen approach.
Iterative development produces one path with incremental fixes, so alternatives never get explored; candidates also worry that admitting limitations weakens the submission.
What to do instead
For at least three key decisions, name a credible alternative (different data structure, different architecture, different interaction model), state the criteria used to compare, and justify the choice. Then state the residual weaknesses of your choice and their consequences.
Citing sources only as links or not at all, and reproducing diagrams, code snippets or explanations from tutorials and documentation without attribution or transformation.
Candidates assemble solutions from documentation, forums and AI tools during development and do not track provenance; they also underestimate what counts as a source in a technical report.
What to do instead
Keep a running source log during development (tool, page, date, what you took). In the report, cite every external idea, library or snippet in a consistent style and make clear what is your own contribution versus adapted material.
Choosing a project scope that is technically shallow - a CRUD app or a template-based website - so there is little to analyse at scholarship level.
Candidates optimise for a finished, demonstrable product and pick familiar, low-risk tools; the resulting system has no algorithmic, data-modelling or systems-level depth to discuss.
What to do instead
Select a project with at least one genuinely hard technical core (a non-trivial algorithm, a data transformation, a concurrency or performance constraint, a custom protocol or model). If the scope is already fixed, identify and deepen the hardest component rather than broadening features.
Leaving evaluation to the end as a statement that 'the project was successful' rather than testing against stated criteria and reporting what failed.
Evaluation is perceived as a formality and time runs out near the deadline; candidates also conflate 'it works when I run it' with evaluation.
What to do instead
Define success criteria at the start (functional, performance, usability, ethical). At the end, test each criterion with a described method, report the actual result including failures and anomalies, and state what you would change and why.
Misreading the assessment schedule: spending the available effort on breadth of features or on presentation polish while neglecting the depth of analysis and reflection the report is judged on.
Candidates carry over habits from internal assessments where completeness and presentation are heavily weighted, and often have not read the scholarship report/assessment specifications closely.
What to do instead
Read the current assessment specifications and any published exemplar guidance, extract the actual judged dimensions, and map your draft against each one. Allocate remaining time proportionally to those dimensions, cutting features to protect analysis depth.