Every Way People Cheat at Hackathons
Every known method of hackathon cheating, categorized and explained. Understanding the problem is the first step to solving it.
Cheating at hackathons takes many forms, from obvious (submitting a project you built months ago) to subtle (hardcoding demo data to make a feature look functional). After analyzing hundreds of hackathon submissions and talking to organizers across corporate, university, and community events, we've identified six distinct categories.
Not every instance is malicious. Sometimes teams genuinely don't understand the rules. A team might not realize that reusing code from a previous project violates the spirit of the hackathon. Clear rules and education prevent the accidental cases, while detection methods catch the intentional ones.
A note on intent
1. Pre-Work & Prior Art
The most common and impactful form of cheating
This is when teams submit projects that were partially or fully built before the hackathon started. It's the most common form of cheating because it's the easiest to rationalize ("I just had a head start") and the hardest to catch without tooling.
Early commits in the repository
The most obvious signal. The team's GitHub repo has commits dating back days, weeks, or even months before the hackathon started.
What it looks like:
A hackathon starts on Saturday morning, but the repo shows 50+ commits from the previous week, with the core architecture already in place. During the hackathon itself, only a few cosmetic commits appear.
Large initial commit ("code dump")
A single massive first commit containing thousands of lines of organized, production-quality code. Legitimate hackathon projects start messy and evolve. A clean, complete codebase appearing in one commit is a red flag.
What it looks like:
First commit: "Initial commit" with 15,000 lines of code, a complete folder structure, proper error handling, and comprehensive tests. This wasn't built in the last 2 hours.
Repo created before the event
The GitHub repository itself was created days or weeks before the hackathon. Even if early commits are squashed or history is rewritten, the repository creation date is immutable on GitHub.
What it looks like:
Hackathon runs March 15-16. Repository was created on March 1. Even if the commit history shows only March 15-16 commits, the repo creation date tells the real story.
Using an existing side project
A team takes a project they've been working on for months, pivots the narrative to fit the hackathon theme, and presents it as new work. The functionality already exists, they just added a fresh coat of paint.
What it looks like:
A mature project with extensive documentation, multiple release tags, and months of git history. During the hackathon, they add a new landing page and a few features related to the theme.
The gray area
2. Recycled Projects
The same project on a hackathon world tour
Teams submit the same project (or a slightly modified version) to multiple hackathons. This is especially common when prize money is involved. The project gets polished over time, giving it an unfair advantage over genuinely new work.
Same project, different hackathon
The exact same repository URL submitted to multiple events. The team might change the project name or description, but the code is identical. Sometimes they don't even bother changing the name.
Minor theme re-skinning
A team has a solid project and adapts the pitch to match each hackathon's theme. The healthcare hackathon version becomes "MedTracker." The fintech hackathon version becomes "FinTracker." The code is 95% the same - they just swap the color scheme and landing page copy.
Class projects and thesis work
University students submit course projects, capstone work, or thesis research as hackathon entries. The work may be impressive, but it wasn't built during the hackathon and had the advantage of weeks or months of guided development.
Why recycling is harmful
3. Team Violations
More people than the rules allow, or the team shows
Team violations range from innocent confusion about the rules to deliberate attempts to gain a workforce advantage. When one team has 8 people and another has 3, the playing field isn't level, especially if the larger team hides extra members.
Ghost team members
People who contribute code, design, or other work but aren't listed on the team. They might be friends, colleagues, or even hired freelancers. Their contributions appear in the git history but they're invisible in the registration.
Exceeding team size limits
The hackathon says "teams of 2-4" but the team actually has 6 members, with only 4 registered. The extra members contribute significantly but don't appear on any official record. Commit history will show more unique authors than registered members.
External professional help
A team brings in an experienced developer, designer, or subject matter expert who isn't a registered participant. This person might not commit code directly but guides architecture decisions, writes critical algorithms, or creates the demo presentation.
One person, multiple teams
A participant registers on multiple teams, hedging their bets. They contribute to whichever project looks most promising, or split their time across teams and claim credit for the winning one.
How to distinguish from mentorship
4. Demo & Presentation Fraud
When what you see isn't what you get
This is the hardest category to detect, especially during live events where judges have limited time. Teams make their project look more functional, more polished, or more technically sophisticated than it actually is.
Hardcoded demo data
The app shows impressive results, charts, or outputs, but they're all hardcoded into the frontend. There's no actual backend processing happening. The "AI analysis" is just a pre-written response. The "real-time data" is a JSON file.
What it looks like:
The demo shows a beautiful dashboard with live analytics. But when you check the code, the data comes from a static JSON file, not an API. The charts will always show the same data regardless of input.
Mocked API responses
The team claims to use a specific API or service, but the responses are mocked. The "GPT-4 integration" returns pre-written text. The "payment processing" never actually contacts Stripe. The API key in the code might even be fake.
What it looks like:
The code contains an API call, but it's wrapped in a condition that always returns the mock data. Or the API endpoint points to a local server that returns canned responses.
Pre-recorded or edited demo videos
Instead of a live demo, the team shows a carefully edited video that hides bugs, loading times, or non-functional features. The video might even show a different version of the product than what's in the submitted code.
Misleading tech stack claims
Teams claim to use impressive technologies - "powered by machine learning," "built with blockchain," "uses computer vision" - when the actual implementation is trivial or non-existent. The ML model is a simple if/else. The blockchain is just a database. The computer vision is a pre-trained model with no customization.
"Happy path" only demos
The demo follows one specific path that works perfectly. Any deviation from that exact flow causes crashes, errors, or reveals that the feature doesn't actually work. The team has rehearsed this one path extensively and avoids showing anything else.
Why this is uniquely damaging
5. Code Misrepresentation
Not their code, or not what they claim it is
This category covers situations where the code itself isn't what the team represents it to be. From outright plagiarism to undisclosed use of AI code generation, these violations undermine the "built it ourselves" spirit of hackathons.
Plagiarized open source code
A team takes an existing open-source project, removes the license and attribution, makes minor changes, and presents it as their own work. This goes beyond using libraries - it's copying the core application logic without credit.
Forked repos with cosmetic changes
Similar to plagiarism but using GitHub's fork feature. The team forks an impressive project, changes the name and branding, adds a few small features, and submits it. The fork relationship is visible on GitHub, but only if you look.
Undisclosed AI-generated code
This is an evolving area. With tools like GitHub Copilot, ChatGPT, and Claude, teams can generate significant portions of code. The question is whether the hackathon allows it and whether teams disclose it.
The nuance:
Most modern hackathons now allow AI tools - the question is degree and disclosure. Using Copilot for autocomplete is different from having GPT-4 generate your entire backend. Your rules should be explicit about what's expected.
Tutorial/course project resubmission
A team follows a YouTube tutorial, online course, or coding bootcamp project step-by-step, then submits the result as their hackathon project. The code is technically "theirs" (they typed it) but the design, architecture, and logic came entirely from an external source.
The AI question
6. Vote Manipulation
Gaming the voting system for unfair results
When hackathons include audience voting or public choice awards, the voting system itself becomes a target. This is especially common in online hackathons where physical presence can't verify voter identity.
Ballot stuffing
Creating multiple accounts or using multiple devices to vote for the same project repeatedly. More sophisticated versions use VPNs or proxy servers to make each vote look like it comes from a different person.
Coordinated external voting
Teams share voting links on social media, group chats, or community forums and ask people to vote for their project. These voters have never seen the other projects and are voting based on friendship, not merit. This is especially common when audience choice awards carry significant prizes.
Strategic negative voting
In systems that allow downvoting or ranking, teams strategically give competing projects low scores while giving their own project the highest score. When many team members coordinate this, it can significantly affect rankings.
Judge influence
Teams with personal connections to judges leverage those relationships for favorable scores. This can be direct ("please score us well") or indirect (a judge scoring their colleague's team more generously). Conflicts of interest that aren't disclosed undermine the entire judging process.