PIET Quest Exam Portal

Problem & Context

Online assessments at PIET needed stronger protection against cheating than a static question list provides — students sitting the same exam shouldn’t be able to easily share answers in real time.

Solution & Architecture

PIET Quest combined two integrity mechanisms:

• Randomized question-set creation — each student (or session) receives a different selection of questions from a shared pool, rather than a single fixed paper.
• Detected-cheating-based reordering — question order changes dynamically based on detected cheating signals, making it harder to coordinate answers by position/sequence even within the same question set.

Supporting automation scripts handled downloading feedback reports and uploading new questions in bulk, reducing manual administrative work for faculty maintaining the question bank. The exact cheating-detection signal isn’t detailed here, since what’s safe to disclose publicly about detection logic for an exam-integrity system is deliberately conservative.

Key Decisions & Tradeoffs

Randomizing question sets per student and reordering by detected-cheating signal are two different integrity mechanisms, not one — randomization protects against pre-arranged answer sharing (“compare answer #4”), while reordering protects against real-time signaling during the exam itself. Treating them as one combined feature would have made it harder to reason about which mechanism actually stopped a given cheating attempt, or to tune one independently of the other as faculty feedback came in.

The bulk-upload/download automation for question banks and reports was scoped as a separate concern from the integrity logic for a similar reason: faculty workflows around managing the question pool change far more often than the integrity rules themselves, and coupling the two would mean every administrative tooling change risked touching exam-day logic.

Lessons Learned

Building integrity features alongside the core exam-taking flow (rather than bolting them on later) made it easier to keep randomization and reordering consistent — both needed access to the same underlying question-pool and session state. Keeping the detection-signal implementation separate from the reordering UI also meant the detection approach could be tightened over time without changing how question order is presented to the student.

The broader pattern worth carrying into other integrity-sensitive systems: a single combined “anti-cheating” feature is harder to evolve than several smaller mechanisms each targeting one specific attack vector, because improving one mechanism’s accuracy doesn’t risk regressing an unrelated one, and faculty trust in the system grows incrementally as each mechanism proves itself rather than all-or-nothing.