A good hackathon problem statement names who is affected, what the problem is, when and where it happens, and why it matters. It includes data [1]. It describes the outcome you want, such as a measurable target, and leaves the tools and architecture to the teams [1][3].
What a strong statement contains
HackerEarth reduces a strong statement to four questions: who is affected, what the problem is, when and where it occurs, and why it matters [1]. Ainna's template is longer. It has six parts: a title, the situation, the gap, who lives with it, why now and why it matters, and a realistic weekend result that a team could show on Sunday [4].
Length matters too. Eventornado says a statement should be neither too long nor too short [6]. In practice, that means a short paragraph for the situation, one or two lines for the gap, and a clear line for the weekend result.
Describe the problem, not your favourite fix
The most common mistake is writing the solution into the problem. If the statement says build a mobile app with a chatbot, you have written a brief for one idea. Describe the problem and the environment it has to work in. Attendees can then put their effort into finding a viable solution [2].
Unstop makes a related point. A statement that dictates the exact architecture tests whether teams can follow instructions, not whether they can solve problems. Its suggested formula is a real problem plus hard constraints on data, technical requirements and time limit, with the approach left open [3].
Make the gap measurable
Show the distance between the current state and the state you want. Unstop contrasts a measurable baseline, tickets taking 48 hours to resolve, with a vague goal, improve support efficiency. The measurable version gives teams a sharper task [3]. HackerEarth recommends a SMART structure: specific, measurable, achievable, relevant and time-bound. Judges can then score against clear metrics [1].
| Weak version | Stronger version | Why it is stronger |
|---|---|---|
| Improve support efficiency | Cut ticket resolution from 48 hours to a target you set | A baseline and a number give teams a fixed finish line |
| Help students learn better | Help first-year students finish a weekly practice set, with a drop-off rate you measure | It names who, what and the measure |
| Make campus events safer | Reduce waiting time at one entry gate during a set entry window | It names a place, a time and a metric |
The stronger versions are our own rewrites of the pattern in the sources, not quotes from them.
Keep the scope to one weekend
Scope is where many statements fail. Broad statements lead to false starts, so keep the scope small enough for real progress in one weekend [2]. Ainna keeps the full problem in the statement and puts only the achievable slice in the weekend-result section [4]. Attendees see the real problem. Judges get a fair target for the time available.
If you want to test engineering skill, list required technologies and quality standards up front, such as a minimum number of test cases and coding standards [1]. If you want to test problem framing, leave the tools open and say so.
Use real data and test the statement before release
Make sure any data the problem depends on is open and easy to reach [2]. A problem that needs a dataset nobody can get on Saturday is not a hackathon problem.
Pre-test draft statements before you publish [2]. Give the draft to someone outside the writing team. Ask them to explain back what they would build and how they would judge it. Any answer that differs from your intent shows where to tighten the wording.
A worked example from a national-scale brief
A HackerEarth example from a GE Healthcare hackathon in India states the problem as a shortage of experienced healthcare professionals in rural India. It links the shortage to maternal care gaps and diagnostic delays, under a Digital Healthcare theme [8]. The statement names a population, a gap and a consequence.
The Bureau of Indian Standards guidelines go further. Each problem statement must be documented with background, objectives, expected outcomes and evaluation criteria, and approved before release [7]. Its sample software statement sets out a nodal department, category, title, background, description, expected solution, platform, deliverables and timelines [7]. A college hackathon does not need that much paperwork. The headings still make a useful checklist.
Publish judging criteria and set the tech rules
Publish judging criteria with the problem statement, not after submissions close. Unstop says this reduces disputes [3]. Ainna suggests one theme, three to seven statements per judged track, and one open track [4]. Teams get a manageable choice, and you still leave room for ideas you did not expect.
Ainna also recommends writing the problem as if the technology did not exist, then naming the allowed technologies in the brief [4]. 99P Labs suggests a curated wiki of short introductions and documentation for the tools you expect teams to use, so no one gets stuck on setup [5]. For a broader audience, 99P Labs argues for open-ended questions so participants without a specialist background can still engage. It says a narrow question can be paired with a broader one [5].
Where Sprint fits in
Unifesto Sprint supports hackathon teams and problem statements. Rounds use weighted rubrics, judge panels, in-app submissions and a live leaderboard. If you publish judging criteria with the statement, Sprint can carry the same rubric through the rounds Sprint. Sprint is a Pro feature.
Our view
Our view: write the statement a little broader than feels comfortable. Keep the hard constraints few and explicit, covering data, technical requirements and the time limit, as Unstop suggests [3]. Most organisers over-specify the approach because they fear teams will drift. In our reading of the sources, drift usually signals a vague gap, not a broad problem. Fix the measure first, then widen the route.
Limitations of this advice
The sources do not fully agree. HackerEarth and Unstop push for quantified, specific constraints. 99P Labs argues for broader, more open questions to lower the entry barrier. The sources do not reconcile these, so you must balance them for your own crowd. A first-year college hackathon may need more openness than a sponsored challenge with an industry partner.
The two Medium pieces on writing problem statements look old, roughly from 2014 by their page metadata. Treat their advice as background rather than current practice [2]. The advice here comes from blog guides and organiser handbooks, not from measured outcomes at college hackathons.
FAQ
Should a hackathon problem statement include a solution?
No. Describe the problem, the environment and the outcome you want, and leave the approach open [2][3]. If you need teams to use a particular tool, name it as a constraint and say why.
How many problem statements should a college hackathon have?
Ainna suggests one theme with three to seven statements per judged track, plus one open track [4]. Fewer statements make judging easier, and a clear theme helps teams choose faster.
How do I know if my problem statement is too big for one weekend?
Check whether a team could show a real result on Sunday. Ainna recommends putting the achievable slice in a weekend-result section, so the full problem stays visible while the target stays fair [4].
Do I need a budget for a hackathon?
Yes. Our guide to organising a college hackathon starts with the format, a checklist and a budget that covers food and prizes, then moves on to problem statements and judging Our guide to organising a college hackathon. For a broader budget plan, see how to make a budget for a college fest.
For judging panels, see how many judges you need for a hackathon.
Sources
- Hackathon Problem Statements: Examples & Ideas for 2026: https://www.hackerearth.com/blog/crafting-hackathon-problem-statements
- Defining Problem Statements. How to Throw the Perfect Hackathon…: https://medium.com/@murby/defining-problem-statements-417aa79ac5d3
- How to Design Hackathon Problem Statements That Convert: https://unstop.com/blog/hackathon-problem-statement-design-guide
- How to Write a Hackathon Problem Statement: Template: https://ainna.ai/resources/faq/hackathon-problem-statement
- How to Generate Better Hackathon Problem Statements: https://medium.com/99p-labs/how-to-generate-better-hackathon-problem-statements-194a313f8fde
- Hackathon problem statements: https://eventornado.com/blog/hackathon-problem-statements
- Guidelines for Organizing Hackathon 1. Introduction: https://www.bis.gov.in/wp-content/uploads/2024/08/Guidelines-for-organizing-the-upcoming-Hackathon-with-Problem-Statements.pdf
- The complete guide to organizing a successful hackathon: https://www.hackerearth.com/community-hackathons/resources/e-books/guide-to-organize-hackathon/