Google Hash Code — When failure teaches you much more than winning does
Last year, a couple of my friends and I participated in the Google Hash Code 2020 Competition. We met physically, had a large whiteboard to share ideas in person, distributed tasks effectively among us and played to our strengths. Despite it being the first time ever competing together as a team and the first time ever participating in this competition we actually ended up placing 1st in Lebanon! The dream team, right!?
This year, the Google Hash Code 2021 Competition was approaching, and we naturally decided to participate in it once again with the same exact team. If we’ve done it once, we can do it twice! However, things were a bit different this year. Last year we practiced together in a mock-up competition to get used to the competition, this year we didn’t, as we assume having already last year’s experience as our practice. Last year we met physically and shared ideas in person, this year it was all virtual via a Zoom call. Last year we had constant eye contact and knew exactly what each one of us was doing, this year all we had was voice communication over Zoom. Long story short, we didn’t even make it to the top 10 in Lebanon. So, what went wrong and what did I learn from it?
To be quite honest with you, this losing experience has taught me much more than last year’s winning experience could’ve ever taught me. This isn’t to say that last year’s winning wasn’t fruitful, in fact it was quite the contrary. However, when things go great, and the end result is a win, we often tend to overlook the mistakes committed, and overestimate our performance. For instance, last year we were super efficient in terms of time and resource management, but given our win, we kind of took it for granted and never questioned if it happened because we enforced it, or just by chance or instinctively?
In contrast, this year has been a disastrous attempt, and all the weak points suddenly shined brighter than ever in front of me! I even questioned the correct stuff we did and made sure I understood why they happened and how to reproduce them. So, without further ado, here are the most valuable lessons I’ve learned from this failure:
As the Competition is only limited to 4 hours, teamwork is vital.
This is one area where we nailed it. Teamwork, as you might have guessed, is absolutely vital in such a competition. In fact, I’d go to say that, in my opinion, one of the most important indicators in either winning or losing this competition is the team members’ level of agreeableness and degree of accepting others’ point of views.
As mentioned above, our team was luckily formed of people with such constructive attitudes. That being said, this kind of paradoxically back-fired and I’ll explain why in the next points.
The phenomenal importance of leadership in a team.
Leadership. Leadership is what we were missing in this land of agreeableness overflow. I can’t stress enough the importance of having a team leader. A clear, decisive, authoritarian and respectful voice is what it takes to actually benefit from this agreeableness and openness in the team. Otherwise, you’ll just end up with a fragmented team, with each member throwing his/her idea, having everyone consider everyone’s approach and no one actually making the call on which approach to double down and focus on.
This feat was easier to achieve, rather instinctively, in last year’s competition as we were working together physically. We all knew what everyone was doing and it was easy to notice time pass by with us just staring at each other and not taking action. So, we would directly call for a mini-meeting on our beloved whiteboard, share ideas and augment them quickly, take decisions and take consequent actions. Thus, it was rather easy to share this leadership responsibility.
Accomplishing this feat this year, without previous preparation, was very challenging. Our team was physically-fragmented and audio communication is all we had. We would discuss idea, after idea, after idea, and never notice time passing by. Being physically distant, and each having a different approach in mind, it was exceptionally hard for someone to take the lead and responsibility of forcing shorter discussions and generating faster actions.
Looking back at it, taking the responsibility of leading the team to a suboptimal solution, beats the hell out of not taking any action at all.
Do not waste resources on solutions that are taking too much time with poor prospects.
There are sometimes where an idea just hits you, an idea that would definitely boost your score if it works, and it just “feels” rapid and easy to implement. But in some of these cases, especially in competitions such as Google Hash Code, such ideas tend to just reveal their complexity over time. So, you get stuck in this rabbit hole, where you’ve already invested so much time into this idea, you feel that it just needs a bit more, and eventually it just devours a ton of precious time from you and your team. Don’t let that happen! Set a hard limit to the implementation of an idea, if in 10–15 minutes the thing is still not figured out just scrape it and move on.
I know it can be hard to let go of ideas, especially when you’ve only had a handful of minutes to try and implement them, but keep in mind that the whole competition is 4 hours, and there’s absolutely no time to waste!
When applicable, solve conflicting ideas by relying on actual data.
Accepting others’ point of views, especially when they might contradict ours, is an essential skill to have both in this competition and in life. In most cases, a team leader should step in and decide which approach trumps the other and move forward with it. In some cases however, especially in the later stages in the competition, ideas will further and further diverge and it’ll be hard to make a call on the better one. If you’ve had a great start, you might have a small leeway to try both ideas, so why not do it! Let each member having a different idea implement his own idea (of course with a time limit) and later on let actual resulting data decide on which approach was indeed better in this scenario.
In fact, we applied this technique in last year’s competition and we ended up merging the 2 tested ideas together to come up with our best solution that won us the 1st place in Lebanon!
We’re used to always glorifying wins, showcase the “best” version of ourselves on LinkedIn, and always disregard the failures and “move forward” from them. This logic is so engraved in our common knowledge, and I really hate it. Whenever you hear about someone winning a competition, what does that tell you about the person? That he learned a lot through this competition, in terms of programming, teamwork and so on, in fact, this person learned the most because he/she even won it! Well, wrong… What sort of logic links learning to winning? Can’t you still learn a ton from losing and failing? Don’t get me wrong, winning still has its merit and it is eventually what we seek when competing, but I just think that it is overshadowing losing so much that we don’t even mention our losses anymore. All I’m saying is that we should switch our mindset from a win/loss end-goal to a learning end-goal.
If you enjoyed reading this blog, don’t forget to support with a clap!👏
You can also connect with me on LinkedIn.
