Evaluation prep checklist

An evaluation — viva, demo, or one-on-one marking session — is a strange performance: your work is already finished, and now it gets interrogated. Most disappointing evaluations are not caused by weak work. They are caused by a demo that would not run, an explanation that wandered, or a question nobody expected. All three are preventable in advance.

A week before

• Read the evaluation brief properly. What is being assessed — the artifact, the explanation, or both? The rubric (if published) is the syllabus of your preparation.
• Run the project from a clean state. Fresh checkout, on a different machine if possible. Every hard-coded path and missing dependency reveals itself now instead of in the room.
• Prepare a 60-second summary. What it does, how it is built, what you would improve. Practise it out loud — twice.
• List your decisions and their reasons. The most common viva question is “why did you do it this way?” — have honest answers ready, including the weakest one.
• Book your slot. If the course uses nuSkor, slots come from the booking grid — first pick, no double-booking. Book before the good times are gone.

The day before

• Touch nothing risky. No refactors, no last-minute features. Freeze the version you will present.
• Package the demo. Dependencies installed, sample data ready, README with run instructions — assume a grader will run it without you.
• Prepare a fallback. A screen recording or a set of screenshots means a broken environment costs you minutes instead of the evaluation.
• Sleep. This is on the checklist because it is on the exam, and its effect on explanation quality is enormous.

In the room

• State the summary first. Orientation before detail: one minute of “what this is” makes every later question land better.
• Drive the demo deliberately. Follow a path you rehearsed; narrate what you are doing and why. Silence while typing reads as confusion even when it is focus.
• Answer the question that was asked. Short answer first, then justification if invited. Rambling is read as not knowing.
• It is fine to say “I don’t know” — followed by method. “I don’t know, but I would find out by X” scores better than a confident guess, every time.

Questions worth rehearsing

• Walk me through the overall design in one minute.
• Which part was hardest, and how did you solve it?
• What breaks if input X is missing or hostile?
• What would you change with one more week?
• Which of these code lines are you least happy with?

After

Write down what got asked while it is fresh — patterns repeat across evaluations, and your notes become next semester’s preparation. If something went wrong (a demo that misbehaved, a question you could not parse), mention it politely to the evaluator: a calm follow-up often lands fine, and the portal-side record stays accurate through course staff. Then close the laptop. You prepared; that is the part you controlled.