More Than Just Code


Judging YHack

More Than Just Code: Judging YHack

Recently, FINRA sponsored YHack, Yale’s student led hackathon. We had three challenges with $1000 prizes for the winners of each challenge. Vitali Potchekin, a product manager at FINRA with experience participating in multiple hackathons, went to judge the submissions.

We sat down with Vitali to learn more about what it’s like to shift from hackathon participant to judge.


What was it like to be a judge? How is it different?

Judging is always fun and much less pressure. You’re not constrained with a time frame. You get to absorb more of what other people are doing and their ideas. That’s the most fun part.

As a participant, you’re focused on your single task. You don’t have a minute to look at others presentations. You’re zoned into your own work. It’s hard work and leaves you stressed and in a hurry.

When judging you get to meet more people, see how their work goes.

What made the winning hacks stand out? Why?

The winner of our taxi cab data set challenge is a good example. There were a couple of contestants that were technically stronger than the winner. The guys who won had a better use case for the business ideas. They didn’t focus on hard coding. They focused on how they could use the data to solve problems.

Other teams were focused on difficult analysis, but didn’t have an end goal. The team that won the challenge came up with a simple but applicable use case for real life. I was able to relate to it.

They used Pebble watch and they integrated data and software. Their hack allowed you to tell your watch where you want to go from current location. Then, it tells the user the cost based on distance of Uber versus cab. I could totally relate to it and that’s what got me.

The more applicable the solution, the better it is. It doesn’t matter how difficult it is. It can be elegant and simple. Solving something is the main criteria.

What do you think is overdone for hacks at hackathons? What do you wish you could see more of?

Solutions do tend to be similar. It’s not a really a problem for participants because we’re in an environment with similar influences. 80% will be nothing new, uninteresting, or not work. 20% will be interesting. At hackathons, there will always be a couple crazy things you wouldn’t believe. It’s just how things are, and it’s ok.

Overall, the hacks at YHack were great quality. Some teams just didn’t come up with something and that’s perfectly normal.

You’ve participated in many hackathons; do you think it’s helped you with your own career and work?

It is helpful to my career. One of the way it helps, in large organizations, teams tend to miss deadlines. Hackathons force a deadline with solutions. It forces you to figure things out and work with deadlines.

In many development companies, it can be hard to see benefits of features or specific functionalities. Hackathons can help teams identify things that will bring value to them and their product’s users. Hackathons develop the habit of delivering MVP (minimum viable product) in teams within the shortest time period while trying to minimize risks. Hackathons help you see how quickly you can build something to resolve issues. Some teams spend too much time building stuff but won’t actually give the desired result. This happens even to great teams with perfect technical skills. They just have a wrong focus.

In the end, hackathons help you identify wins and move quickly. You will learn to focus and select the best ideas.