The stuff outside the lab.

Part scavenger hunt, part build challenge. Teams were given a set of clues that pointed to physical locations around the college building — solve the clue, find the spot, and it revealed which electronic components you got to "acquire." The catch: you had to actually build a working circuit from whatever you managed to procure, and the first team to get a functioning model up won.

We got to know about the challenge at the very last second and honestly had no clear path in the beginning. None of us had previously worked with FastAPI, OCR pipelines, or document question-answering systems, so the first phase was pure learning while building under pressure.

For a week, we stayed in college until around 9 PM almost every day, iterating non-stop. We exhausted the free Gemini API tokens while testing and refining the workflow, learned Pinecone vector databases on the fly, explored PDF reading libraries, and experimented with multiple chunking and tokenization strategies to keep retrieval quality and response relevance stable.

By the end, we had a working system ready: document ingestion, retrieval, and answer generation were all in place. Deployment became the hard wall. Because of limited experience with Docker and packaging a heavy system, our builds kept failing. Even so, the project felt like learning a month's worth of engineering in seven days, and it changed how we approach rapid problem solving.

My team, Mihir Mohite and Nishad Dere, and I recently had the incredible opportunity to participate in the DataQuest Hackathon organized under HackMIT-WPU. It was a three-round competition that pushed our data science and machine learning skills to the limit.

Round 1: We built an ML model to predict sepsis risk from the given dataset. Out of 315 teams, we made it to the top 40 and secured our place in the next round.

Round 2 (Overnight Challenge): We received the dataset at 1 PM and had to submit by 6 AM. The task was to predict credit card default probability from a dataset with 1,200 features. High dimensionality and severe class imbalance made precision-recall balance very difficult.

We tried multiple approaches: SMOTE with XGBoost for oversampling and probability estimation, feature selection by removing highly correlated and low-impact features, and undersampling the overrepresented class to improve precision-recall balance. This strategy helped us break through to the final round as a top 20 team.

Round 3 (Finals): We presented our models and insights to a panel of judges, explaining our methodology and the reasoning behind our choices. We did not win, but the learning, experience, and connections were the real victories.

Key takeaways: The curse of dimensionality is real, understanding data matters more than blindly applying models, and feature selection plus dimensionality reduction can make or break model performance. Engaging with judges and reviewing winning approaches expanded our thinking beyond just coding a solution.