Our writer Karen Lin spent the first weekend of October at UC Berkeley’s own hackathon. In this piece, she explores what participants at these events learn from each other, and how navigating team dynamics translate into engineering skills.
The weekend of Cal Hacks 2.0, approximately 30 organizers, 47 sponsors, 120+ volunteers, and 2000+ participants from universities all over the nation congregated in Berkeley’s Memorial Stadium to participate in a 36-hour marathon programming competition, or “hackathon.” To build a viable product within 36 hours, hackers relied not only on code and cutting-edge hardware but also on each other.
The stakes were high for the teams. Sponsors such as Microsoft, Uber, and Capital One were on the search for talented programmers with hiring potential. The companies provided APIs, or Application Program Interfaces, as tools students could use to bring their product vision to life. Uber even offered jobs to students who managed to impress them. The message is clear: the world needs talented team players. Hackathons are the places to find them.
Teams at Cal Hacks formed in different ways, but most of them came together through high school or college friendships. Sometimes high school friends from different colleges united at the hackathon. Others found impromptu partners and teams through social media or by meeting strangers once they reached the venue.
Diversity in Teams
Diversity in teams is necessary. Grace Wu, a second-year computer science student at Stanford, pointed out that some companies do not test their products with all groups of users. She mentioned examples of a soap dispenser that struggled to detect black skin and motor companies that test the safety of their cars exclusively with male crash dummies. More diversity on a team decreases the likelihood that a group of users will be left out of the testing process.
A Ideal Team Size
The ideal team size varied depending on the project, but most agreed that 2-5 is a good number. Working alone is possible, but requires a lot of preparation and focus. A group of 6 people or more might make communication difficult. Groups sizes also tended to fluctuate throughout the 36 hours as people left the hackathon, abandoned each other to join other groups, or caught up on sleep.
Distributed Their Workload
Teams also distributed their workload in different ways depending on the complexity of each project. Typically, teams divided up their workload between frontend and backend, between user interface and algorithms design, or among list of tasks. Team members generally worked with their own specialties and were able to teach each other different skills.
Sebastian Merz and his startup co-founders used hackathons as their training ground before entering the “real world.” They organized the first ever Cal Hacks last year in 2014, then went on to start a company after graduation. “Cal Hacks was really important because that’s really how we got to know each other, and how we sort of learned how we work under pressure,” said Merz. “When you’ve seen someone at or organizing a hackathon, you sort of know everything about them, and it made it a lot easier for us to get together and say ‘we want this company.’”
Collegiate hackathons encourage computer science students to explore their ideas outside of the classroom environment. “You learn a lot in school,” said Peter Minor, a co-founder of the tech incubator CITRIS Foundry. “You learn syntax, programming languages, but being able to apply it in a real-life scenario and do it in a short amount of time, being able to think in terms of prototyping and testing, is really valuable.”
Hackathons can force students to confront their lack of practical experience. Faced with freedom from professors and curricula, some students might not know how to begin their project. Unlike homework that asks students to use specific concepts introduced in class, hackathons allow them to build products from scratch. “Hackathons really teach you how to navigate, ‘okay, I’m going to choose my technology, and I have this deadline, I need to get x, x, x has done at that point and this is possibly some way I could go about it,’” said Merz.
Outside of school, people rarely work alone on large projects. Companies are built by designers, programmers, and business people, each with their own unique skill. “In the end, you’re not designing the product for yourself, you’re designing it as a small part of the company,” said Stanley Kwong, a second-year CS student. “So in a way, even if you’re not talking to anybody per se, you’re in a way still communicating with people, even if it’s through Slack [a messaging platform] or something.”
More than ever, despite the competitive nature of collegiate hackathons, these marathon coding events establish a sense of community. “Look at this, there’s 1500 people in a giant room together, coding,” said Minor. “You’re observing partners, you’re concocting thoughts, you’re having conversations about them, similar to it’s an ideal illustration of a local area of individuals cooperating.”
