top of page

How Checkpoints Made My Project Better

ree

At NYU, one of my most memorable courses, High Performance Machine Learning, ended with a final project. Unlike the usual format of exams and papers, this project was designed with built-in checkpoints that guided us from the idea stage to the final presentation.


The project started with an initial idea meeting. Our professors Parijat Dube and Zehra Sura asked each group to come prepared with a rough outline of what we wanted to work on. Honestly, my teammate and I walked in with a time-series forecasting project idea, which was slightly vague and slightly ambitious. Instead of us running with it blindly, our professor asked sharp, guiding questions: “What problem are you really trying to solve? How will you measure success? Who benefits from this project?” These questions forced us to refine our concept into something concrete and achievable. We left with clearer direction and a sense of confidence that our idea was actually worth building.


A few weeks later came the midpoint check-in. By that time, we had started building our project but were running into roadblocks. Some parts of our solution looked strong, but other areas felt clumsy, and we weren’t sure if we were on the right track. Having a scheduled touchpoint with the professor and getting immediate feedback was helpful. She validated the progress we had made, pointed out we were overcomplicating things, and suggested resources we hadn’t considered. More importantly, the checkpoint gave us a moment to pause, evaluate, and realign before it was too late. Instead of spiraling toward a dead end, we were able to change our approach and simplify, which made our work more polished. For example, we had quantized the model by ~30%, but after feedback and suggestions to check out specific Github discussion forums we found ideas that other developers implemented. This helped us to reduce the model size by 74%.


Finally, we had the final presentation a week before the semester ended. Each team had to deliver a 10-minute presentation that included a three-minute demo of the project. We were given a detailed rubric a week ahead, which outlined what to cover and kept us focused. It also forced us to be concise and well-structured so we could finish within the time limit.


What really stood out, though, was the Q&A session that followed. It wasn’t the typical stressful viva exam I had prepared for. Instead, it felt like a conversation. The professors asked practical, implementation-focused questions that showed they genuinely cared about our learning journey, not just the project results. And when we stumbled or missed something in our answers, they didn’t just mark us down, but they explained, taught, and nudged us to think deeper. That back-and-forth made the evaluation feel less like a test and more like an extension of our learning.


Looking back, I realized how important those checkpoints were for me. Instead of rushing to put something together at the last minute, we always knew where we stood and what we needed to improve. It helped us explore more concepts with a guided hand of professors. By the time we gave our final presentation and demo, I felt proud of what we had built and more confident in explaining it. What I appreciated most was the flow of projects and feedback given by the professors. That structure made all the difference, and it’s something I’ll carry with me into future projects.

 
 
 

Comments


bottom of page