[Hackcon VII] Attracting non-STEM Majors to Hackathons


This is the original transcript of the Lightning Talk I gave at MLH Hackcon VII. While I was actually presenting, I went very off script. I'm an improviser at heart. However, the original draft is much more informative and detailed so I decided to upload that here.



When the new co-presidents of VandyHacks took office, they made it a mission of theirs to increase the intellectual diversity of our programs by attracting non-STEM majors. For those of you that serve as lowly committee members, you know that means it became my job to actually do it. My name is Conner Pinson. I am a Computer Science and Engineering Management major from Vanderbilt University. I have served our hackathon organization, VandyHacks, as a committee member for the past two years. In this position, I have been tasked with the unique opportunity to craft workshops and talks targeted at not only computer science majors and aspiring software developers, but also art, English, and other humanities majors, whose skills are just as utilized in the software industry as the programmers we normally focus on. I will be talking about focusing workshop topics towards non-STEM majors.

Why workshops?

Generally, hackathons are not seen as a place for majors outside engineering. That’s why we must make an extra effort to show those people that we have experiences and material that is beneficial to them. For most potential attendees, we don’t get past a hand-wave response of “that’s not for me.” However, by selecting workshop topics that can be useful to non-STEM majors, we can show that hacking is something than many people can get a worthwhile experience out of. Holding accessible workshops before and during the event and correctly publicizing them can attract non-STEM majors to hackathons, increasing diversity across the board.

Why non-CS majors?

Let’s get something out of the way first. Hackathon organizations are clubs for programmers. It’s true that the tech industry is built on the back of brilliant developers but they don’t bear that burden alone. Having a more diverse attendee pool directly feeds into the professionalism of the hackathon experience. Hacks will tackle more diverse problems across a variety of disciplines. Programmers will be able to create hacks having professional-looking logos and UI made by graphic designers that are presented to judges by a business or marketing major who really has studied for this environment.

Other types of diversity

This also tackles another problem that hackathons and the tech industry in general have always had: ethnic, cultural, and gender diversity. Our initial thought was to reach out to diversity-advocate engineering groups on campus (such as Women in Computing) but, ultimately, the majority of their members were already attending our events. We figured that tapping into the greater academic community would be a better way to attract a more diverse audience. We personally hold workshops leading up to the event. VandyHacks hosts one workshop night month consisting of multiple sessions held at the same time. This helps boost our campus presence before our big event in November. Giving non-CS students practical tools they can use in the hackathon environment to create is a great way to bring new people in the door of the big event. With this in mind, we worked with professors in the human and organizational development department and the economics department to promote our events to their classes as well as offer extra credit to those who attended. I strongly recommend fighting for extra credit as this gets many people to take the time to show up. We have also considered reaching out to other student organizations focused around different majors to promote our events. This provides visibility but no clear incentive. I encourage organizers to get creative to make their own incentives. We’re lucky enough to be able to provide prizes for short “Hack Nights” that we hold after workshops to reward the best project made in a night. Some other ideas could be hyping up your prizes at your primary event or pushing how your workshop focuses on a desirable skills for different majors (i.e. Data analysis for economics majors).

Now that we’ve discussed a little bit on the “why” of the method and a little bit about how to get people in the door. We can talk logistics. The first step, and the one my committee spends at least three meetings on, is selecting the topic for the workshop.

1. Selecting a topic

In my experience, the selection for a technical workshop usually boils down to who on hand has enough knowledge on a topic to present on it. This step doesn’t change for a non-STEM focused workshop. However, you should consider looking for different talents within your organization than you normally would. It is important that the non-technical skill you choose can still be applied to the hackathon environment. For example, we had our in-house graphic design lead give a workshop on digital design. A business pitch presentation workshop would also be useful for the hackathon scene. However, an important part of this planning process is ensure you don’t fully alienate your core audience, programmers. This is the key to this process – straddling the line between approachable and technical. In this approach, you can find someone with a technical skill, say Excel, and get those creative juices flowing to create a tutorial project that will appeal to techies and draw in non-STEM majors. A good example we’ve used is R for data science. We did some operations on a data set that gave experience not only with a programming language that a lot of CS students might have never used, but also with data analysis techniques that might be attractive to more business-focused majors. We have found that holding a couple of workshops in the months leading up to your hackathon can really increase your campus or community presence and help attract new attendees.

2. Planning and Execution

Now that you’ve selected your project, it’s time to plan your presentation. Presentation is all about personal style. I’ve seen people walk through code, code on the fly, give PowerPoint presentations, etc. all to a successful degree so I won’t dive too much into the specifics. What’s important is that presenters shy away from coder-specific language. This seems obvious at first. We’re not going to be talking about parent processes waiting for their children to die or pointer arithmetic or exiting Vim in a beginner’s CS lecture. But it’s the small things that trip people up. For example, IDE is the most basic thing we use but I guarantee most people on the street can’t tell you what it stands for, let alone what it is. So when you’re reading over your notes, keep in mind those words that seem obvious to you and make sure they are book-ended with an explanation.

Another point for presenters is that constant posing of questions should be welcome. I have seen some presentations where speakers ask for questions to be held to the end and that does not work well for this case. The reason? People get really lost. If someone can’t get their IDE up and running then there’s no chance that they will continue listening to the lecture. This can then begin to sprout into thoughts of “programming is too hard” or “this isn’t for me” and that’s exactly what we’re trying to discourage. This could bleed into the structuring of your workshop. It could be better to have enough “primary content” for the first half of the time slot. Then have “bonus content” to make the project you’ve created better for the rest of the time. That way, if there are an abundance of questions, attendees still walk out with a minimum viable product of which they can be proud.


In conclusion, workshops can be framed and marketed towards non-STEM majors in such a way that makes the topics of hackathons more inviting and less intimidating. We can show that more than just programmers have a place within the world of the hackathon and that it is a great place to apply a pre-existing skill or learn a new one. We talked about the implications of focusing on the attraction of non-STEM majors into hackathons which can include positive benefits to the quality of the hacks as well as the diversity of the general attendance. Keeping all of this in mind, it is still important to cater to your primary audience of programmers and ensure your lectures straddle a line between non-technical and technical implementations. All in all, thank you for coming and I hope something in here helps make your hackathon a success.

No Comments Yet