Running a proctored coding exam for 400 students

A proctored coding exam for a full engineering cohort is an operations problem before it is an academic one. Four hundred students means four hundred devices, four hundred network connections, and at least a handful of power fluctuations, dropped Wi-Fi sessions, and students who arrive without having tested their camera. The academic design matters enormously, and we will get to it, but most exams that go wrong go wrong on logistics that were knowable a week earlier.

This post is the runbook we walk departments through: before, during, and after. It assumes an online lab exam run on campus or a mix of campus and home, which is the reality for most Indian engineering colleges.

Proctoring controls the environment. It does nothing about a question whose answer is already in the student's head because it circulates in every solutions group. If your exam reuses well-known puzzles, the students who drilled them will finish in minutes and the integrity tooling will correctly report that nothing suspicious happened, because nothing did. The leak was in the paper, not the room.

The fixes are design fixes. Write problems around scenarios rather than named techniques, vary the constraints and edge cases from anything published, and lean on the second half of dual scoring: every submission on Assessly carries a written explanation graded for clarity, technical accuracy, depth, and completeness. A memorized solution can pass tests. It struggles to account for itself in the student's own words, and that struggle is visible in the score without any accusation being made.

The week before the exam, run a low-stakes rehearsal on the same platform with the same proctoring modules enabled. This is the single highest-value step in the whole runbook. It surfaces the laptop with a broken camera, the student who never granted microphone permission, and the lab machine with an ancient browser, while there is still time to fix them instead of during roll call.

For the lab itself, plan around the constraints you actually have:

• Bandwidth: camera and audio monitoring consume upstream bandwidth per seat, so confirm the lab's uplink can carry the full room before exam day, not during it
• Seating: proctoring records what happens on the device; it does not stop a student reading a neighbour's screen, so keep the physical spacing you would use for a paper exam
• Devices: one student, one device is enforced by the platform, but decide in advance what your fallback is when a machine dies mid-exam, because one will
• Power: know which labs are on backup power, and schedule around known load-shedding windows where they exist

Every proctoring module a student will sit under should be communicated before the attempt, in plain language: camera and audio monitoring tied to verified identity, a locked fullscreen environment, the clipboard sealed, tab switches counted, paste events hashed. On Assessly the configuration is frozen when the attempt starts, so the rules a student sees at the beginning are the rules for the whole session. Students who know the rules in advance argue with them less afterwards, and a documented briefing is the first exhibit in any appeal.

Most integrity disputes are really communication disputes. The student who knew exactly what was recorded rarely contests what it recorded.

Once the exam starts, the system is doing three jobs at once. It is locking the environment: fullscreen enforced, clipboard sealed, concurrent logins blocked. It is recording evidence: identity-verified camera and audio, tab-switch counts, typing patterns, hashed paste events, each logged with a timestamp and context. And it is protecting the attempt itself: the timer runs on the server, not the student's machine, and work autosaves continuously.

That last part is what carries you through the failure everyone in India plans for. When power drops or a network blips, the student's clock did not stop and their work did not vanish. They log back in, the server-side timer is where it should be, the autosaved work is intact, and the gap itself is in the log for the review that follows. Invigilators should know this cold, because a calm "log back in, your work is saved" prevents the panic that turns one dead socket into a disrupted room.

A flag during the session is a recorded observation, not an alarm. Resist the urge to confront a student mid-attempt over a tab-switch count. The evidence is timestamped and is not going anywhere, and an interrupted exam creates a genuine grievance to replace a suspected one. Invigilators intervene during the session for the things software cannot see: a phone on a lap, a conversation between seats, an impersonation attempt at the door. The software watches the machine so the humans can watch the room.

Do not release results the moment the exam ends. Run a moderation pass first, in a fixed order:

• Resolve interrupted attempts: match every disconnection in the logs against the invigilator's notes on power and network, and clear the ones with an innocent explanation
• Review flagged sessions: read the context around each flag, since a single tab switch means something different from forty of them alongside paste events
• Read the score pairs: a strong code score over an empty explanation is the signature of borrowed work, and it is evidence a reviewer can read directly rather than a suspicion
• Record decisions: note who reviewed each flagged case and what they concluded, because that record is what the appeal process will stand on

This is where the evidence-not-accusations design pays for itself. Assessly never zeroes a score or issues a verdict on its own. Every flag arrives as a documented observation with timestamps and context, which means your review board starts from facts it can examine rather than from a vendor's opinion it has to defend. Students see what was recorded about their own session, appeals argue about evidence instead of about a black box, and the decisions that end up mattering are made by people accountable for them.

Honesty about limits: no online proctoring system stops a determined student with a second phone propped out of camera view, a helper in the room, or a question they have already memorized. Lockdown raises the cost of cheating and records the attempt; it does not make cheating impossible, and a vendor who claims otherwise is selling something.

That is why the durable protection in this runbook is the first section, not the middle ones. An exam built on original problems, where half the grade comes from the student explaining their own work, is hard to fake even for the student who beat the room. The environment controls narrow the channel; the assessment design is what closes it.

Rehearse with the real proctoring config a week early. Write questions that have not circulated. Brief students on exactly what is recorded. Trust the server-side timer and autosave when the power does what power does. Log flags, do not litigate them mid-exam. Moderate before you publish, and keep humans on every verdict.

For how the integrity tooling is built, see security. To walk through this runbook against your own exam calendar, get a demo, or read more about how universities run Assessly.