What each part of the prompt does
- Attempt before answer
- The rule against showing solutions early is the point of the session. Writing an answer cold, the way you will in the exam hall, is what builds the skill; reading model code only feels like progress.
- Errors sorted by type
- Separating syntax errors, logic errors and missed edge cases tells you what to practise. Missing semicolons need a checklist; a wrong loop boundary needs more tracing practice.
- Hand-writable model answers
- Plain variable names and no clever library calls keep the model answer realistic. Code you could not reproduce from memory on paper does not help you on the day.
- Weak topic weighting
- Asking for at least two problems on [WEAK TOPIC] puts the practice where your marks are leaking, instead of letting the session drift towards the topics you already enjoy.
Variations to try
Same idea, one thing changed.
Output tracing questions <role>You are an examiner preparing me for a written programming exam where I write code on paper without a computer.</role> <context> - Language: [LANGUAGE] - Topics on the syllabus: [TOPICS] - My weakest topic: [WEAK TOPIC] - Exam style, if known: [EXAM STYLE] </context> <instructions> 1. Write five short code snippets, from easy to hard, with at least two on [WEAK TOPIC]. For each, ask me to write the exact output and the value of each variable after the last line. 2. Show me the problems only. Wait for me to paste my handwritten answer for problem 1 before you continue. 3. When I paste an answer, mark it like an examiner: list syntax errors, logic errors and missed edge cases separately, and say what marks it would likely get on a simple scale (full, partial, little). 4. Then show a model answer that is short enough to write by hand: plain names, no library tricks, comments only where a marker would look for them. 5. Explain the logic of the model answer in three or four sentences I could say out loud if asked. 6. Move to the next problem only when I type "next". </instructions> <rules>Do not show a model answer before I have attempted the problem, unless I type "show".</rules>
Timed mock section <role>You are an examiner preparing me for a written programming exam where I write code on paper without a computer.</role> <context> - Language: [LANGUAGE] - Topics on the syllabus: [TOPICS] - My weakest topic: [WEAK TOPIC] - Exam style, if known: [EXAM STYLE] </context> <instructions> 1. Write five practice problems, from easy to hard, with at least two on [WEAK TOPIC]. Each problem states the input, the expected output and one example. 2. Show me the problems only. Wait for me to paste my handwritten answer for problem 1 before you continue. 3. When I paste an answer, mark it like an examiner: list syntax errors, logic errors and missed edge cases separately, and say what marks it would likely get on a simple scale (full, partial, little). 4. Then show a model answer that is short enough to write by hand: plain names, no library tricks, comments only where a marker would look for them. 5. Explain the logic of the model answer in three or four sentences I could say out loud if asked. 6. Show all five problems at once and tell me to set a 45-minute timer. I will paste all my answers together, and you mark them in order. </instructions> <rules>Do not show a model answer before I have attempted the problem, unless I type "show".</rules>
If the result isn't right
- Actually write your answer on paper first, then type it in exactly as written, mistakes included; fixing it while typing hides the errors you would make in the exam.
- Keep a running list of every syntax error Claude flags and read it the morning of the exam.
- If the problems feel too easy, reply "make the next three exam difficulty" rather than restarting.