When people ask me why I go on trips to support hackathons, I never have enough time to tell them the whole story. Well, this is the whole story. I hope this article will inspire you to add hackathons as a tool in your own student/professional development and also motivate you to mentor/sponsor such events if that is an option available to you/your company. If nothing else, I hope to bring you into the world of coding competitions and explain why I am a big fan of them.
Section 1: Hackathons
Let’s turn the clock back to the winter of 2012. I was at UW and had just completed my first ever real coding competition. It was a disaster. I think we finished second to last in a field of more than thirty teams. We knew we had to create some financial currency utility but we didn’t know where to start. We struggled to get our libraries imported, tried to solve too many problems, and ran out of time. The worst part was looking around and NOT seeing other teams struggling like we were. Were we just that bad? Before analyzing the performance, let’s just agree on a Wikipedia definition for what a hackathon is:
A hackathon (also known as a hack day, hackfest or codefest) is a design sprint-like event in which computer programmers and others involved in software development collaborate intensively on software projects… The word “hackathon” is a portmanteau of the words “hack” and “marathon”, where “hack” is used in the sense of exploratory programming. – Wikipedia (at time of writing)
So looking back at our performance in the intensive environment, we really struggled with the lack of direction and guidance. At this point, none of us had a grasp of GitHub plus version control to collaborate on code from scratch. None of us knew how to use API keys and sandboxes to integrate third party libraries. There were only a few mentors in the room who could help with this but we were too shy to talk with them. These things are not explicitly taught in school but are pretty basic and fundamental to anyone who’s coded in industry. We got discouraged. Instead of using this coding competition as an exciting first foray for “hacking together” original, exploratory code we were shellshocked and felt bad for entering at all, overshadowed by others.
A year later I learned in 2013 how the “others” operate. During a summer stint in California, I went to San Francisco to try my luck at #scubahack. This was a different kind of game than the first one at UW. This was a company-sponsored event from iDive Housing (underwater iPad cases) and there were prizes at stake for teams who could build the best apps to go with the housing. This was not college so there were no mentors and everyone around looked like they had at least five years of experience. Intimidating? Definitely. So I tried to get a head start with team selection. On one hand, choosing the smartest looking group of developers (which I did based on a networking happy hour) to join pretty much ensures that you will be the dummy of the group. But that didn’t matter much to me. I just wanted to win something.
The funny thing though was that I was able to contribute and avoid being deadweight despite my inexperience. My fears and pain points from my first hackathon like GitHub and task management had been mostly ironed out. I did still ask stupid questions to my teammates but I was glad I asked questions so I stayed on the same page with the team. We had a lot of cooks (developers) in the kitchen so while I pushed a few commits into our codebase, there ended up being more value in whiteboarding, arranging interviews with divers, and dressing up our demo. Because all my teammates had been part of hackathons before, they knew what to do. Because of my previous hackathon experience, I was getting a feel of what to do as well. Long story short, we built a useful and well-liked app with time to spare and won the prize. With experience, I was having more fun and becoming one of the “others” I had profiled at UW.
The only source of knowledge is experience. – Albert Einstein
Sure knowledge is good. Ultimately it was the veteran coding knowledge of a few developers on my team that built the foundation for our prize-winning app. However, I 100% believe that the combined experience of the team to deal with the event format and environment was the reason the team succeeded and won in a field of other brainy competitors.
So that was that. For a while, I was pretty content to take my winnings and call it a day. I had no idea how valuable that hackathon experience was to my career future.
Fast forward to 2015, when university recruiting at Concur asked if I could help with DubHacks (UW Seattle) as a sponsor. I went and had a lot of fun collecting resumes and passing out stickers, but I felt a little bit detached from the hacking side of things. When the next opportunity arose, MHacks Refactor (UM Ann Arbor), I asked to be a mentor on top of sponsor duties. I was a little bit shaky with helping students set up their iOS app projects in a crunch-time kind of setting but I could always lean on my past experience to help students with tactics and demos.
My biggest takeaways from those 2015 hackathons were:
- “Man colleges really have upped their hackathon game” (thousands of student participants, with well-organized activities/food and plenty of sponsors/mentors)
- “It feels really nice to help students build cool things”
- “It’s really cool to see what these students end up building at the end”
- “I want to keep doing these and being involved”
With this in mind, 2016 comes around and here’s my paper trail:
- Concur Intern Hackathon – MENTOR (Bellevue, WA)
- MHacks8 – SPONSOR / MENTOR / JUDGE (Detroit, MI)
- CalHacks – SPONSOR / MENTOR / PRESENTER / JUDGE (Berkeley, CA)
- HackMIT – SPONSOR / MENTOR / PRESENTER / JUDGE (Cambridge, MA)
- Concur SPIKE Global Hackathon – HACKER/Craziest Hack Winner (SF)
So yeah. I asked for more and I got more. But I don’t regret any of it. My “duties” at the events expanded to judge and API presenter for Concur so the job never got old. I felt like I was getting new perspectives on all aspects of development and that I was getting better at this. I felt like I was getting better at evaluating talent, getting better at mentoring, and getting better at understanding what companies want to see from students.
Above is an example mentorship tool at CalHacks. I thought the HELPq system was interesting because of the mentor ranking/scoring system. It was like the mentors could get in on the competition too. I won’t boast about my score because I only took seven tickets at the time of the screenshot but I can assure you that if this scoring system had existed for my earlier mentor gigs I would have never been in the top five. Knowing when to tell someone when to keep pushing and when to tell them to abandon a lost cause was very hard for me early on, but it got better with time. Going back to that Einstein quote, “The only source of knowledge is experience”, experience is what you have to lean on when the questions get harder and more specific. Harder and more specific as in, “I’ve tried to move this Stack Overflow code from Objective-C into my Swift 3 project for two hours and still can’t get it to work.”
5. Concur SPIKE Global Hackathon – HACKER/Craziest Hack Winner (SF)
To conclude this section, I want to touch on this last hackathon event of the year, SPIKE Global Hackathon. I had kind of convinced myself that I could mentor other people on what to do, but I always kind of wanted to take another crack at being a hacker. I mean, this was basically my first big hacker opportunity since #scubahack in 2013. I was hungry to prove a point to myself that I could be more useful now than before. Hackathons being a team sport, thankfully the team operated at a very high level and I was able to put in my fair share of the work. We built a Tinder-like extension for the TripIt app called “Matcherator” that was less crazy than it sounds. Still, it was crazy and we won the prize for craziest hack.
This win felt even more satisfying than the #scubahack win. I felt like I put more of my heart into the win as well as the additional years of lessons learned from the past. It felt nice to see the added experience lead to results.
The crazy thing is that if a few things had gone differently, I might not have been on any track to get hackathon exposure. But because I got that exposure, I feel incredibly grateful for the additional boost it gave to my professional development.
Section 2: Hammers
This is the mandatory part of the story where I remind you to have fun. Hackathons are most valuable when everyone has incentive to get involved. As a note of caution, hackathons can lose appeal, especially in corporate settings. When hackathons become long coding sessions meant to milk employees (or nonemployee hackers) for specific product development the incentive lies mostly with the organizers (even if a few free pizzas and t-shirts are provided). When this happens, fun falls out of the equation. This is why I can’t emphasize enough the idea that hackathons should, above other key characteristics, be outlets for people who want to have fun and build things.
As an example of this, in April 2017 the director of R&D at TripIt wanted to see what TripIt’s engineering teams could build with code and hardware when the requirement for “business value” got axed. The only requirement was that projects had to relate to flying.
The result was ridiculous. We had blimps flying around the office, drones converted into hovercraft, snack delivery helicopters, and air compressor rockets too. Then there was our trebuchet. Built from an Amazon.com wood trebuchet kit with glue and hammers, coded to launch with a variety of IoT (internet of things) instructions, and presented with a completely made up story about its value to the world, it took home the sarcastic prize of “Most likely to make the world a better place”.
The event uncovered hidden engineering and creative talent of team members, and for me as an employee was just a fun event to take part in. It is events like this that make me really appreciate a corporate culture based on the principle that having fun can go together with building cool things. Some people could argue that the entire engineering team lost a day of progress and business value. Maybe I’m biased because I got to walk around the office with hammers and hardware for a day of work, but I still choose to believe that when people have fun and build cool things, the business value will follow closely.
Try It Out
I want to end by going back to one of the objectives of this article.
I hope this article will inspire you to add hackathons as a tool in your own student/professional development
Firstly, I would encourage all CS students to try at least one hackathon before graduating. Hackathons provide an extra dimension outside of textbook coding ability. It’s one thing to have a week to design and test code for a homework assignment. It’s another thing to have to deal with a 24-hour deadline that forces you to cut corners and focus on core demo-able functions. As a student, I only really participated in two coding competitions but they both still immensely shaped me as a developer. The competition aspect is also a way to measure yourself against your peers.
Speaking from the recruiter side of things, it is an opportunity as a student to network with companies for internships. Companies love to see the initiative and it’s an opportunity to show your ability beyond a resume and cover letter if there are engineers onsite observing candidates. Also, the environment is festive and generally there’s a lot of free stuff. You might even win prizes.
Secondly, I would encourage tech graduates in industry that it’s not too late to try hackathons, internally or externally. Just as for students, the competition aspect is a way to measure yourself against your peers to see where there are areas for you to improve on. The ability to pick up tools quickly, acclimate with new teammates and prioritize and size issues is applicable in just about any form of engineering. Especially for external hackathons, it’s a good way to see what new tools are out there and to network with other developers. Just as I said for students, you might even win prizes. When was the last time you “won something” at work? This could be a source of motivation.
If you are in a position in a company to influence decisions such as creating internal/external company-sanctioned hackathons or sponsoring existing external hackathons, I would ask you to consider breathing life into those ideas. If none of these are options, then I would suggest becoming a mentor at such events, because this is a great way to hone your own skills while helping others.
So try it out if you can. You never know what it could lead to.
Original article here…
https://www.linkedin.com/pulse/value-hackathons-hammers-peter-hu
