Cheating Detection
Prevention reduces cheating. Detection catches what prevention misses. The combination of both makes cheating not worth the risk.
The Deterrence Principle
The most powerful detection isn't catching every violation after the fact. It's making participants believe they'll be caught. When teams know that submissions are automatically analyzed across multiple dimensions, most won't try to cheat in the first place.
That's why we recommend telling participants that integrity checks will be run, without specifying exactly what those checks look for. The ambiguity is the deterrent.
Announce, don't detail
What to Check
Before announcing winners or distributing prizes, organizers should verify submissions across these dimensions. Some checks can be automated, others require human judgment.
Check the Git History
A project's git history reveals when work actually happened. Check when the repository was created, whether commits exist before the event start date, and whether the development pattern looks like a real hackathon build (messy, iterative) or a pre-built project (clean, organized from the start). This is the single most reliable integrity signal.
Compare Contributors to the Team
GitHub shows who committed code to a repository. Compare that list against the registered team members. If there are more contributors than team members, someone outside the team may have helped. If a team member has zero commits, they may not have actually contributed.
Look for Recycled Projects
Before awarding prizes, do a quick check: search the project name, look at the team's GitHub profiles for similar repositories, and check if the same project appears on other hackathon platforms. Teams that recycle projects often don't bother changing the README or project description between events.
Verify the Demo Matches the Code
Ask the team to demo off-script. Request unexpected inputs. Have a technical judge glance at the codebase to confirm the claimed tech stack is actually used. If a team claims "powered by machine learning" but the code is just if/else statements, that's worth questioning.
Assess Code Maturity
A hackathon project built in 24 hours looks fundamentally different from a production codebase developed over months. Look for signs of maturity that don't match the timeframe: comprehensive test suites, detailed documentation, complex CI pipelines, or polished error handling throughout. These are great in production but suspicious in a weekend project.
Protect Audience Voting
If your event includes audience voting or public choice awards, use a platform with built-in rate limiting and abuse detection. Watch for sudden spikes in votes from the same IP ranges, and consider limiting voting to registered participants rather than open public links.
Manual vs. Automated Detection
Small events (under 20 submissions) can get by with manual spot checks. But as events scale, manual verification becomes impractical. The answer is layered: automate the systematic checks, reserve human judgment for flagged submissions.
Manual Checks
- Technical Q&A during judging (ask teams to explain decisions)
- Live demo verification (request off-script interactions)
- Spot-checking code for suspicious patterns
- Comparing check-in progress with final submission
Best for: small events, final verification of flagged submissions
Automated Checks
- Repository and commit analysis at scale
- Contributor matching against team registration
- Cross-event duplicate detection
- Voting pattern anomaly detection
Best for: events at any scale, consistent and unbiased verification
What Good Verification Looks Like
Whether you build your own pipeline or use a platform, the goal is the same: organizers should see clear, actionable information for each submission without needing to understand git internals or run command-line tools.
Example: What Organizers Should See
A summary of checks with clear pass/review/flag indicators. The specifics depend on your tools and process, but the format should be simple enough that any organizer can act on it.
Timeline Verification
PassDevelopment activity is consistent with the hackathon timeframe. No pre-event work detected.
Team Verification
PassAll code contributors match registered team members.
Originality Check
PassRepository is not a fork of existing work. No signs of recycled project structure.
Development Pattern
ReviewCode volume is higher than typical for this hackathon duration. Recommend verifying during technical Q&A.
Handling Findings
When detection methods flag a submission, follow a fair process. Flags are signals, not verdicts.
Review the evidence privately
Don't publicly accuse anyone. Review the flags with your co-organizers first. Many flags have legitimate explanations that become obvious with context.
Have a conversation with the team
Give the team an opportunity to explain. Most honest teams have straightforward answers. This conversation alone reveals a lot about whether the concern is valid.
Make a decision as a team
Decisions should be made by at least 2-3 organizers, not one person. Options include: accepting the explanation, adjusting scores, disqualifying the submission, or noting the concern for future events. Document your reasoning.
Communicate the outcome respectfully
If you disqualify a team, do it privately and explain which rule was violated. Provide the evidence. Allow them to respond. Maintain their dignity regardless of the outcome. Public shaming never helps.
Flags are not verdicts