Blog

How to Run Large Coding Lab Exams Without Losing Work

Large coding lab exams break in predictable ways: a frozen browser, a rebooted lab PC, a flaky network. This guide covers how to plan and run them so a technical hiccup never costs a student their work.

Examination Center is in early access — we're onboarding institutions through our Early Access Program. The information here describes our current platform and direction and may evolve; it is not a contractual commitment.

By the Examination Center team · Last updated: 2026-06-18

Why large coding lab exams lose work in the first place

When you run a coding exam for 80, 200, or 400 students at once, the failure modes are not exotic. They are the ordinary glitches of any shared computer lab, multiplied by the number of seats. A single frozen tab is annoying for one student; the same freeze across a busy lab during peak load becomes a wave of raised hands and a stack of grade appeals.

Most lost-work disputes trace back to a few root causes. Knowing them up front lets you design the sitting to absorb them instead of reacting once the exam is already underway.

• Browser or tab crashes — heavy IDEs, large notebooks, or a runaway loop can hang the page and wipe in-memory edits.
• Lab PC reboots — a forced Windows update or a power blip restarts the machine mid-exam.
• Network drops — campus Wi-Fi or VPN flakes for a few seconds, and an unsaved buffer is gone.
• Accidental closes — a student hits the wrong key, closes the window, and panics.
• Local-only files — work saved to a lab machine's disk vanishes when the imaging system wipes it on logout.

Make autosave and recovery the default, not the exception

The single most effective defense is to stop relying on a student to press Save. In a large sitting you cannot count on it, and you should not have to. Work should be captured continuously and stored somewhere that survives the device.

A browser-based exam environment helps here because there is nothing to install and nothing pinned to one machine's disk. Examination Center, for example, autosaves each student's code and run output continuously, both locally and to the server, so a frozen browser or a fresh session can be recovered without losing work. If a lab PC is wiped on logout, the work is still on the server, not the disk that just got reimaged.

Recovery should be a deliberate, invigilated step rather than a free-for-all. When a student's local data is gone, an instructor can issue a one-time recovery code to restore their session. That keeps the recovery path auditable and prevents it from becoming a loophole during the exam.

Whatever tool you use, confirm three things before exam day: work is saved without student action, it is stored off the local device, and there is a clear procedure to bring a student back into their exact session after a crash.

Plan capacity so the platform does not buckle at peak

Large coding lab exams are bursty. Most students arrive in the same ten-minute window, and many hit Run within seconds of each other near the deadline. If your environment compiles or executes code on a server, that is the moment it gets stressed, so plan for the peak, not the average.

For languages that run entirely in the browser, the math is easier. Python on Examination Center runs in the browser via Pyodide (with NumPy, pandas, and Matplotlib), so each student's code executes on their own machine and there is no shared execution queue to overwhelm. Compiled languages like C, C++, Fortran, and Java compile and run in a secure server sandbox, so for those you should think about concurrent runs at the deadline.

A few practical capacity checks before a big sitting:

• Run a dry sitting at realistic scale, ideally on the same campus network the exam will use.
• Stagger or schedule start times where your exam policy allows, so the login spike is spread out.
• Use scheduled auto-close so the exam ends cleanly for everyone instead of relying on manual cutoff.
• Have a fallback plan for the room: a few spare seats and a known recovery procedure beat improvising under pressure.

Keep the exam fair and identical for every student

Scale is also a fairness problem. The bigger the cohort, the more variation creeps in: one student's IDE has a different autocomplete, another has an AI assistant installed, a third has a plugin that quietly fills in boilerplate. In a real exam those differences are not features, they are inconsistencies you will have to defend later.

An AI-free exam environment removes that variation by giving everyone the same plain editor: no built-in AI assistant and no autocomplete, identical for every student. That single decision eliminates a whole class of "but their setup was different" arguments and makes the sitting easier to stand behind.

Note what this is not. A controlled exam environment of this kind does not take over, lock, or record a student's device or camera, and it is not a proctoring browser. It standardizes the coding surface; it does not surveil the person.

Use live monitoring and integrity evidence, not automated verdicts

During a large sitting you cannot watch every screen, so a live dashboard that shows current code, run history, and integrity signals lets a small invigilation team oversee a big room. You see who is stuck, who has stopped running code, and where activity looks unusual, all in real time.

Be deliberate about how you treat integrity signals. On Examination Center, things like paste events, large or sudden code changes, and cross-student code similarity are surfaced as evidence for human review, never as automated accusations or verdicts. The platform does not assign guilt, it does not grade, and it does not claim to detect AI use. A human makes the call.

That distinction matters at scale because automated flags applied to hundreds of students would generate hundreds of disputes. Evidence for human review keeps the instructor in control and the process defensible. It is worth being clear with your department that this is an integrity-evidence tool, not an auto-grader and not a grade book; grading stays in your existing workflow.

A pre-exam checklist for large sittings

Pulling it together, here is a short runbook you can adapt for any large coding lab exam. The goal is that no single technical failure decides a student's outcome.

• Before: confirm autosave is on, work is stored off-device, and you know the recovery procedure cold.
• Before: run a scaled dry sitting on the real network; check concurrent-run behavior for compiled languages.
• Before: standardize the editor so every student gets the same AI-free environment.
• During: watch the live dashboard; reseat or recover crashed students with a one-time recovery code.
• During: let scheduled auto-close end the exam uniformly.
• After: export sessions, events, and integrity reports for your records, and review any flagged evidence by hand.

Related reading

Python lab exams use case · Engineering Python exams · Examination Center vs Google Colab · Security and reliability

Run fair coding exams

Early Access scope: up to 40 students and 1 exam. Indicative pricing only — see pricing or apply for Early Access.