WJEC A-level Computer Science: What Actually Matters

WJEC's A-level Computer Science splits neatly into three parts: two written exams and a non-exam assessment (NEA) coding project. Students coming from GCSE often underestimate how much the jump in depth matters, especially around computer architecture and formal algorithm analysis. This guide breaks down what each component actually demands, not just what the spec document says in abstract terms.

The exam structure you're working with

Component 1 (Unit 1) covers programming, data structures, and computer systems fundamentals — things like the fetch-execute cycle, Boolean algebra, and number representation (two's complement, floating point normalisation). Component 2 (Unit 2) goes deeper into algorithms, databases, networking, and the legal/ethical side of computing.

Both papers mix short-answer questions with extended writing, and both include pseudocode written in WJEC's own style, which differs slightly from Python or Java syntax. Get comfortable with it early. Students who only ever write real Python and never practice reading the exam board's pseudocode notation lose marks on translation, not understanding.

Boolean algebra and logic gates deserve real practice time

This is the section that trips up otherwise strong programmers. Simplifying expressions using De Morgan's laws, drawing truth tables for XOR and NAND combinations, and converting between logic gate diagrams and Boolean expressions — these skills need repetition, not just conceptual understanding. Work through past papers specifically for this topic. The mark schemes show exactly how much working is expected; skipping steps costs marks even when the final answer is right.

Computer architecture: know the pipeline, not just the vocabulary

Students can usually recite "fetch, decode, execute" but struggle to explain what actually happens to the program counter or memory address register during each stage. WJEC exams ask you to trace through a simplified instruction cycle step by step. Draw it out by hand a few times with actual register names (MAR, MDR, PC, CIR, ALU) until the sequence is automatic. The same applies to von Neumann versus Harvard architecture — know one clear distinguishing feature, not a vague paragraph of description.

The NEA: pick a project you can actually finish

The non-exam assessment is worth a meaningful chunk of the overall grade, and the biggest mistake students make is choosing a project that's too ambitious. A working inventory management system with a SQLite backend and a clean Tkinter or PyQt interface will score better than an unfinished machine learning app that never gets past a broken prototype.

Structure your NEA write-up around the assessment objectives directly: analysis (what problem, whose need, what success criteria), design (data structures, algorithms, interface mockups), technical solution (actual code, with evidence of testing), and evaluation (does it meet the original success criteria, tested against real data). Screenshot your testing at every stage — moderators want to see evidence, not just a claim that