Hitting the Hackathon Jackpot: How Quizlet Live Was Born
A conversation with the inventor of one of the world's most popular classroom games
We all dream the hackweek dream - your janky creation solves a core customer problem, is prioritized by leadership and emerges as a product used by millions 🌈. For most of us that is just a mirage, an urban legend whispered on Hacker News and in the hallways of Silicon Valley.
In April 2016 Alec Winograd hit the hackweek jackpot at Quizlet, a global learning platform now used by over 60 million students every month for flashcards, quizzes and AI-powered learning. Alec designed and built an in-classroom game during a company hackathon and then led a x-functional team to scale that game, Quizlet Live, to millions of students.
This is the story of how Alec, now VP of Engineering at Oui Therapeutics, brought Quizlet Live into the world. I overlapped with Alec briefly at Quizlet where I worked from early 2017 thru to the end of 2019 leading Monetization. By the time I arrived at Quizlet, Alec’s successful hack project was already a Silicon Valley (or at least Quizlet) legend. I never had the courage to ask Alec about Quizlet Live when we worked together, but we caught up recently via zoom.
Alex: So, I have to admit, from the time I first heard that Quizlet Live was born in a hackweek I’ve wanted to have this conversation. I’m pumped!
Alec: Me too, this brings back good memories.
So let’s set the scene - what was Quizlet like back in 2015, 2016?
Well it was a lot smaller. I joined straight out of college in 2015. There were about 20 of us and we had about 10 million monthly active users (MAUs). So we were each roughly responsible for a half million users.
Talk about impact!
Seriously. That was a big reason I joined.
So how did Quizlet Live come about?
Every quarter or so Quizlet held a hackathon. It was a full day where you could work on new ideas, no strings attached. Around that time, in-class educational games were picking up steam. Kahoot was getting popular, and we all knew it was something worth exploring.
As part of a senior capstone project, I discovered this game called Space Team.
Space Team?
Yeah, you should give it a try. It's a game meant to be played by a group in the same room. The concept is you're a spaceship crew going through a meteor storm, and you need to perform certain operations to keep the spaceship from crashing and burning.
So no pressure.
None! And to make it even crazier, instructions for one of your teammates pop up on your screen and vice versa. So Space Team is really about how you pull together, communicate and complete the instructions in time before you crash and burn.
Ok, I think I can see how you might apply that to a classroom.
Right! Space Team gave us the kernel of an idea. I loved the idea of applying that collaborative energy to learning. So that’s what we built in one frantic day - a working prototype of a collaborative learning game where students work together in small teams to answer questions from their Quizlet study sets. We focused on just the bare bones of a working game we could demo and play with the company at the end of the hack day. We presented it at the end of the hackathon, and people loved it–it was good, chaotic fun.
So did the leadership team latch onto it right then and there?
Not exactly. The team was working on a bunch of other stuff around that time so there wasn’t really any bandwidth to turn it into a real product. It was a few months later that Quizlet decided to invest in a classroom game and a team was created. But turning a prototype into a real, scalable product was a whole new challenge.
Love hearing about challenges. What were some of the biggest hurdles?
Oh, there were plenty! First, we needed to refine the actual game mechanics. Our PM, Sophia had a lot of experience going into classrooms. She really understood the environment and was attuned to what teachers would and wouldn’t like (since ultimately they would control whether students got to play the game).
Change incoming!
Exactly. She was like “I like this chaotic thing where everyone's shouting random words, but teachers are going to hate it.” So the first challenge was rethinking our game mechanics.
The way we approached this was constant rounds of testing and iteration (Editor’s note, for more on testing see Shipping on Friday’s “A/B Testing in Action”).
Sophia and I developed ideas, tested them with teammates, and refined them based on feedback. Eventually we got to a point where we felt confident enough to go into a classroom and test with real students. This was invaluable for learning. We were able to observe how our target audience interacted with the game. After each classroom visit we synthesized learnings and iterated on the game play, ultimately arriving at the MVP we launched.
I love that approach to building. Learn and iterate. You discussed user experience challenges, did you face any technical challenges?
Yes! The first major challenge was the real time nature of the game. Most web applications follow a simple request-response model—you click a button, and something loads. But with Quizlet Live, we needed data constantly flowing between 20+ student devices, all within the same classroom. With every game move - every new answer right or wrong - data was trying to sync.
All that synching added up and we noticed it would congest classroom wifi networks causing unreliability and slowness. We had to optimize how often devices communicated and how much data we sent at a time.
How did you approach that?
We started thinking through which players needed what information and we realized that in our original architecture we sent all players all the game data including some that they didn’t need and wasn’t even displayed (think info related to other teams). We refined who we sent what, which cut the data flow significantly and solved the majority of our issues.
So once you solved the real-time networking, how did you think about scaling? After all, Quizlet is used by millions.
That was another tricky part. At first, we ran Quizlet Live on a single server. But as more classrooms started using it, we needed multiple servers. Normally, in a large-scale web service, you load-balance across many servers and can scale up and down dynamically. But with Quizlet Live, every student in a classroom had to be on the same server for the game to work.
That sounds like a nightmare.
Yeah, if we didn’t handle it right, students wouldn’t be able to connect with their classmates. Imagine we’re scaling up to an additional server just as your teacher is starting a new game. It would be a disaster. Our solution? Well, when a teacher launched a game, their device would generate a game PIN. We implemented a custom load balancer strategy that used the PIN to consistently route all students in that session to the same game server.
Clever!
Thanks! This solution allowed us to scale and within a year, Quizlet Live had grown to account for about 10% of Quizlet’s total traffic. Scaling that quickly was intense, but super rewarding.
Any fun stories from development?
One of my favorite moments was when we were testing team names. We knew we wanted students to be in teams, but we weren’t sure how to name them. Giving each team a number was just boring.
Someone suggested colors, another person suggested cities, and then someone proposed animals. We liked the animals idea, but were a little hesitant because we weren’t sure how our high school users would respond. Were animal names too childish?
What did you decide?
We tested it, of course! We found that in classrooms the moment the team names appeared—Lions, Tigers, Bears—the students went wild. They absolutely loved it. Any concerns we had about it feeling too juvenile vanished instantly. Students would chant their team names - they were excited to play!
There is a fun Easter egg related to team names. Every 1,000th game, a team gets named “Unicorns.”
That’s amazing.
Yeah, little things like that make a big difference.
That's such a great moment when you realize, you've built something that truly resonates.
Definitely. Though, we also had a humbling moment slash learning experience.
Oh?
A few months after launching, we received feedback from a teacher at a predominantly black school that some students got offended when they were assigned to the “Monkey” team. We realized that our own unconscious bias had missed the historical context. We thanked the teacher for the feedback, removed “Monkey” as a team name, and audited the other animals for similar issues.
That’s a great lesson about putting users first and striving to think from their perspective even when it comes to the most seemingly trivial decisions like choosing animal team names.
Looking back, what’s your biggest takeaway from building Quizlet Live?
I think the biggest lesson is the power of rapid iteration. The hackathon gave us the space to explore a wild idea, but refining it into a great product required constant user feedback and testing. Without Sophia driving that effort and iteration, Quizlet Live would have fallen flat–too unfocused and chaotic.
Also, making learning fun isn’t just a gimmick—it genuinely helps students engage better. Watching Quizlet Live go from a small side project to a major part of the platform was an incredible journey.
And now it’s played in classrooms all over the world. Pretty amazing.
It really is.
And that’s the story of how Quizlet Live was born—from a simple hackathon idea to a global classroom favorite. It’s a great reminder that the best products often come from experimentation, teamwork, and a willingness to learn from real users.
Do you know a Hack project that hit the jackpot? Let me know in the comments! 🚀