For UW Data Science club's largest speedfriending event. Take a buzzfeed-like test and our hybrid matching algorithm will find you your next best data buddy.
Throughout high school, I used to pride myself on filling my lunches and after-school time with clubs and sports. Many of my core memories came from staying after school late planning events for the student council, or laughing in the changeroom after volleyball practice.
When I started my first term at Waterloo, I saw a rather stark shift in my priorities– all of a sudden, I found myself sitting in the sad corners of our DC library catching up on lectures. I promised to put myself out there more.
And thus, I joined the Data Science club at UW! Trying to avoid the bad ending where all of my hobbies and clubs become tech-related, I applied to the logistics team for a change.
So, you can imagine my confusion when I got an interview invite to be a tech lead instead. It felt almost comedic how I found myself interviewing for a technical role despite intentionally straying away from it.
I ended up taking the role and becoming the tech lead to an awesome team of 4 girls: Lydia, Aditi, Anh and Monica.
There were a few projects that DSC would be working on throughout the term. The one that caught our eye was their infamous “Speed-dataing” event, where members of the club take a BuzzFeed-like quiz and then get matched with each other in classic blind-date fashion.
The matching process was manual! It involved collecting responses from Google Forms and then reviewing them to create matches. Last year, they kept the Google Forms, but plugged all the responses into ChatGPT so that AI could play cupid.
However, this was extremely inefficient, less whimsical, and people who came later to the event could no longer participate.
It was going to be different! I was determined to create a scalable platform that could be used for every subsequent term. As the tech lead, I took the initiative to design the project architecture, starting with the core functionalities.
I also asked each team member to share more about their previous technical experiences and what they were hoping to work on within the scope of the project.
After sketching out the goals, I explored different frameworks and weighed the tradeoffs. I needed something that could handle real-time form submissions, integrate smoothly with an external DSC authentication system, and still be light enough for the team to pick up quickly.
Eventually, I landed on a Next.js / TypeScript stack, paired with Supabase and OpenAI embeddings for the matching algorithm.
This was the heart of our project. Instead of manually pairing people up, I wanted the system to generate meaningful matches in real time. Also, we wanted to change it up this year by doing both multiple-choice and short/long answers. No more being matched because two people both chose a lot of C’s.
To accommodate, we decided to use vectors. We numerically calculated the similarity between multiple-choice answers, and then used OpenAI’s embedding model to convert words into long numerical vectors that capture their “meaning.”
Once everyone had a vector, I could measure how alike two people were by calculating the cosine similarity (distance) between their responses. Higher scores meant they were more aligned/closer.
From there, I built a big graph of all possible pairs and their similarity scores. To keep things efficient, I used a greedy algorithm: start with the most compatible pair, match them, then move to the next best unused pair, and so on until everyone has a match.
If you’re unfamiliar, a greedy algorithm is exactly what it sounds like: an algorithm that makes the “greediest”, best immediate choice at each step, without worrying about the bigger picture.
If there was an extra person, the system set them aside and guaranteed them a match in the next round. That way, nobody slipped through the cracks.
By week 4, we began stringing together the components that we worked on individually. We combined the form component and the matches component with the dashboard, and we connected our authentication system with the existing DSC database.
The final, most important step would be implementing state session management. The actual event is sequential and split into different rounds of matching: how do we ensure that everyone fills out the form before we match?
Our solution was an admin dashboard: by verifying a user’s “role” with the DSC database, we created a system where DSC executives, when logged in, could access an exclusive dashboard that controlled which step of the matching cycle they were in. The states were updated in real-time via Supabase.
These states subsequently determined what participants could see/do on their end.
Truthfully, I was finishing the platform and resolving bugs even the morning of the event, and fixing up the deployment an hour before.
With the authentication system, matching algorithm, forms and admin dashboard ready, the event was ready to make some matches! We were even able to throw in some meme ideas last-minute, such as a data-science pickup line generator to look at in between cycles.
Though this past term on DSC didn’t play out as expected, I am so glad I took the leap. To see the project come to life, and to see our team become a close group of friends, many memories were made through code reviews together or our silly easter egg ideas. Time really flies in university, and I’ll always keep making the most out of my time here!