NZ Scholarship Digital Technologies key terms

A finite, ordered set of unambiguous steps that transforms an input into an output. Correctness, termination and efficiency can each be reasoned about separately, which is why algorithm choice often matters more than programming language.

Removing detail that is irrelevant to the problem at hand so a system can be described and reasoned about at a manageable level. Interfaces, data types and models are all abstractions that hide underlying complexity.

Breaking a large problem into smaller sub-problems that can be solved, tested and reused independently. Good decomposition reduces coupling between parts and makes parallel work and incremental testing possible.

A description of how an algorithm's running time grows as input size increases, usually expressed in big-O notation. It characterises growth rate rather than exact seconds, so it compares algorithms independently of hardware.

A measure of the extra memory an algorithm needs as input size grows, again usually given in big-O form. Trading space for time, such as caching results, is a common design decision candidates should be able to justify.

A notation describing an upper bound on growth rate, ignoring constant factors and lower-order terms. For example, an algorithm doing n comparisons plus 50 setup steps is O(n) because growth dominates constants.

The input pattern that makes an algorithm do the most work, used when giving guarantees about performance. Average case describes typical inputs and best case is rarely useful, since it says little about reliability.

A technique where a function solves a problem by calling itself on a smaller instance, with one or more base cases that stop the calls. Each call adds a stack frame, so deep recursion risks stack overflow.

The condition in a recursive function that returns a result directly instead of recursing further. Without a reachable base case, recursion never terminates and the call stack keeps growing until the program crashes.

The runtime structure holding one frame per active function call, storing return addresses and local variables. It explains why recursion consumes memory and why an unhandled exception reports a stack trace of nested calls.

Caching the results of expensive function calls so repeated inputs are answered from storage instead of recomputed. It converts some exponential recursive algorithms into polynomial ones at the cost of extra memory.

A way of organising data in memory so that particular operations are efficient, such as arrays, linked lists, stacks, queues, hash tables and trees. Choice of structure determines which operations are fast.

A structure mapping keys to values via a hash function, giving average constant-time lookup, insertion and deletion. Collisions must be resolved, for example by chaining, and worst-case performance degrades to linear search.

A last-in-first-out structure where only the most recently added item can be removed. It suits undo histories, expression evaluation and backtracking, and underlies how function calls are managed at runtime.

A first-in-first-out structure where items are removed in the order they were added. Queues model fair scheduling, buffering and breadth-first traversal, and variants such as priority queues order items by key instead.

Systematically visiting every vertex of a graph, typically by breadth-first search using a queue or depth-first search using a stack or recursion. Traversal underpins pathfinding, connectivity checks and dependency ordering.

A procedure arranging items into order, such as merge sort, quicksort or insertion sort. They differ in typical and worst-case complexity, stability, memory use and behaviour on nearly sorted input, so context decides the best choice.

A language-independent notation expressing algorithm logic using structured English and standard control constructs. It lets candidates communicate design decisions and complexity reasoning without the syntax noise of a real language.

A manual record of variable values after each step of an algorithm, used to verify logic and locate errors. Tracing a small example by hand is often the fastest way to expose off-by-one and boundary mistakes.

A specific input together with the expected output, chosen to exercise a behaviour or boundary. Good suites include normal, boundary and invalid inputs, and each case should be traceable to a requirement.

An input at or just either side of a limit, such as an empty list, a maximum size or a zero quantity. Errors cluster at boundaries, so these cases deserve explicit tests rather than only typical values.

Re-running existing tests after changes to confirm that previously working behaviour still works. Automated regression suites make refactoring safe, because any newly broken behaviour is detected quickly rather than in production.

The process of locating and correcting defects by reproducing the fault, forming hypotheses and narrowing the cause. Systematic debugging uses traces, logging and minimal test cases rather than random edits to code.

An event signalling that normal execution cannot continue, such as a division by zero or a missing file. Well-designed programs catch anticipated exceptions and handle them meaningfully instead of silently ignoring them.

Bundling data with the operations that act on it and restricting direct access from outside. It protects invariants, allows internal representation to change, and reduces the ripple effect of modifications across a codebase.

The defined boundary through which components interact, specifying what operations are available without exposing how they work. Stable interfaces let implementations be swapped and allow teams to develop parts independently.

Designing a system as separable units with clear responsibilities and minimal unnecessary dependencies. High modularity improves testability, reuse and comprehension, and limits how far a change or fault can propagate.

The degree to which one module depends on details of another. Loose coupling, achieved through narrow interfaces and passed parameters rather than shared global state, makes modules easier to replace and test in isolation.

Restructuring existing code to improve readability or design without changing external behaviour. It is performed in small verified steps backed by tests, and it manages accumulating technical debt rather than adding features.

The future cost incurred by choosing a quick, expedient solution over a better-designed one. Like financial debt, it accrues interest as changes become slower and riskier, so it should be tracked and repaid deliberately.

A system recording changes to files over time so any earlier state can be inspected or restored. Branching supports parallel work and merging, and commit history provides an audit trail of who changed what and why.

Combining separately developed components and verifying that they work together. Problems often surface at boundaries where assumptions differ, so integration should be frequent and supported by automated tests.

The ability of a system to continue operating sensibly when inputs are invalid, resources fail or conditions are unexpected. It is achieved through validation, error handling and graceful degradation rather than assuming ideal conditions.

Checking that data supplied to a program meets expected type, format, range and completeness rules before use. Validation at trust boundaries prevents corrupted state and is a primary defence against injection-style attacks.

Transforming readable data into ciphertext using a key so that only authorised parties can recover the original. Symmetric schemes use one shared key; asymmetric schemes use a public and private key pair.

Applying a one-way function to data to produce a fixed-length digest used for integrity checks and password storage. Hashes are not reversible, and a good cryptographic hash makes finding two colliding inputs impractical.

A value created with a sender's private key that a recipient can verify with the public key, proving origin and integrity. It provides authentication and non-repudiation but not confidentiality on its own.

Verifying that a claimed identity is genuine, typically through something known, possessed or inherent. It differs from authorisation, which decides what an already authenticated identity is permitted to do.