7) Behavioral

Tell me about a time you debugged a difficult hardware problem

On ChromaWave I was getting distorted audio output from the microcontroller that I couldn’t explain from the code. So I went straight to hardware and used an oscilloscope. The waveform shape looked correct, but the amplitude was varying at specific frequencies, which pointed to a timing issue rather than a logic bug. I traced it to a DMA buffer issue — the firmware was writing into a ring buffer faster than the DAC was consuming under load, causing overwrites. I fixed it by adding a buffer fullness check before writes. The main takeaway for me was that code can look correct and still be wrong — the scope shows what the system is actually doing.

Tell me about a time you worked under pressure

At Cornell Tech we had a catapult competition with a hard demo deadline. I scaled an existing design by 1.5x, which broke the trigger geometry — the arm wouldn’t release cleanly. I had to quickly redesign two components in Fusion 360 and get them laser-cut within a day. The constraint forced me to focus only on what mattered — fixing the critical path instead of everything. The device launched successfully. The main thing I took from that is that hard constraints actually improve decision-making — you focus on what really matters.

Tell me about a time you worked cross-functionally

On SCENE, my partner handled the software layer — Flask API, Spotify integration — while I handled hardware and firmware. We ran into an issue where her API was sending LED updates faster than my UART buffer could handle, causing silent overflows. From her side everything looked fine, and from mine everything looked fine, so neither of us could diagnose it alone. We fixed it together by adding rate limiting on the software side and flow control on the firmware side. It’s a good example of how problems at system boundaries need both sides to solve them.

Tell me about learning something new quickly

In my ASIC design course at Cornell, I started with no experience in industrial EDA tools. Within a couple of weeks I was using tools like Cadence Genus and Innovus. What helped was separating concerns — I first built a Python reference model of the cipher I was implementing and verified correctness there. Then I translated it into SystemVerilog knowing exactly what the output should be. That approach let me debug logic and tooling separately, which made ramping up much faster.

Tell me about a failure and what you took from it

On Orbit 360 I was targeting ±2cm navigation precision but was stuck around ±15cm. I initially assumed it was a SLAM algorithm issue and spent a lot of time in the code. Eventually I checked the physical setup and found the ultrasonic sensors were slightly misaligned, introducing systematic error. Once I fixed the mounting and recalibrated, it hit the target. The main lesson for me was to verify the physical setup before diving deep into software — hardware errors don’t show up in code.

Tell me about making a technical decision with incomplete information

On SCENE I had to choose the communication architecture before fully characterising latency. I knew the system target was 30Hz, so about 33ms per frame, and I estimated that communication needed to stay under ~5ms to leave margin. I designed the UART protocol around that assumption. When I later measured it, it was around 1.2ms, well within budget. The approach I use is to make a defensible decision based on known constraints, document assumptions, and then validate them once real data is available.

Tell me about advocating for a technical decision

On SCENE I advocated for a split-processor architecture instead of running everything on the Raspberry Pi. My reasoning was that Python’s garbage collector can introduce unpredictable pauses, which would cause visible flicker at 30Hz. We implemented both approaches and compared them, and the difference was immediately visible. That reinforced that the best way to resolve technical disagreement is to test both approaches and let data decide.

How do you handle critical feedback on your work

I treat it as information. If someone points out a flaw, the goal is to evaluate whether they’re right, not defend what I did. At Cornell Tech I incorporated feedback on SCENE’s architecture that led me to change some decisions. I’ll push back if I have evidence, but that pushback is based on data, not defensiveness.

Tell me about improving a process

At Imperial, the signal-processing pipeline I inherited took several hours per dataset, which slowed down iteration. I profiled it using cProfile and found redundant computations and unvectorised loops. I refactored it to cache reusable results and replaced loops with NumPy vectorised operations. Runtime dropped by 61%. The improvement was also structural — the code became much easier for others to understand and maintain.

What’s your approach when you’re stuck on a hard problem

I stop guessing and go back to ground truth. Instead of tweaking code, I measure what the system is actually doing — using an oscilloscope or logic analyser. Hardware and software fail differently, and measurement helps separate them. If I’ve been stuck for a while, I’ll grab someone for a quick sanity check rather than losing more time. I also document as I go so the same issue doesn’t happen twice.

Tell me about a cross-team difficulty you navigated

In a VR course at Cornell Tech, I was on a six-person team where contribution ended up being uneven — I implemented a large portion of the core systems. I raised it early with the professor rather than letting it build into a bigger issue. The main lesson was that setting expectations and being transparent early prevents larger problems, and that I work best in small, high-ownership teams where responsibilities are clear.

How would you approach your first week if you were given a Portal PCBA and told to test it?

I’d start by understanding the system before powering anything — schematics, block diagram, whatever documentation exists — just to build a mental model.

Then I’d bring it up methodically: current-limited supply, check for shorts, and verify power rails one by one.

Once power is stable, I’d move to communication buses and then functional blocks.

And I’d log measurements as I go so I have a baseline.

If possible, I’d also talk to the designer about power sequencing or fragile nodes, since that can save time.

I’ve done something similar on my own PCB projects — the main thing I’ve learned is not to skip steps early, because that usually creates bigger problems later.