What A Level Coding Really Looks Like in My Year 12 Room

Monday P5, my Year 12s were proud of a tidy Python recursion demo—until the exam-style trace table asked for the values by frame and they wrote console output instead. That’s the split I see most: students can code, but the British A Level wants reasoning in the spec’s vocabulary. OCR expects their reference language, AQA leans on trace tables and algorithmic justification, and Edexcel likes clean definitions of stacks/queues and ADTs. On-topic resources nail skills; curriculum-fit resources mirror exam phrasing, data representations, and command words.

The other fit issue is the NEA. Plenty of “projects” ask for features but ignore analysis/design logs, test data tables, and evaluation against objectives. I now plan with both lenses: teach the coding concept and its exam proof. I park exemplars, trace-table templates, and past-paper style questions in one organised spot so I’m not reinventing it each week; you can browse and save community pieces in the library and adapt them to your board’s quirks without losing time.

Last Thursday, Maira froze on a 6‑marker that used “justify” instead of “explain”. Same topic, different demand. Since then, I run a few quick checks before a worksheet hits photocopy: does the pseudocode match my board’s reference style? Are command words (state, describe, justify) mapped to the mark scheme’s depth? Do trace tables require variable-by-step values, not printed output? Is Big‑O mentioned only where the spec expects it, and defined with the same wording we teach?

I also scan for ADTs presented the A Level way: operations named consistently (Enqueue/Dequeue/Peek), pointer movement shown for array implementations, and space for students to reason, not just code. When I want a second opinion on phrasing, I paste an excerpt into ClassPods and regenerate questions using the board’s vocabulary; you can spin up a draft in a minute here and pressure‑test it against your scheme before committing.

Last Friday my Year 12 set mixed up front/rear on a queue during a quiz, so I rebuilt the lesson with explicit exam wording and a single worked example we could trace.

Objective: Represent and operate on stacks and queues, translating between Python and exam‑style pseudocode, and justify each operation’s effect.

Worked example: A canteen queue model with an array‑based implementation (size 6), showing Enqueue, Dequeue, and Peek with front/rear pointers and wrap‑around.

• Starter (6 min): Two mini trace steps on paper: push 3, push 7, pop → What’s on top?
• Main input (12 min): Live code a Queue class in Python, then rewrite operations in OCR‑style pseudocode. Name operations exactly as per spec.
• Guided practice (18 min): Students complete a three‑step trace of the canteen queue with wrap‑around; annotate pointer moves and resulting array.
• Formative check (8 min): 4 short prompts, including “justify why Dequeue fails when (rear+1)%n == front.”
• Plenary (6 min): One exam‑style 4‑marker: “Describe how Peek operates on a non‑empty queue and its effect on pointers.”

I keep the deck, trace table, and quiz together so I can tweak for AQA wording next term; if you want to auto‑generate and store a version per board, you can start a pack here and slot in your exemplars.

Two weeks into NEA season, my Year 13s were pushing features but leaving sketchy logs. I stopped and handed out a one‑pager we now use for peer reviews and checkpoints. It mirrors the usual A Level NEA strands without quoting any single board.

NEA code‑review rubric (student‑friendly, teacher‑markable):

• Analysis (clear problem + users): One‑paragraph brief; bullet the success criteria as testable statements. Question stem: “The system must… so that…”
• Design (algorithms + data): Include one structure chart and one key algorithm in reference pseudocode. State chosen data structures and why.
• Development (coding choices): Show modularity, naming, and comments tied to design. Evidence commits or dated logs.
• Testing (systematic, traceable): Provide a test table: case, input, expected, actual, fix. Include at least one boundary test per criterion.
• Evaluation (against criteria): For each success criterion, state met/partly/not met with evidence. Next steps in one sentence.

I print it for folders and keep a digital copy for moderation notes. If you’re weighing up departmental budgets for shared templates and storage, the breakdown is clear on the pricing page so you can decide what fits your allocation this year.

Wednesday after school, my bilingual Year 12 set (Polish and Arabic home languages) were fine coding a queue, but stumbled when a prompt said “justify pointer movement.” Language, not logic, was the hurdle. Now I pre‑teach a micro‑glossary on the board (justify, describe, trace, pointer, overflow) with examples, then echo those in code comments so the phrasing sticks.

For pacing, I split roles: one student runs code; the other writes the trace and labels front/rear. We swap mid‑task so both practise the exam language. Homework is short and surgical: a 6‑question exit quiz mixing command words, followed by a single NEA log update linking today’s concept to their project (“Where in your system might a queue appear?”). I space those quizzes across weeks for retrieval.

When I’m tight on time, I generate a bilingual word bank and a quick exit quiz in the same place I keep my lesson deck; if you want to try the same workflow for your set, you can create a draft in the lesson‑pack builder and tailor the stems to your cohort’s languages.