Hackathon Cheating Prevention
The best defense is making cheating hard and honesty easy. These frameworks reduce cheating before it happens by setting clear expectations and removing opportunities.
The Prevention Pyramid
Prevention works in layers. Each layer catches what the one above missed. Start at the top (cheapest to implement) and work down.
Clear Rules & Honor Code
Most accidental cheating happens because rules aren't clear. A well-written honor code eliminates ambiguity and gives you grounds for disqualification when needed.
Submission Requirements
Require GitHub repos, mandate live demos, ask for technical write-ups. Each requirement creates a paper trail that makes cheating harder and detection easier.
Milestone Check-Ins
Periodic check-ins during the hackathon create a timeline of progress that's very hard to fake. They also encourage teams and prevent scope creep.
Technical Verification
Technical Q&A during judging, code review of submissions, and automated integrity checks. This is your last line of defense and the most powerful.
The Honor Code
An honor code sets expectations and creates a social contract. Participants who agree to specific rules are far less likely to break them, and you have clear grounds for action when they do.
Sample Hackathon Honor Code
Copy and adapt this for your event. The best honor codes are specific enough to be enforceable but flexible enough to accommodate different project types.
Original Work
All projects must be started from scratch during the hackathon timeframe. You may use publicly available libraries, frameworks, APIs, and open-source tools. You may not use pre-existing projects, private codebases, or substantial code written before the event.
What's Allowed
- Public frameworks and starter templates (Create React App, Next.js, etc.)
- Open-source libraries and packages from package managers
- Public APIs and third-party services (Stripe, AWS, OpenAI, etc.)
- AI coding assistants (Copilot, ChatGPT, Claude) with disclosure
- Design assets from public sources (icons, fonts, stock images)
What's Not Allowed
- ✗Projects or code written before the hackathon start time
- ✗Submitting projects entered in other hackathons or competitions
- ✗Contributions from people not registered on your team
- ✗Misrepresenting functionality in demos (hardcoded data, mocked APIs)
- ✗Manipulating voting systems or coordinating external votes
AI Tool Disclosure
We encourage using AI tools to accelerate your work. In your submission, please include a brief description of which AI tools you used and what they helped with. This is not penalized - it's about transparency.
Consequences
Violations of this honor code may result in disqualification from the current event and potential exclusion from future events. The organizing team reserves the right to investigate submissions and make final determinations.
When to present the honor code
Submission Requirements
Every requirement you add creates a verification point. The goal isn't bureaucracy - it's creating a paper trail that makes cheating visible.
Require a public GitHub repository
This is the single most important requirement. A public repo lets you verify commit timelines, contributor counts, and code quality. Teams should create a new repository at or after the hackathon start time.
What to specify in rules:
- - Repository must be created after the hackathon start time
- - Repository must remain public until judging is complete
- - All team members must be listed as collaborators
- - Commit history must not be rewritten or squashed before judging
Require a live demo (not pre-recorded)
Live demos are much harder to fake than pre-recorded videos. They reveal bugs, incomplete features, and hardcoded data in ways that edited videos never will. If virtual, require screensharing with the judge controlling the navigation.
For virtual hackathons:
If live demos aren't feasible (large events, async hackathons), require an unedited screen recording that shows the full user flow including the browser address bar. This makes it harder to splice together working fragments.
Require a technical write-up
Ask teams to describe their architecture, what technologies they used and why, what they built vs. what they used off-the-shelf, and what challenges they faced. This creates a verifiable claim that can be checked against the code. Teams that built the project themselves can easily explain these decisions; teams that didn't will struggle.
Require individual contribution statements
Each team member describes what they personally contributed. This deters ghost contributors (who can't be listed) and helps judges assess whether the work distribution is realistic for the team size.
Milestone Check-Ins
Periodic check-ins create a verifiable timeline of progress. A team that built everything during the hackathon can show natural progression. A team submitting pre-built work will have a suspiciously complete project at the first check-in.
Kickoff Check-In
First hour of the hackathon
Teams share their idea, planned tech stack, and team members. This creates a baseline. If a team later presents something completely different from what they described at kickoff, it raises questions about when the real project was started.
Mid-Point Check-In
Halfway through the hackathon
Teams show what they've built so far. It should be rough, incomplete, and clearly in progress. A team that has a polished, feature-complete product at the midpoint is either exceptionally fast or started early. Ask specific questions: "What's not working yet? What's your biggest challenge right now?"
Pre-Submission Check-In
2-3 hours before submissions close
Teams share progress and get final mentorship. This check-in helps mentors identify teams that might need help, and creates another verification point. The progression from mid-point to pre-submission should show visible development.
Keep it lightweight
Technical Q&A During Judging
The most effective anti-cheating tool is a judge who asks the right questions. Teams who built the project themselves can easily explain their decisions. Teams who didn't will stumble.
Architecture Questions
- "Why did you choose this tech stack?"
- "Walk me through how data flows from the frontend to the database."
- "What was the hardest technical decision you made?"
- "If you had another 24 hours, what would you change architecturally?"
Implementation Questions
- "Show me the code for [specific feature]. How does it work?"
- "What was the biggest bug you ran into?"
- "How does [the API integration] actually work in your code?"
- "Can you show me a different path through the app than your demo?"
Process Questions
- "How did you split the work among team members?"
- "What was the first thing you built?"
- "What did you learn during this hackathon?"
- "What would you do differently next time?"
Verification Questions
- "Type something unexpected into that input field."
- "What happens if the API is slow or fails?"
- "Can you run the project from the command line right now?"
- "Show me the commit history in your terminal."
Train your judges
Creating Your AI Tools Policy
AI coding tools are now standard practice. Banning them entirely is impractical and discourages adoption of legitimate productivity tools. Instead, focus on transparency and disclosure.
Recommended Approach
- Allow AI tools (Copilot, ChatGPT, Claude, etc.)
- Require disclosure of which tools were used
- Ask teams to describe what AI helped with
- Judge the final product, not the process
- Value understanding over generation (test via Q&A)
What to Add to Your Submission Form
"AI Tools Disclosure" (optional text field):
"Please list any AI coding assistants or code generation tools you used during this hackathon (e.g., GitHub Copilot, ChatGPT, Claude, Cursor). Briefly describe what they helped with. Using AI tools is not penalized - we value transparency."