MatchMe

Planning!
Screen designs that we've done
Sorting users into teams
Screen where you can select your projects
Debugging screen of our preference assigning algorithm!
Selecting preferences

Inspiration ⭐

No matter what field, workplace, situation you find yourself in; leadership and roles are a critical part of successful everyday functioning and management. However, the selection process for such positions can prove to be challenging. Scrolling through hundreds of applications, sorting out who goes into which role to make sure everyone gets something they’re happy with can take hours, wasting precious time and energy.

That’s why we’ve engineered a solution, aiming to solve such a common and time-intensive issue across the globe. As a result of our solution all kinds of organisers, and most importantly, the applicants themselves - can look forward to a more efficient and seamless selection process, designed to maximise happiness without headaches!

What it does 🤔

MatchMe allows administrators to create “events” on our platform, which, simply put, are groupings of distinct roles that participants will preference accordingly. To put this into context: say that you are a tech recruiter; then an “event” would be, say, a Software Engineering Job; with the roles being Frontend, Backend and Full-stack.

Once an administrator has confirmed these roles, the preferencing begins! URLs are sent out to all participants, who will order their preferences. These are sent live to our platform, and carefully stored. After this, the administrator locks in the event, and starts the allocation! Our internal algorithm processes the preferences, and assigns participants their roles in near instant time.

How we built it 💻

Research 🧠 Our solution is based on a known algorithm called cycle-cancelling. We imagined each of the distinct roles as nodes, and preferences as the costs on a flow graph. And by running the cycle-cancelling algorithm on this graph, we could achieve essentially what is the best preference allocation.
Development ☁️+ 🍾+ ⚛️ Our frontend was built with TypeScript, and uses React, Vite and Tailwind to create an awesome design. The UI was initially designed with Figma, and seamlessly translated into a real, live product. The frontend packages all user input, sending it to our backend to handle its magic!

Flask is our backend handler, and interacts with the database, which is hosted by AWS. Flask hosts routes which service incoming and outgoing requests, including administrator and participant interaction. Our backend team effectively programmed the backend to simulate the graph problem needed to handle the preference allocation, and returns this to the frontend, with a clear, easy-to-digest format. It also comes with CSV support, allowing for allocation data to be more cross-compatible.

Challenges we ran into 🌀

Amazon RDS’ configuration proved to be challenging for first timers like us. The countless number of settings proved to be a main obstacle. A challenge of note was setting it up such that all incoming connections were compatible with all URLS. Now with the database set up, SQLAlchemy emerged as another cumbersome task. Though our backend team had prior experience, re-learning was difficult, as the documentation was challenging to digest, thus writing queries became tiresome, often requiring many trials before we could get it right.

The matching algorithm also proved to be a big obstacle. Over the course of 48-hours, several unhandled edge cases would prove fatal, crashing our backend; and so extensive test cases and progressive code revision were required.

Another challenge was the event creation page, specifically on the frontend side. We initially envisioned a dynamic table with editable cells and dynamically creatable columns and rows. However, this proved to be a greater challenge than initially anticipated. The component library we were utilising, Material UI, did not natively support the dynamic creation of columns with the storage of data from editable cells. After working on trying to implement it for an entire day, we had to pivot away and change the frontend design for that page to be a grid of cards.

Accomplishments that we're proud of 🏆

Our implementation of our matching algorithm and our Flask backend, complete with database. We’re also proud of being able to at least get a minimum viable working product both functionally from a frontend and backend standpoint in under 48 hours.

What we learned 🧑‍🏫

As many of us were doing a hackathon for the first or second time, we ended up learning quite a lot from working on MatchMe in the 48 hour period for UniHack 2024. Mainly, that 48 hours is a lot less than it seems :)

What's next for MatchMe 🚀

So far, we’ve presented the barebones of our project. But our aim definitely extends further. With the onset of CSV support, integration with existing workflows is on our horizon. Seamless interaction with Google Sheets and Microsoft Excel, would immensely improve convenience and compatibility with nearly every organiser out there. In addition, another convenience to add would be the automation of sending out the links for participants to preference their roles, whether that be via email or via other forms of communication.

In the long term, we have quite a few things planned. After the participants have preferenced their roles, how do we know how well suited they are for such roles? Inside our algorithm, we will add additional matching criteria such as modifiers to a person’s preference based on their skill level for their role (as assigned by the administrator). Furthermore, we could integrate machine learning in order to automatically generate or recommend a skill level modifier based on a participant’s resume or recruiter interview feedback.