How to get an A at AS and an A* in Cambridge A Level Computer Science

Explain what happens to the data

For systems topics, follow information through the process. In a communication or processor question, identify what is stored, what is transferred and what controls the next step. A small annotated diagram can help you organise the explanation, but each arrow should have a clear meaning.

At AS, use examples to distinguish related concepts such as validation and verification, a data type and a data structure, or a program error and a hardware fault. If you can only repeat a definition, create a new scenario and explain how the term applies there.

Trace before you trust an algorithm

Use a table to track variables through loops and decisions. Include the initial values and the final iteration; many errors occur at the boundaries. When you write pseudocode, make the input, processing and output clear and follow the conventions required for your exam year.

Before coding, break the task into manageable operations. State what each operation receives and returns. Test the design with a tiny example that you can solve manually. If the design fails there, repair it before adding the distractions of language syntax and file handling.

Build A2 programming fluency through small projects

For the advanced practical component, work in the language and environment agreed with your centre and allowed by the current syllabus. Practise starting with a clean file and organising a solution without relying on prepared snippets. Save meaningful versions and follow the file instructions given in the task.

Use small projects with explicit requirements: read records, validate fields, search or sort data, and produce a specified output. After making the program work, deliberately test awkward cases. Debug by checking assumptions and inspecting intermediate values, rather than repeatedly changing code until the output looks plausible.

Test the specification, not your favourite example

Create a test table before running the program. Include input, expected result, actual result and the reason for the test. Boundary tests should sit at or immediately beside a limit; invalid tests should violate a stated rule. A valid but unusual input is not automatically an invalid test.

For theory and practical revision, keep an error log with causes: incorrect concept, flawed algorithm, syntax, or misunderstood requirements. Redo the task after a delay. Track whether you can explain and reproduce the correction, not simply whether the program ran once.

Common mistakes—and how to fix them

Your four-week revision plan

Use this as a focused revision cycle alongside your lessons. If you are still learning the course, give unfamiliar topics more time before attempting full papers.

1. Week 1

   Check foundations

   • Confirm syllabus year and pseudocode guide.
   • Trace loops, arrays and decisions; explain weak theory concepts.
2. Week 2

   Design and implement

   • Write short algorithms from requirements.
   • Build and test small programs without copying a finished solution.
3. Week 3

   Simulate assessment

   • Attempt timed theory and stage-appropriate programming tasks.
   • Use test tables and inspect every failed requirement.
4. Week 4

   Repair recurring defects

   • Redo boundary-error and file-handling tasks.
   • Rehearse the centre’s software and file-saving procedures.

Your questions, answered