Over the past months, I have taken part in several full-scale hackathons: from a solo FinTech challenge and a data-analytics format focused on building developer performance dashboards – to a 1,000-participant TravelTech competition and a hackathon on creating an AI agent for a socially important domain. At each hackathon, I took on several roles at once: from product manager and systems analyst to architect, researcher, QA, prompt engineer, and the person responsible for the demo, pitch, and business justification. Sometimes it required engineering thinking, and sometimes it was just strict time management. In this article, I want to share some advice on how NOT to participate in hackathons. After several intense competitions, I started to clearly notice repeating mistakes – both mine and others' – that reduced teams' chances and wasted valuable time. And since I will soon be on the other side as a hackathon judge, it feels even more important to talk about the actions, decisions, and approaches that most often lead teams to failure or pointless effort. how NOT to participate in hackathons Preparation for a Hackathon 1. Do not jump into a hackathon unprepared Starting a hackathon tired, without blocked time, or in the wrong conditions is a guaranteed path to chaos. Even a bit of preparation increases your chances of finishing the project and keeping the team calm. Set aside time for the event, do not sacrifice sleep completely, and plan your schedule with real life in mind. 2. Do not skip technical preparation: access, environment, repository 2. Losing hours on setting up your environment, getting access to the GitHub repo, or even entering the hackathon platform can cost you a big part of your productivity. Checking your equipment and setup in advance saves a huge amount of time during the hackathon. 3. Do not ignore the format of the final pitch, especially if it’s offline 3. Do not ignore the format of the final pitch, especially if it’s offline Do not postpone the question of the offline part. Most hackathons run online, but the final pitch might be held offline in the organiser’s office – or even in another city with a different time zone. If the final is offline, discuss in advance: Who can go? Who can speak confidently? Who won’t fall apart under stress? Otherwise, you might realise at the last moment that no one can attend, or the person who goes is too nervous to present well – and all your online work may be wasted. Who can go? Who can speak confidently? Who won’t fall apart under stress? Team Formation 4. Do not build a team out of people who "might find some time" 4. Every participant must be ready to commit time to the hackathon. Otherwise, the workload falls on a single lead. Unreliable teammates slow the process down and create unnecessary pressure for the rest of the group. 5. Do not start a hackathon with strangers in complete silence 5. Many people who form a team on the spot immediately dive into tasks without taking a moment to understand one another. This creates awkwardness, uncertainty, and hesitation to share ideas – and the problem usually appears within the first hour or two. Take some time for a short introduction. Spend at least 30-40 minutes talking to each other before the event begins. It helps reduce tension, understand personalities, energy levels, and expectations. A team that has "warmed up" works noticeably faster and feels more comfortable from the very start. 6. Do not work without defined roles and a clear task split 6. A team without roles quickly turns into chaos. It is especially important to appoint a captain – not a boss, but a coordinator: the main contact for the organisers, the person who watches the deadlines, tasks, focus, pitch quality, and makes sure everyone stays aligned. Without a formal lead, teams almost always fall out of sync. 7. Do not build a team of people with the same roles 7. If everyone is an idea generator, no one writes the code; if everyone is a developer, no one works on the strategy or the pitch. A team needs a balanced set of skills. Do not expect the right roles to "appear on their own". 8. Do not overlook the personal goals of each team member 8. If people have different expectations – one wants to win, another just wants to try, and a third aims to improve their portfolio or LinkedIn profile – it creates a mismatch in values. Talk about your goals in advance to keep the motivation aligned. Planning and Strategy 9. Do not ignore the rules and judging criteria 9. If the team does not read the full list of rules and limitations, it risks spending time on the wrong solution or planning deadlines incorrectly. The judging criteria are your actual checklist for success, and ignoring them means cutting your own points on purpose. Check the start time of the hackathon, expert checkpoints, the stop-code time, and the time zone. Pay attention to the allowed and forbidden tech stack, requirements for using LLMs, and the rules for structuring your README.md, docker-compose.yml, Dockerfile, and .env README.md docker-compose.yml Dockerfile .env 10. Do not build "castles in the air" Teams often come up with huge concepts that are impossible to deliver in 24-48 hours. You need to define a minimum workable scope built around the core feature of your solution and stay focused on it. Extra features should only be added if you genuinely have time left. 11. Do not be afraid to admit that an idea is not working Teams often keep pushing a weak solution simply because it feels wasteful to drop what has already been made. But hackathons are exactly the place for quick turns. The earlier the team says “stop”, the sooner it can find a workable alternative. Development and Execution 12. Do not experiment with a tech stack you do not know 12. Jumping to a new technology just because "you feel like it" is a bad idea when time is limited. Your focus should be on speed and reliability, not trends. If you want to use a stack that is new to you, practise in a sandbox beforehand. Try it out, read the documentation in advance – but definitely not after the hackathon timer has already started. 13. Do not try to build a perfect product 13. A hackathon is not about perfection – it is about speed and proving the concept. Trying to make everything "production-level" drains time and energy, and distracts you from the actual value of the solution. If you do have the time and the desire, you can outline the future development plan in a .md file in the repository or highlight it in your pitch. At the very least, it shows the judges that you think ahead and understand how the solution can grow. .md 14. Do not postpone key tasks 14. The feeling that you have plenty of time is misleading – it disappears much faster than you expect. Constantly pushing tasks aside leads to rushing, mistakes, lack of testing, and a weak final pitch. 15. Do not leave testing for the final hours 15. If testing starts only at the end, even small bugs can break the demo. It is far more effective to test gradually, addressing risks as the development goes on. 16. Do not lose focus through constant distractions 16. A stream of messages, chats, and endless discussions in group threads seriously reduces productivity. Assign one person to monitor communication with the organisers and experts, and let everyone else work in peace. Communication and Psychological Aspects 17. Do not ignore the team’s emotional resilience 17. A hackathon is a stressful environment, and if the team cannot talk through problems, any tension quickly turns into conflict. Pay attention to personalities and set up calm, open communication from the very beginning. 18. Do not turn work-related comments into personal conflicts During a hackathon, everyone works under high speed and pressure, so feedback often sounds shorter, tougher, or less diplomatic than in a normal work setting. If every remark is taken as a personal attack, the team quickly loses focus and energy, slipping into arguments and resentment instead of progress. Being able to hear criticism is a major boost to the team’s pace. Politeness in tone and the ability to separate the content of a comment from the emotions behind it are the foundation of healthy communication. Calm, constructive behaviour – even under deadline pressure – helps the team move faster, stay confident, and avoid unnecessary conflicts. 19. Do not fall into the "rescuer syndrome" Sometimes one person ends up doing everything – the code, the design, the pitch – out of perfectionism or lack of trust in others. This leads to burnout and reduces the contribution of the whole team. Delegation is key to balancing the workload and achieving a better overall result. 20. Do not ignore the emotional "signals" within the team 20. Irritation, tiredness, silence, or avoiding tasks are all early signs of overload. If these signals go unnoticed, the team can quickly slip into passive aggression or complete disengagement. A leader should read the atmosphere and step in gently before things escalate. Final Thoughts A hackathon itself is not difficult – it is the chaos, uncertainty, and strict time limits that can either bring a team together or completely break it apart. Most mistakes participants make are not about code or technology, but about preparation, communication, role distribution, and the ability to stay focused on what truly matters. Understanding how not to approach a hackathon helps the team avoid unnecessary stress, save energy, and direct it towards building a working solution rather than putting out fires. If you steer clear of these common pitfalls, a hackathon stops feeling like an exhausting marathon and becomes a productive, inspiring experience. how not to approach a hackathon

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

How (Not) to Hackathon? The Hackathon Anti-Pattern Guide

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 ways to be a billionaire— by somebody who’s not a billionaire.

10 Money Lessons I Wish I Knew When I Was 25

11 Lessons I Learned as a Tech Founder

21 Keys to Building Better Business Software

31 Lessons Learned From 10,000 Hours of Programming

34 Stories To Learn About Advice

10 ways to be a billionaire— by somebody who’s not a billionaire.

10 Money Lessons I Wish I Knew When I Was 25

11 Lessons I Learned as a Tech Founder

21 Keys to Building Better Business Software

31 Lessons Learned From 10,000 Hours of Programming

34 Stories To Learn About Advice

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps