Skip to main content

What not to do in a Hackathon

Ideas win Hackathons
While the above statement might be true, there is just a little modification which is needed.
Idea wins Hackathons
I learnt this the hard way. And if you didn't get the full difference, that's what this blog is for.
The previous month gave me two opportunities to build something amazingly innovative. While I did exactly that on both the occasions, I failed to make it to the win.


We did not have one great idea. We had 2 great ideas.
Somehow, we tweaked both of them to present them as 1 great idea!
If this is sounding like one good no-sense poem, give it a rest.

Often in Hackathons, the team formed has multiple interests/talents. A particular member might be an expert in some framework/language and another might have a flair for another. It's important to coordinate all activities for the project.
However, finding one project that actually has so many activities which can be done by all members is a rather tough task.
Naively, we thought of 2 different projects, both of which were amazing, and combined them as one project, inter-knitting their features together.

When the judgement round arrived, the audience (judges) didn't seem to agree with the joining of the 2 projects in the first place. And here's the thing, no matter if they love even one of your ideas, the entire debate would just pivot towards the question of joining the 2 projects together.
No one is looking at your idea(s), but it's your decision skills into question. The judge probably thinks that there is a good reason for it which will make this project one GREAT project. But nope, you know the reason is just to even stuff out, or get as many bounty prizes as you can.

Thus, here's my shortest advice:
If you're building something at a Hackathon, just build on one Idea. No matter how uncomfortable everyone in your team might be, make sure that all of you are contributing only towards a single idea.
Don't worry about the silliness of your idea. One of the many things I learnt from these Hackathons is, if there's no real conflict of thought with the judge, even the silliest of ideas make it to the finals.
There are a few things that matter in the first round:

  • A clear concept of what the idea is.
  • A rather good reason to pursue this idea. 
  • Just ONE idea.
  • Confidence.
Here are a few things that matter in the finals:
  • Confidence.
  • The features that you have added, which shows how much work you've done in such a short span
  • The UI, it helps to blow off the audience.
  • The presentation. 


  1. Precisely what hackathon participants have to keep in mind. I have participated in a few hackathons, but could never make it to the finals. Luckily, I got much exposure to find my interests and a chance to work on some good projects.

    Moreover, as K Vaitheeswaran (father of E-commerce in India) says :

    "Success teaches you a chapter, failures teach you the whole syllabus"


Post a Comment

Popular posts from this blog

Namaste JavaScript Quick Notes

Note:  Akshay Saini's Namaste JavaScript is probably the best course for JavaScript developers out there. These are my personal notes that I made while watching the course; they serve more of as an online quick reference for my understanding and revision, and I hope it benefits anyone reading it too! Everything in JS happens inside an Execution Context. Before a JS code is run, memory is allocated and variables are set as undefined   , and functions are set as their exact code in the scope within the Execution Context. The global execution context hosts all the global variables and function definitions. An Execution Context has 2 components: Memory, that stores variables and functions; and Code, that reads and executes the code. Call Stack maintains the order of execution contexts. Since JS is single threaded and asynchronous, at one point of time, only one function is executed which is at the top of the call stack. For each function, an execution context is created before executi

An introduction to APIs

API is an acronym for Application Programming Interface. Let's start with first defining some basic terms: Browser: These are browsers. To visit any website on the internet, you need a browser. Server: Hmm, this is tough. In simple words, server is a computer. Yes, just like the laptop, or PC at your home. The only difference is that it does not have a screen. Of course, there are other differences in technical specifications, but at its core, the server is just, simply, a computer. That's it. So why is it called a server? Because it serves . When you go to a website like , your computer connects to the internet and gets you your search result. But your computer's internet connection has to get that result from somewhere, right? If the google search result is giving you some answers, the answers have to come from somewhere. What is that place? The answer to that some place is: a server. When you click on the search button on google, or hit enter after typing, &q

Review: Nestjs - Finally a scalable way to build APIs

I have been thinking about this for a long time. There HAS to be a defined way to build APIs in a scalable way.  If you have used Node, Express, etc in your side projects, you might have felt that after a point in development, debugging truly becomes a pain. Sure, enterprise-level API codes are great. But a lot of times, these configurations are too much, and probably not even needed in other projects. To be honest, I haven't seen a lot of Open-Source API codes either to make a judgement on how experienced developers build their APIs. Anyway, I came across an amazing framework recently, and I think if you are coding a complex API, this should be your way to go. Nest.js Nest.js is a framework for building efficient, reliable and scalable server-side applications.  You essentially break your APIs into controllers, services, and modules, which allow you to modularize the smallest of functionalities in your endpoints or the API as a whole. Why is modularizing important? As I have talk