How I got here
NIT Sikkim is a newer institution in the northeast of India. There was no large alumni network and no established research pipeline around me. I spent the first two years figuring out what I actually wanted to build. In my third year I found it in a professor who was working at the intersection of machine learning and speech processing and was genuinely open to taking on an undergraduate who wanted to do real research.
The problem we worked on was dysarthric speech severity classification. It was a low-resource problem with limited data and not much prior work from an electronics and communication angle, which is part of what made it interesting. I spent a year on it, mostly just me and the professor, and it eventually led to an IEEE SPCOM 2024 paper and a journal acceptance in 2026. I was the only person from my batch who stayed with a full year of research and got it published. That year taught me more about hard problems than anything else in my undergraduate degree.
When I graduated, I had an MNC offer for a Technical Consultant role. I turned it down for an SDE internship at SalesUp, a growing startup. That choice mattered. At SalesUp I was closer to the real decisions: conversations with founders and clients, understanding what the business actually needed before writing code, and building with real budget constraints and no safety net. Working across business, sales, and tech at the same time gave me a clearer picture of what software is actually for than a structured rotation would have.
For my master's degree, I wanted to go deeper on the hardware-software boundary, the layer where a performance problem stops being only a code question and starts becoming an architecture and systems question. NYU Tandon pointed in that direction.
What I work on
My projects tend to live at that same boundary. I wrote a CUDA kernel for transformer inference because I wanted to understand what the profiler was actually telling me about memory movement, not just run benchmarks and report numbers. At SalesUp, the P99 latency problem turned out to be an architecture question disguised as a code one. The dysarthria research started from wanting to understand how speech breaks down at the motor level, not just model the acoustics.
The pattern across all of it is the same. I want to understand what the system is actually doing, not just what it looks like from the outside.
What I'm working toward
I am joining Amazon this summer as an SDE intern. The longer direction is systems software at the hardware-software boundary, the kind of work where the software has to understand what the hardware underneath it is doing. Memory hierarchy, kernel-level execution, and the gap between what the architecture promises and what the profiler shows are the parts that keep pulling me in.
What I'm working on now
Lately that has meant staying close to systems work that has real constraints underneath it: performance questions that need profiling, ML workflows that need to hold up beyond a notebook, and backend habits that keep software reliable once it starts serving real users.
Outside all of this
I spend time with close friends, trying new restaurants, cooking, playing badminton badly, and just talking. Nothing structured. That is the point.