MATSEC AM Computing exam-day guide

Stop learning new syntax and start drilling the recurring practical tasks: reading data from a text file into an array or list, validating input in a loop, searching and sorting a small collection, and writing results back to a file. Write each from memory in your centre's environment, then compare against your notes and fix the gaps.

Rehearse a full timed run: pick a short problem statement, spend the first few minutes on a written plan, then code, test with normal, boundary and invalid data, and finish with a tidy listing. Time yourself and note where you lost minutes.

Memorise your debugging checklist: check variable initialisation, loop bounds (off-by-one), string versus numeric input, division by zero, empty file or empty list, and correct closing of files. Practise reading a compiler or interpreter error message and locating the reported line.

Confirm logistics with the provider: session date and time, room, permitted materials, language and IDE, submission method, and any access arrangements. Resolve uncertainties now rather than on the day.

Prepare and pack your materials: ID, candidate details, pens and pencils, and your own one-page structure outline if permitted. Get two good nights of sleep before the session rather than cramming the night before.

Do one light practice task only, focused on your weakest area, then stop. Re-read your own summary sheet of language syntax you tend to forget: array/list declaration, string concatenation and conversion, file open modes, and how to define and call a function or method.

Check the practical details once more: arrival time, travel route, and what you are allowed to bring. Charge any device only if the provider has confirmed it is permitted; otherwise leave it at home.

Prepare your opening routine on paper: how you will create and name the file, where you will save it, and the first three things you will code (for example data declarations, input section, output section). Deciding this in advance removes early-session hesitation.

Eat properly, arrive early, and set up your workstation calmly: open the editor or IDE, create the correctly named file, and save it once before typing any real code so the file path is established.

Read the whole paper before coding. Identify which parts carry the most marks and which are independent, then order your work so that a complete, working, simpler solution exists before you attempt refinements.

Write a short plan on paper: inputs, processing, outputs, data structures, and the functions or methods you will create. A five-minute plan usually saves more than five minutes of rework later.

Build in small increments and run the program after each one. Get input and output working with hard-coded values first, then add validation, then file handling, then any extra features. Save after every successful increment.

Test deliberately rather than casually: one normal case, one boundary case (empty input, zero, largest expected value), and one invalid case (letters where numbers are expected). Note what you tested, as some papers ask for evidence of testing.

Stop adding features. Tidy indentation and naming, remove stray debug output, confirm the file is saved in the required location and format, and check that your name or candidate number is on the work if required. Submit or hand over exactly as instructed.