Crafting hackathon problem statements that test real developer skills
Estimated read time: 8 minutes
Crafting hackathon problem statements is the practice of writing structured, constraint-driven challenges that push developers to build real solutions rather than surface-level demos. For recruiters, engineering leaders, and DevRel teams running internal or external hackathons, the quality of the problem statement determines whether the event surfaces genuine skill signal or produces a pile of half-built prototypes. Simple prompts like "build a better app" no longer differentiate strong candidates. Top events now require complex challenges that test architecture, security, and the use of emerging protocols such as the Model Context Protocol (MCP) — an open standard, introduced by Anthropic in late 2024, for connecting AI assistants to external tools and data sources.
What makes a hackathon problem statement actually good?
A good hackathon problem statement gives clear direction while leaving room for creative solutions. What separates a routine project from a standout one is real-world difficulty — often introduced through strict data limits, legacy system integration, or explicit ethical and security constraints.
One widely used approach is the SMART framework — specific, measurable, achievable, relevant, and time-bound — originally proposed by George T. Doran in a 1981 Management Review article and adapted here for hackathon design. For example, instead of asking for a general "sustainability app," a better prompt would ask for a way to reduce data center water use by fifteen percent using an AI-powered cooling system. This level of detail lets judges measure solutions with clear metrics instead of relying on gut feel.
A trade-off to note: rigid SMART constraints can over-specify a problem and stifle creative approaches. Organizers should leave the how open even when the what is precise.
| Feature | Toy problem statement | Professional problem statement |
|---|---|---|
| Scope | Vague ("Build a social app") | Specific ("Create a latency-optimized social platform for remote workers") |
| Constraints | None or minimal | Strict (e.g., must use MCP, must handle 10k concurrent users, must be secure-by-design) |
| Data | Mock/Dummy data | Real-world datasets or high-fidelity simulated enterprise patterns |
| Evaluation | Subjective "innovation" | Quantitative (F1 score, semantic similarity, load test results) |
| Goal | Prototype | Scalable, maintainable, and deployable MVP |
Adding an "agentic layer" or "security layer" is a defining feature of today's advanced challenges. When developers have to build features like automated triage or vulnerability scanning, they start thinking more like systems architects than feature builders. According to Stack Overflow's 2024 Developer Survey, 76% of developers are using or planning to use AI tools in their workflow, so the real test is not just using them, but using them responsibly and at scale. HackerEarth's assessment platform is built around this same principle: measuring not just whether a candidate can produce code, but whether they can reason through constraints under time pressure.

How to write a problem statement (step-by-step): crafting hackathon problem statements in practice
Crafting problem statements is a distinct skill. It requires empathy for the end-user and a working grasp of the technology involved. Start by identifying the root cause of the problem, not just the symptoms — for instance, if support tickets are backlogged, investigate whether the cause is tooling, staffing, or triage logic before framing the challenge.
Step 1: Identify the stakeholder pain points
Before writing anything, organizers should do primary research and talk to people affected by the problem. In practice, this means visiting a production floor to observe equipment issues, sitting with a support team to review ticket categories, or interviewing three to five end users to identify recurring friction. In company hackathons, systemic engineering problems — such as technical debt, which McKinsey estimates consumes 20–40% of a technology estate's value — often make the best problem statements.
Step 2: Define the five Ws and the baseline data
A strong problem statement answers the five Ws — who is affected, what the problem is, when and where it happens, and why it matters — a framework long used in journalism and root-cause analysis. It should also include data. For example, instead of saying "support tickets are slow," say "IT support tickets for database access take an average of 48 hours to resolve, affecting 500 engineers' productivity."
Step 3: Contrast current and future states
The best challenges clearly show the difference between the current state and the desired future state. This gap sets the goal for developers. The future state should be clear but not overly prescriptive — describe the result, like "automated ticket resolution with 90% accuracy," without dictating which tools to use.
Step 4: Layer in technical requirements and evaluation criteria
To meaningfully test developer skills, the problem statement should list required technologies and quality standards. This might mean asking for modular code, a defined test coverage target (many enterprise teams treat 70%+ line coverage as a baseline; organizers should set a threshold appropriate to project scope), and adherence to industry coding standards. Trade-off: overly strict criteria can push teams toward compliance rather than creativity.
Crafting Gen AI hackathon problem statements (3 levels)
Generative AI has raised the bar for hackathon projects. In competitive hackathon contexts, a basic chatbot — once a strong submission — is now typically treated as a starting point. When crafting hackathon problem statements for Gen AI tracks, focus on retrieval, grounding, and safety.
Level 1: Contextual prompt engineering and basic RAG
The objective here is to move beyond simple "zero-shot" prompting. Developers are challenged to build a system that uses a local knowledge base to provide grounded answers.
- Problem: A university's student handbook is a 300-page PDF that is difficult to search, leading to repetitive questions for administrative staff.
- Task: Build a "Handbook Copilot" that uses a vector database to retrieve relevant sections and provide cited answers to student queries.
- Goal: Demonstrate an understanding of embeddings, chunking strategies, and basic retrieval-augmented generation (RAG).
Level 2: Multimodal integration and agentic reasoning
At this stage, developers work with different data types and build logic that handles multi-step tasks.
- Problem: Fashion researchers spend hundreds of hours manually tagging social media images to identify emerging trends.
- Task: Create a "Style Weaver" that extracts visual elements (colors, textures, styles) from images using computer vision and synthesizes these with text analysis (hashtags, captions) to predict the next season's trending palette.
- Goal: Integrate vision-language models with clustering algorithms to provide actionable business intelligence.
Level 3: Enterprise-grade reliability and sentinel auditing
The toughest Gen AI challenges focus on trust, transparency, and preventing hallucinations.
- Problem: Financial institutions cannot deploy LLMs for customer-facing advice due to the high risk of hallucinated data causing regulatory breaches.
- Task: Develop a "Sentinel AI" system that runs two independent LLMs in parallel for every query. A third "Audit Agent" must cross-validate their outputs, perform a consistency check, and flag any discrepancy or toxic content before it reaches the user.
- Goal: Build a self-auditing architecture that meets enterprise compliance and safety standards.
Crafting agentic AI hackathon problem statements (3 levels)
Some industry analysts have described 2025 as the "year of AI agents," as the field shifts from passive models to active assistants that plan and carry out complex tasks. When crafting hackathon problem statements in this category, focus on agent-to-agent coordination and the Model Context Protocol (MCP). Note: MCP is still an emerging standard with limited but growing tooling support, so organizers should validate that reference implementations exist before requiring it.
| Level | Problem theme | Technical focus |
|---|---|---|
| Beginner | Intelligent task automation | Intent recognition, basic tool-use, single-agent workflows |
| Intermediate | Multi-agent research and synthesis | Agent orchestration, state machines, self-reflective RAG |
| Expert | Autonomous supply chain/industrial resilience | MCP servers, multi-modal sensor integration, ethical governance |
Level 1: The digital assistant for repetitive workflows
Automate one clear business process using a digital skill.
- Problem: HR teams spend a significant share of their time — often cited illustratively as around 20% — manually responding to emails about leave policies and updating internal trackers.
- Task: Build an agent that monitors a specific inbox, answers policy questions using a provided wiki, and — upon receiving a formal request — automatically updates a mock HR database.
- Goal: Demonstrate basic agentic orchestration and "tool-call" capabilities.
Level 2: The deep research meta-agent
This stage tests whether a team can coordinate specialized sub-agents working together, either in a group-chat topology or as part of a state machine.
- Problem: Professional analysts require structured research reports that draw from diverse web sources, academic papers, and financial filings.
- Task: Design an agent called "Apollo" that manages two sub-agents: "Athena" (the search engine) and "Hermes" (the analyzer). Athena gathers data using advanced web-search APIs, while Hermes checks for knowledge gaps and requests more information until the research itinerary is complete.
- Goal: Implement a two-stage synthesis process where section-specific content is generated before a final, cited report is assembled.
Level 3: The industrial "risk-wise" orchestrator
The most advanced level asks agents to work with real-world systems and unpredictable market data. Trade-off: expert-tier problems like this often exceed the standard 48-hour window and may be better suited to 72-hour or extended formats.
- Problem: Global supply chains are susceptible to port delays, geopolitical shifts, and sudden tariff changes that create material cost impact for large importers.
- Task: Build a "Supply Chain Risk Analysis System" that leverages AI agents to monitor shipping schedules and news feeds in real time. The system must use MCP to interact with SQL databases containing historical tariff data and any major cloud AI service (AWS Bedrock, Azure AI, or GCP Vertex — tool-agnostic; teams choose based on familiarity) to predict potential disruptions before they occur.
- Goal: Create a dashboard-driven system that provides "explainable" risk scores and automated mitigation strategies.
Crafting AI/ML hackathon problem statements (3 levels)
Traditional AI and machine learning remain central to predictive analytics and computer vision, particularly where text-based deep learning is not the primary need. These challenges test the fundamentals: data prep, model training, and deploying as a scalable API.
Level 1: Predictive analytics for health and wellness
Classic regression and classification tasks with structured sensor data.
- Problem: Rising sedentary lifestyles have led to an increase in preventable workplace injuries and chronic fatigue.
- Task: Develop a system that analyzes heart rate variability and motion data from wearable devices to predict "fatigue warnings" and suggest adaptive routines.
- Goal: Implement a clean ML pipeline using Scikit-learn or TensorFlow Lite for edge devices.
Level 2: Computer vision for industrial or agricultural automation
Image processing and specialized classification.
- Problem: Agricultural researchers in rural regions struggle with the manual classification of cattle and buffalo breeds, which is essential for genetic improvement and disease control.
- Task: Build an "Auto Recording of Animal Type Classification System" that uses images to extract body structure parameters (length, height, rump angle) and generates objective classification scores.
- Goal: Deploy a CNN model that maintains classification accuracy across diverse environmental backgrounds, lighting conditions, and camera angles.
Level 3: Real-time anomaly detection for fraud and cybersecurity
Stream-processing at low latency with high precision.
- Problem: Financial institutions face sophisticated fraud that evolves faster than traditional rule-based systems can detect.
- Task: Create a "Real-Time Intrusion Detection Dashboard" that processes network traffic and transaction logs to detect anomalies such as brute-force attempts or unauthorized access patterns using ensemble methods and transfer learning.
- Goal: Build a system that visualizes alerts with severity scores and recommends immediate defensive actions.
Crafting web development hackathon problem statements (frontend, backend, full-stack)
Web development hackathons have grown from single-page projects to complex full-stack events with professional expectations. These challenges test whether developers can build scalable, maintainable, secure systems.
Frontend: immersive experiences and state management
Frontend challenges now emphasize performance and modern UI frameworks like React 19.
- Problem: Global data centers consume massive amounts of energy, partially driven by inefficient "infinite scroll" designs that download data the user never sees.
- Task: Create a "Slow Your Scroll" web application that uses advanced virtualization and lazy-loading techniques to minimize data download while maintaining a smooth user experience.
- Goal: Demonstrate mastery of the DOM, accessibility (A11y), and energy-efficient web design.
Backend: scalable infrastructure and API orchestration
Backend challenges test the core of the app: security, database logic, and API performance.
- Problem: Small businesses struggle with invoice reconciliation — manually matching bank payments to thousands of outstanding bills across different currencies.
- Task: Build an "Invoicing & Reconciliation API" that handles bulk uploads, matches payments to invoices using fuzzy string matching and configurable tolerance rules, and integrates with third-party payment gateways like UPI or Stripe.
- Goal: Architect a system using Node.js or Python that emphasizes security (JWT auth, input validation, rate limiting), scalability, and error handling with structured retries, dead-letter queues, and idempotent writes.
Full-stack: the "full-stack forge" battle for supremacy
Full-stack challenges ask teams to build a complete system, often with defined targets for scope and test coverage.
- Problem: Remote villages lack access to specialized medical advice, and existing telemedicine apps are too heavy for low-bandwidth environments.
- Task: Develop a "Lightweight Telemedicine Platform" that includes a responsive React/Next.js frontend and a Node.js/FastAPI backend. The system must support asynchronous messaging, low-res image uploads for diagnosis, and a "doctor's portal" for managing patient files.
- Goal: Deliver a modular project with organizer-defined test coverage targets (for example, 70+ meaningful test cases across unit and integration layers), following a clear "separation of concerns" architecture.
| Stack layer | Example tools | Developer skill tested |
|---|---|---|
| Frontend | Examples include Next.js, TypeScript, Tailwind CSS | UI/UX, server components, type-safety |
| Backend | Examples include Bun, Python (FastAPI), Go | Concurrency, API design, performance tuning |
| Database | PostgreSQL (pgvector), Neo4j, MongoDB | Data modeling, vector search, semantic relationships |
| DevOps | Docker, GitHub Actions, Terraform | Infrastructure as code, CI/CD automation |
How to pick the right problem statement
Picking the right challenge affects visibility and outcomes for both teams and organizers. For organizers, it can mean the difference between a great event and a pile of unfinished projects.
For developers: the impact vs. feasibility matrix
Teams should choose an idea they can complete within the hackathon's time limit (typically 48 hours) and that has real-world value.
- Validate the scope: Map dependencies, bottlenecks, and priorities before writing code — list every external API, dataset, and integration, and rank them by risk.
- Deliver an MVP: Ship a minimum viable product that solves the main problem end-to-end, rather than building a partial version of a larger system.
- Cut ruthlessly: Drop any feature that does not directly serve the demo path within the first four hours of scoping.
For organizers: the "innovation moat" check
Organizers should design a problem statement that creates an "innovation moat" — one that pushes teams beyond common solutions.
- Feasibility check: Can the problem be reasonably solved or prototyped in the given timeframe?
- Business value: Does the solution meaningfully change access, cost, or throughput for a defined user group?
- AI-first thinking: Is AI core to the solution, or is it a wrapper around an existing feature?
Running internal hackathons to identify high-potential engineers is a common use case for HackerEarth's skills intelligence tooling — the same rubric that scores hackathon submissions can be reused for structured technical assessments during hiring.
FAQ
How do you write a hackathon problem statement?
Write a hackathon problem statement by defining a specific real-world pain point, quantifying its impact with baseline data, and specifying measurable success criteria without prescribing the solution. Use the SMART framework as a starting point, contrast current and desired states, and add technical constraints (data sources, required protocols, evaluation metrics) that force teams beyond trivial answers.
What makes a good hackathon challenge?
A good hackathon challenge is specific, measurable, and constrained enough to produce comparable submissions, while remaining open-ended in how teams solve it. It uses real or realistic data, sets quantitative evaluation criteria, and includes at least one non-trivial constraint — such as a latency target, security requirement, or protocol dependency — that separates strong engineering from surface-level demos.
How long should a hackathon problem statement be?
A hackathon problem statement should typically be 150–400 words: enough to cover the problem context, the task, required constraints, the evaluation rubric, and any provided datasets or APIs. Anything shorter tends to be ambiguous; anything longer usually signals that the organizer is prescribing the solution.
What are common mistakes when crafting hackathon problem statements?
Common mistakes include over-specifying the solution, using vague success criteria like "innovative" or "impactful," omitting datasets or reference APIs, and setting scope that cannot be completed in the allotted time. Another frequent issue is copying enterprise problems verbatim without adapting them to a 24–72 hour format.
How is a hackathon problem statement different from a project brief?
A hackathon problem statement is time-boxed, competition-oriented, and evaluated against a shared rubric across many teams. A project brief is scoped for one team over weeks or months and typically includes staffing, budget, and milestones. Hackathon statements optimize for comparability and creative pressure; project briefs optimize for delivery certainty.
Should hackathon problem statements specify a tech stack?
Hackathon problem statements should specify the tech stack only when the challenge is explicitly testing a technology (e.g., MCP, a specific database, or an accessibility standard). Otherwise, keep the stack open and evaluate on outcomes, so teams can play to their strengths.
Trade-offs and limitations
No framework covers every case. SMART can produce over-constrained prompts that suppress creative approaches. MCP is a young standard with uneven tooling. Coverage targets like "70+ test cases" are useful anchors but should be calibrated to project scope rather than treated as universal. Organizers should treat this guide as a starting point and adapt criteria to their audience and time budget.
What's next for hackathon design
One arguable prediction: within the next 18–24 months, hackathon evaluation rubrics will weight agent observability and reasoning traces as heavily as code quality is weighted today. As AI agents take over more of the implementation, judges will need to assess how transparently a system explains its own decisions — not just whether the output is correct. Organizers who build reasoning-trace requirements into their problem statements now will be ahead of the shift.
The related recommendation for talent teams: treat hackathon submissions as structured skill signal, not just event output. The same rubrics that judge a hackathon can inform downstream technical hiring assessments and internal mobility decisions.
Next steps
If you're planning a hackathon — internal, campus, or public — and want to reuse the evaluation signal for hiring or talent development, explore how HackerEarth supports both sides of the workflow:
- Run structured technical assessments mapped to the same skills your hackathon tests.
- Launch a branded hackathon or innovation challenge with automated evaluation and leaderboards.
- Talk to the HackerEarth team about designing problem statements calibrated to your hiring or R&D goals.
Sources
- Doran, G. T. (1981). "There's a S.M.A.R.T. way to write management's goals and objectives." Management Review.
- Anthropic. Model Context Protocol documentation. https://modelcontextprotocol.io/
- Stack Overflow. 2024 Developer Survey — AI section. https://survey.stackoverflow.co/2024/ai
- McKinsey Digital. "Tech debt: Reclaiming tech equity." https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity
Note to production: featured image and at least one in-body visual (e.g., a diagram of the impact vs. feasibility matrix or the three-level progression) required before publish. Meta title suggestion: "Crafting hackathon problem statements (2025 guide)" — 54 characters.




