How to prepare for an online programming exam: a practical method

You finished the lessons, and now there is a timed exam: 15 multiple-choice questions, 30 minutes, 70% to pass. Many people prepare for a programming exam the way they would for a history exam, rereading notes until the words feel familiar. That feeling of familiarity is misleading. Programming exams test whether you can read code and predict what it does, and that is a skill you build by doing it. This guide gives a practical method that works for the exams on this site and for most timed programming tests. It is based on how learning actually works, not on tricks.

What a programming exam really tests

Most questions fall into a few kinds:

1. Predict the output. A short piece of code, and four possible outputs. Only careful reading, or knowing a rule well, gives the right answer.
2. Find the problem. Code that fails or behaves oddly. Which line or concept is the cause?
3. Pick the right tool. Which function, keyword or clause does this job?
4. Concept questions. What does a term mean, or what is the difference between two similar things?
5. Safety and good practice. Which version is secure, efficient or correct?

The first two kinds are why rereading does not work: you cannot reread your way into predicting code. You must practise predicting.

The method

1. Map the syllabus

List the sections of the course and, under each, the lessons. For each lesson, write one line: "I can explain …". If you cannot complete the line, mark the lesson. The summary at the top of each lesson gives you the key points to check against. This list is your revision plan, and it stops you spending a week on topics you know and no time on those you do not.

2. Start early, in short sessions

Learning sticks better when it is spread out. Four sessions of 45 minutes across a week beat one session of three hours the night before. Begin revision at least a week before the exam, and keep the session going until you could explain a topic to a friend.

3. Practise recalling, not rereading

After a lesson, close it and write down what you remember: the rules, an example, a trap. Then check. The effort of recalling is what builds memory. Rereading feels easier and teaches less. For code, rewrite an example from memory, then run it and compare.

4. Predict before you run

This is the single best exercise for a programming exam. Take any example from a lesson. Write down what you think it will print, in full, including the format. Then run it. If you were right, move on. If you were wrong, find the exact rule that explains the difference and write it down. Over a week you will collect a list of rules that you got wrong at first, and those are the ones that appear in exams.

5. Collect your "gotchas"

Every language has surprising behaviours. Keep a page of them, in your own words:

• comparisons between different types,
• what counts as true or false,
• the order in which clauses or operators are evaluated,
• whether a function changes its input or returns a new value,
• off-by-one in ranges and indexes,
• text versus number.

Reread this page the evening before the exam. It is shorter than the course and contains exactly the things you are likely to forget.

6. Build one small thing

Rebuild the course project, or a smaller version, from a blank file without looking. Where you get stuck shows what you only half know. The practical work also gives you the context that makes questions about it easier.

7. Do a trial run

Set a timer for the exam length, close your notes, and answer questions from the lesson quizzes in one sitting. You are practising two things at once: the content and the pace. If the real exam has 15 questions in 30 minutes, you have two minutes per question on average.

During the exam

Read the whole question before the options. Many wrong answers are plausible if you skim. Look at the code line by line, and pay attention to small details such as quotes, equal signs and brackets.

Work through code by hand. Write the variable values on paper as they change. Do not trust a feeling of what the code "obviously" does.

Eliminate. Cross off options you know are wrong; often two of four can be ruled out quickly. Then think about the remaining two.

Watch the clock. If a question takes more than three minutes, make your best choice and move on. Come back if time allows.

Beware of absolute words. Options with "always" or "never" are often wrong in a subject full of exceptions, though not every time.

Do not change answers lightly. Change an answer only when you have found a specific reason, not because of a vague unease.

Answer every question. A blank is worth nothing, a guess might be right.

Stay on your own. The point of a certificate is that it says what you can do without help, so avoid searching during the exam. It would also waste the clock.

Before the exam

• Check the rules: number of questions, time limit, pass mark and attempts. For the exams on this site: 15 questions, 30 minutes, 70% to pass, 3 attempts in 24 hours. The timer keeps running if you leave the page.
• Choose a quiet time when you have the full length plus a margin, and a stable internet connection.
• Sleep and eat. Tired people misread code.
• Close other tabs and notifications.
• Have paper and a pen for working out answers.

After the exam, pass or fail

If you passed, record what you learned and how you prepared. If you did not, treat the result as information.

1. Look at which topics the questions covered. The results show which questions you got wrong.
2. Identify the type of mistake. Was it a gap in knowledge, a misread question or running out of time? Each has a different fix.
3. Return to the lessons for those topics, run the examples and write new predictions.
4. Wait before retrying. Try again after you can explain the missed topics, not an hour later. Because the question bank is reused, rushing an immediate retry mostly repeats the same weakness.
5. Don't take it personally. Exams are built to be demanding, and many people pass on their second attempt.

Common mistakes in preparation

• Rereading notes instead of practising.
• Skipping the hard topics and revising only what feels comfortable.
• Memorising answers to practice questions instead of the rule behind them. The bank is larger than a single attempt and the wording changes.
• Studying only on the last night.
• Never running code.
• Revising with distractions such as a phone beside you.
• Ignoring the small print of the exam rules.

A sample week of revision

Day	Focus
1	Make the syllabus map; mark the weak lessons
2	Weak lessons: reread, then rewrite examples from memory
3	Predict-then-run session; start the gotcha page
4	Rebuild a small project without looking
5	Remaining weak lessons; add to the gotcha page
6	Timed trial with the lesson quizzes
7	Light review of the gotcha page; rest

For subject-specific advice, read the guides to the exams: HTML, CSS, MySQL and PHP. The study plans for HTML and CSS and MySQL and SQL show how to schedule a whole course. When the result arrives, add your certificate to LinkedIn and your CV.

Quick answers

How long should I revise? A week of short daily sessions is typical after finishing the course.

Is it better to cram? No. Spread sessions work much better.

Should I memorise syntax? Know the common syntax well, but understanding what code does matters more.

What if I run out of time? Practise with a timer and move on from hard questions.

Can I look things up during the exam? The exam is meant to measure what you can do on your own, so do not.