The 90-Minute Theory Blitz: Where the Marks Really Hide
In Paper 1 (Theory Fundamentals), you are up against a strict timer: 90 minutes to secure 75 marks. This translates to exactly 1.2 minutes per mark. High-scoring candidates do not treat this paper as a race of speed, but as a test of scientific precision. Examiners repeatedly penalize candidates who use everyday general terms instead of precise computer science terminology. For example, never call storage 'memory' or data 'information'. When explaining hardware, saying SRAM is simply 'faster' will lose you the mark; you must specify that it has a 'faster access time' compared to DRAM, which requires a continuous physical refreshing mechanism.
Furthermore, do not lose easy marks on mathematical representations. When converting or calculating files sizes (e.g., calculating a 16-bit color depth bitmap image size), always write down your intermediate steps clearly. A classic trap is calculating the bit-depth directly without dividing by 8 to convert bits to bytes. If you omit this division, your final answer will be off by a factor of eight, instantly costing you both working and final accuracy marks. Remember that binary prefixes (KiB, MiB) are base-2 (1024-based) while denary prefixes are base-10 (1000-based) — know which one the question demands!
The Paper 2 Code Breaker: The 5-Minute Habit That Saves a Grade
Paper 2 is where logic and programming concepts are put to the test over 120 minutes. The absolute best habit you can build during your preparation is the 5-minute pre-writing planning phase. Before writing a single line of pseudocode for a high-mark program design question, analyze the module specifications. Top scorers underline parameters, their types, and the required return values. They immediately identify whether variables need to be passed by reference (BYREF) or by value (BYVAL). If a subroutine modifies an array in memory, omitting the BYREF keyword in the procedure header will guarantee a loss of implementation marks.
Dry runs and trace tables are another goldmine where marks are needlessly dropped. Students frequently misallocate space on trace tables by skipping lines or failing to maintain strict row-to-row alignments with instructions. To avoid this, trace line-by-line and use a physical ruler on your desk. Remember, if an assembly instruction uses indirect addressing (such as LDI), you must read the memory address stored in the operand, then fetch the contents of that target address, rather than loading the immediate pointer itself.
The Syntax Vault: Translating Thoughts into Flawless Pseudocode
The Cambridge 9618 syllabus uses a highly standardized pseudocode format that is strictly enforced. One of the most common ways candidates lose marks is by letting concrete syntax from high-level programming languages (like Python, Java, or VB) slip into their answers. Writing = for variable assignment instead of the standard left-arrow <- is an automatic error. Similarly, using the + operator for string concatenation is a syntax violation — you must use the ampersand (&) operator.
When handling text files, there are three absolute golden rules to follow:
- Always enclose literal filenames in quotes: Writing
OPENFILE Stock.txt FOR WRITEis invalid. It must be written asOPENFILE "Stock.txt" FOR WRITE. - Do not omit parameters: Commands like
CLOSEFILEandEOF()require the filename parameter (e.g.,CLOSEFILE "Stock.txt"). Omitting it is a penalizable syntax error. - Type conversion is mandatory: When writing non-string variables to a sequential text file, you must explicitly convert them using
NUM_TO_STR(). Conversely, when reading numerical values from a text file, convert them usingSTR_TO_NUM()before performing any mathematical assignments.
SQL Scripting Secrets: Joining Tables Without Cartesians
SQL is highly weighted in Paper 1 and demands absolute syntactic accuracy. In database SQL queries, the single biggest pitfall is failing to include explicit table join conditions (e.g., WHERE CONTAINER.ShipID = SHIP.ShipID) when querying multiple relational tables. Forgetting this link results in a Cartesian product, which returns a useless, massive grid of records and voids your query marks. Additionally, always remember to pair group-level attributes with a GROUP BY clause whenever aggregate functions like COUNT() or SUM() are used. When defining composite primary keys in a CREATE TABLE block, do not write 'PRIMARY KEY' inline on two separate fields. Instead, define them as a single, combined constraint at the very end of the statement: PRIMARY KEY (Field1, Field2).