You Can't Stop Students From Cheating on Online Exams. Here's What Actually Works.

Every client building an exam platform asks me some version of the same question early in the project: how do we stop students from cheating?

It's the right thing to worry about. If your assessments can be gamed, the credential behind them is worthless, and a worthless credential takes your whole platform down with it. But the question itself points people toward the wrong solution. They start shopping for surveillance when they should be rethinking the exam.

Here's the honest answer I give every one of them: you can't stop cheating completely. And the harder you try to catch it, the worse you make the experience for everyone who never planned to cheat.

The surveillance arms race has no finish line

The instinct is to lock everything down. It feels like control. In practice, every layer of monitoring gets defeated, and usually faster than the budget it cost to build.

Lockdown browsers prevent students from opening new tabs during an exam. They also get bypassed by a second phone propped up next to the laptop. Webcam proctoring watches the student's face and flags suspicious movement. It also gets beaten by notes taped just behind the screen, or a second person sitting out of frame. AI-based proctoring claims to detect cheating behavior automatically. In reality it flags anxious students who look away to think, misses the ones who prepared properly, and quietly introduces bias against anyone whose testing environment or appearance doesn't match what the model expects.

Each of these tools adds cost, adds friction, and adds a layer of distrust between you and your learners. And none of them solve the problem, because the problem isn't really technical. It's a design problem wearing a surveillance problem's clothing.

Design exams that are hard to cheat on in the first place

The platforms that handle this well spend their budget on the assessment design, not the surveillance stack. Three things do most of the work.

Randomized question pools. Instead of every student sitting the same 30 questions, you build a bank of 150 and serve each student a randomized subset. Now there's no single answer key to pass around. Sharing answers becomes nearly useless because no two exams match. This is straightforward to build and it removes the most common form of cheating: students simply telling each other what's on the test.

The detail people miss is balancing. If you randomize naively, one student draws thirty easy questions and another draws thirty hard ones, and now your exam is unfair in a different direction. The fix is to tag every question in the bank by topic and difficulty, then randomize within those constraints. Pull two questions from each topic, balanced across easy, medium, and hard, so every generated exam is different in content but equivalent in difficulty. As a rough rule, the bank should be at least four to five times the size of the exam. A 30-question test wants a pool of 150 or more, or the randomization gets shallow enough that overlapping exams start showing up and the answer-sharing problem creeps back in.

Time pressure calibrated to knowledge, not speed. When an exam gives generous time, looking up answers is easy and low risk. When the time budget assumes the student already knows the material, every lookup costs more than it's worth. You're not trying to stress people out. You're tuning the clock so that the fastest path to a good score is actually knowing the answer, not searching for it.

The way to find the right budget is to have a few people who know the material take the exam and track how long they actually need. Take that time and add a reasonable margin, maybe 25 to 50 percent, so you're not punishing slow readers or anyone who needs accommodations. The point isn't to make the clock a weapon. It's to set it so that a prepared student finishes comfortably while someone trying to google every answer simply runs out of road. If your honest test-takers are leaving huge amounts of time on the table, your window is too wide and you've quietly left the door open for lookups.

Question types that test application, not recall. You can google a definition. You can't google your way through a scenario that asks you to apply a concept to a situation you've never seen. Move away from "what is X" and toward "here's a situation, what would you do and why." Recall questions reward memorization and lookup. Applied questions reward understanding, and understanding is the thing you actually wanted to measure.

Here's what that shift looks like in practice. Say you're testing whether someone understands database indexing.

The recall version: "What is a database index?" A student types that into any search engine and has the answer in three seconds. You've measured their ability to use Google.

The applied version: "A query that filters a million-row table by email address is running slowly. The email column has no index. Explain what's happening and what you'd change." Now the student has to actually understand what an index does, why the query is slow without one, and how adding one changes the behavior. There's no single sentence to copy from a search result. They either get the concept or they don't, and the answer shows you which.

That rewrite is the whole game. Same underlying knowledge, completely different thing being measured. The recall question tests whether they can look something up. The applied question tests whether they understood it. Build an exam mostly out of the second kind and cheating stops being a shortcut, because there's nothing short to take.

A quick example

One way to see the difference: imagine two versions of the same exam.

Version one is 30 fixed multiple-choice questions, the same for everyone, with a comfortable time limit and a lockdown browser enforcing honesty. A student opens a second device, looks up the answers, finishes early, and scores well. You learned nothing about what they know. You spent money on the lockdown browser anyway.

Version two pulls 30 questions from a pool of 150, mixes recall with applied scenarios, and sets a time budget that assumes preparation. No lockdown browser. A student who tries to look everything up runs out of time on the scenarios, because those can't be answered with a quick search. The student who studied finishes comfortably. The score now reflects the thing you wanted to measure, and you spent nothing on surveillance.

The second exam is harder to build. That's the trade. But it's the right place to spend the effort.

Proctoring catches cheaters. Design makes cheating pointless.

There's a place for proctoring. High-stakes certification exams with legal or professional weight sometimes require it, and some accrediting bodies mandate it. If you need it, build it. But treat it as the last layer, not the first, and never as a substitute for an exam that was designed to be cheat-resistant on its own.

If you're building assessment into your platform and you only have budget for one thing, put it into the question bank and the exam logic. A well-designed exam protects your credential quietly, every time it runs, without making your honest learners feel like suspects.

That's the engineering decision that actually moves the needle. Everything else is theater.

---

I build custom e-learning platforms and assessment systems for EdTech and L&D teams. If you're working through how to build trustworthy exams into your product, that's exactly the kind of problem I help solve.