A Justification for Mentioning Your High School Rock Band in that Interview
People never ask me about SN0WCRASH on my résumé.
It’s true, I’ve put thousands of hours into being an indie pop star. It’s probably the modern version of the natural extension of a high school dream of playing Led Zeppelin tunes in an amphitheater, plus the guitar FX pedal junkie in me finding a new food source in the Digital Audio Workstation.
In other words, it’s what I put at the bottom of my résumé. Maybe because I want to differentiate myself from the next software engineer applicant by having them look me up on Spotify and hear me scream about digital girlfriends. Maybe I just can’t get over the fact that every semicolon I type into Atom closes the door to an alternate life by another micron, tugs a little harder on the rubber bands holding my identity together.
I’ve typed quite a few semicolons the past couple years, and continental drift is proof that slow but steady processes can be transformative.
Most of the time, during phone screenings, I get asked about Golang, or about Atlassian Git Tools, or the question, “Why the hell did you spend a summer developing firmware?”. I get it. I’m interviewing for a technical job, you should ask me technical questions.
But I want to show you a picture.
One of my coworkers this past summer was working on inter-band Qi communication. This isn’t very important to the story, but here’s the gist: you can get a wireless charger and a phone to talk to each other using the same electromagnetic coupling that charges the phone.
He’d encountered a problem. The signal was pretty messy (our ADC was not so good), and he was having a hard time translating the peaks and troughs to ones and zeros.
Being the intern, I spent most of my three months asking questions, not giving answers. So when he asked me what my thoughts were, I was a little surprised that I knew just how to solve the problem.
“Use an Equalizer.”
For those of you who haven’t spent too much time watching YouTube mixing tutorials (or haven’t ever messed with the sound settings in your car), an Equalizer is a musical effect that looks more or less like this.
Most people know about treble, mids, and bass—these are qualitative words we use to describe different frequency bands within the range of the human ear, 20 Hz to 20 kHz. Higher frequency sounds are tinny, sometimes grating. Lower frequency sounds are deep and bassy.
To give you a point of reference, the typical bass drum has most of its energy around 150 Hz. The human voice has a prominent frequency band around 3–4 kHz.
When you’re trying to get different elements of a mix to fit together, you use equalization on each of them to highlight the parts you want to hear, and scoop out the parts you don’t want to hear. This adds crispness and clarity to the mix, and allows you to better hear things like the splashiness of a great cymbal, or the griminess of a thick, detuned bass patch.
So when my coworker asked me about how to get ones and zeros from our messy ADC readouts, I thought to myself, “If I was at my desk, listening to this signal on my monitors, and I wanted to hear those ones and zeros better, what would I do?”
And the answer was simple. I’d figure out what frequency they were at, and use an equalizer to cut out all the frequencies except that one.
My coworker: “What are you talking about?”
Me: “Oh, I mean a high-Q bandpass filter with variable center frequency.”
I had to retranslate back to engineering speak—that garble of words and an equalizer are more or less the same tool, relabeled by both disciplines to engender the right connotation: highly technical in one case, timbrally oriented in the other.
I’d spent some time writing a fast equalization section for an audio effect I was working on a few months before. I copy-pasted the filtering algorithm into our Qi communication code. It passed all of our tests.
A lot of good engineers will tell me that what I did wasn’t anything special. I’d actually be inclined to believe them. Most (including my coworker) would eventually try out some kind of bandpass filter to clean up the signal. I can’t even say that I necessarily came to that solution faster than somebody else would have.
What I can say is that I would never have come up with that solution to the problem if I hadn’t spent hours poring over a mixing console, frequency hunting for an unpleasant ringing sound in a snare drum sample.
My understanding of a very technical problem was greatly enhanced by my ability to draw a connection between it and a seemingly different (but actually very similar) problem I’d encountered in a traditionally separate discipline.
This is STEAM. The power to see what you know in the things you don’t know; to construct metaphors that straddle the artificial boundaries between subjects; to dissolve long-standing barriers that exist not just between the Arts and the Sciences, but the ones that exist in our minds, telling us that an equalization plugin, a bandpass IC, a damped driven spring, and a predator-prey system are fundamentally different things that have no overlap.
In a profession that demands consistent, high quality problem solving, the value of a fresh perspective can’t be overstated. Not every problem will have an easy solution like “use a bandpass filter”, and it’s these kind of problems that don’t submit to single-track thought patterns.
STEAM isn’t just a re-skinning of the tech aesthetic with pseudo flat design and bold gradients (though some might tell you otherwise). It’s an interdisciplinary mindset that’s open to everyone to experiment with, embrace, and enjoy.
SN0WCRASH belongs on my résumé as much as Golang, or Atlassian Git, or “Firmware Developer Intern”, and if I ever have to interview a backend developer, my first question is going to be “who’s your favorite band?”.
