How I Won 11 Hackathons | Complete Guide

Summary

The speaker explains how he improved from placing 53rd out of 100 teams at his first hackathon to winning 11 of the next 14. He says the change did not come from suddenly becoming a better programmer or inventing more ambitious technology. Instead, he began treating hackathons as short product-development exercises: identify a real problem, understand the people affected, build a focused solution, and communicate its value clearly.

His central lesson is that the most technically complex project—or the one with the most code and features—doesn’t necessarily win. Strong product decisions, grounded in user needs and clear evidence, matter more.

Hackathon Approach

Step 0: Choose the Right Hackathon

Before starting, check whether the event is a good fit:

• Research its theme and requirements.
• Consider whether it matches your interests, goals, and technical skills.
• Look at the judges and the kind of work the event is likely to value.
• Participate when the event aligns with your direction and capabilities.

Step 1: Understand the Problem

Don’t begin by asking an AI chatbot to generate a project idea or ready-made solution. Use tools such as ChatGPT or Claude to help investigate the industry and its problems instead.

• Identify the sector the hackathon topic relates to.
• Research the challenges people in that sector currently face.
• Find out how often the problem occurs and how serious it is.
• Look for relevant metrics, including financial, time, or other losses.
• Understand what solutions already exist and where they fall short.
• Use this research to form a specific, evidence-based problem statement.

Step 2: Design for a Clearly Defined User

Avoid defining the customer as “everyone.” Identify exactly who will use the product and consider their circumstances and habits.

• Narrow broad groups into specific users—for example, identify what kind of students or professionals the product serves.
• Map how the user would encounter and use the solution.
• Remove barriers that might prevent them from using it.
• Adapt the interface and delivery method to the user’s abilities and context.

The speaker’s example is a farmer who may not be comfortable using a mobile app. Rather than requiring an app, a phone number or voice-based service could let the farmer access the same capabilities more easily. The right user experience can distinguish a useful product from a merely functional one.

Step 3: Build a Focused, Distinctive Solution

Concentrate on the product’s unique selling proposition (USP) and the main problem it solves.

• Prioritize a small number of effective features over a large feature list.
• Don’t add AI, blockchain, or other complex technologies just to make the project seem advanced.
• Ask of every feature:
  • Who will use it?
  • Does it solve the main problem?
  • Is it essential, or merely a nice extra?
• Reduce friction and make the solution fit into the user’s existing workflow—for example, by making it easy to import and export information.
• Add optional features only after the core problem is solved and time permits.

The aim is to solve the problem clearly and with as little difficulty as possible.

Step 4: Make the Product Easy to Understand and Demonstrate

Work on the presentation while building the product. At least one team member should be thinking about how the product will be shown to judges.

The speaker recommends a presentation and demo that follow this sequence:

1. Define the problem and the user. State clearly what is being solved and who is affected. Consider opening with a relevant audience question to capture attention.
2. Show evidence. Use credible reports, articles, news stories, surveys, or other sources to demonstrate that the problem is real.
3. Explain the cost of the problem. Show the time, money, or other resources it consumes.
4. Describe the solution simply. Include a screenshot or other clear visual, and explain what the product does in language a nontechnical person can understand. Avoid unnecessary jargon.
5. Demonstrate the working prototype. Begin as the intended user would. Explain key design choices, then show the user journey and prioritize the most important features.
6. Compare before and after. Quantify the improvement where possible—for example, reduced time or cost—so judges can see the practical impact.
7. Optionally explain technical details. If time allows, cover the architecture, technologies, development process, or division of work.
8. Introduce the team. Close by showing the team’s experience and why it is capable of carrying out the solution.

A working prototype is essential: a presentation alone is not enough. The demo should make the main benefit visible rather than burying it under secondary features.

Advice for the Q&A

• Listen carefully and answer calmly; don’t argue with judges.
• Know the product’s USP, features, and competitors before presenting.
• Be honest about anything that has not been implemented.
• Explain what was achievable within the hackathon’s limited time and what you would build next.
• Don’t exaggerate or claim unfinished work is complete; the speaker warns that judges may lose trust if they detect dishonesty.

Closing Lesson

The speaker describes a hackathon as a simulation of product creation. Beginners do not need to know everything or be the best programmers in the room. They should arrive with a plan, an open mind, and a problem-solving mindset. His concluding idea is that engineers are there not merely to write code, but to solve problems.

Speakers and Sources Featured

• Main speaker: Introduces himself as Syed Zohaib, a student at Scaler School of Technology. Later subtitles refer to him as “Zahur,” so the name may have been transcribed inconsistently.
• Brief off-camera questioner or interviewer: The subtitles include “So, Zahur, what are you doing now?” before the main speaker discusses his work and roles.
• Research sources recommended for presentations: Survey reports, articles, news stories, and magazine coverage, including examples such as Forbes. No specific report or article is identified in the subtitles.