ENSEACK was my fourth hackathon and the first one I couldn’t leave.
At the three I’d done in Montreal and in the US, you could go home at two in the morning, or order food, or at least walk somewhere. At ENSEA you were locked in for nineteen hours. Nobody had warned us to bring food. A student group was selling crêpes and sandwiches, and my last real meal had been at noon, before any of it started. So I spent most of that night debugging on an empty stomach, chasing errors I was certain I’d already fixed.
Our team was five Americans, from Pitt, LSU, UMich, UF and Illinois Tech, most of us juniors or sophomores. No FAME student had ever entered ENSEACK before that year. There were two FAME teams this time around, and we were the only two who presented in English. Everyone else was French, and most of them were well past our level, since French engineers spend two years in prépa before three years of engineering school and graduate at master’s level.
The theme was technology serving music. We set out to build Charles de J., an autonomous DJ system. The name is a pun on Charles de Gaulle, the famous French general, and I spent most of that night quietly convinced a French audience would find it cringeworthy.
The system pulls royalty-free tracks in real time, analyzes each one for tempo, energy, and genre, and picks the best track for a live room-energy rating from one to ten. My part was the layer that turns sound into instructions: a Python code sending serial data to an Arduino Mega driving an LED matrix, where color tracks the song’s energy and every detected beat sends a ripple expanding outward across the display. This could be used as a floor mat or reactive lights for events.
Around midnight, judges walked the floor giving advice. They told us not to lean on AI, and to write an algorithm that computed the tempo and energy values ourselves, from the audio.
I had no idea where to begin. That was the first time all night I felt genuinely out of my depth, and it wasn’t because the problem was too hard to understand. I understood exactly what they were asking for. What I didn’t have was any instinct for how you’d start. I said yes, yes, because the rigor behind that suggestion was so unmistakably French that there was nothing else to say, and I went back to my laptop.
At five in the morning, we found out the service we were pulling our data from didn’t expose the two values our entire system depended on. Nine hours of work were useless. There was no time to build a database of analyzed audio from scratch. The deadline was noon.
The team was finished. And I want to be honest here, because this is the part that changed how I think about leading anything: so was I. I was hungry, I’d been awake since the previous morning, and I was ready to call it.
What stopped me wasn’t determination. It was arithmetic. The hardware and wiring were easy to manage, but the Python code wasn’t, and I wrote it. Quitting wasn’t really a decision I could make on my own behalf, because making it would have made it for four other people too. So I worked alone for about two hours while my teammates slept, rebuilding the analysis so we pulled the features out of the audio itself instead of asking a service to hand them to us.
We had a working prototype by noon and the name I’d worried about all night turned out to be fine. They loved it!!
Our prototype was rigid, and I’d say so to anyone who asked. You set an energy level and it ran. You couldn’t change songs mid-run or add anything to the playlist. Nineteen hours gets you a demonstration, not a system. We didn’t place. The other FAME team won the public prize. But after the results, one of the judges came over to tell us ours was the prototype he’d liked best. We hadn’t won anything. I’ve kept that anyway.
The thing I actually brought home was the discomfort. During our presentation, I explained that a library had computed our values rather than us deriving them ourselves, and I watched a judge’s expression shift. He wasn’t telling me we’d misunderstood our own design. He was telling me that the interesting part of the problem had happened somewhere outside our project. I hadn’t thought about engineering that way before, and I think about it constantly now. Before I reach for someone else’s solution, I ask whether I’m building this or assembling it.
And I’d describe my leadership differently now. Before that night, I would have said leading a team was about organizing the work and keeping everyone moving. What I learned at five in the morning is quieter than that. Sometimes leading just means noticing that the critical path runs through you, and that walking away isn’t a decision you get to make alone.