Audio Programming Jobs

I’ve been thinking a lot about the field of audio and its prospects as a software engineer.

I’ve read a big chunk of So Good They Can’t Ignore You by Cal Newport and I’ve taken away that for the vast majority of people, becoming highly skilled at something comes before passion. We often try to find our passion first and then pursue it; however, when you examine passionate, successful people, it’s often the case that their passion (and subsequent desirable lifestyle) came after investing in becoming a “craftsmen” in their field. They built upon acquired career capital instead of starting from scratch in a new field.

I’ve read a big chunk of Soft Skills: The software developer’s life manual by John Sonmez and one of the things I’ve taken away is that a software engineer needs to specialize.

What do you call a software engineer that works in audio? An audio programmer? An audio software engineer? How about an audio digital signal processing (DSP) engineer?

What domains do such individuals work in? Music? Speech? Communications? Academia? Gaming?

Is it possible to live anywhere and do this work? Can you work remotely? Can you consult?

What technologies and concepts should one study? [1] I admire the work and business that the folks of AudioKit are creating for themselves. That could be a good place to start. They recently wrote of some project ideas that new folks can pursue. I recently purchased The Scientist and Engineer’s Guide to Digital Signal Processing by Dr. Steven W. Smith. It is available online for free. I got excited after skimming through it because it was written in a very approachable way. Should one start there? What about taking the Stanford’s MOOC course Audio Signal Processing for Music Applications. Or how about the course Physics-based Sound Synthesis for Games and Interactive Systems?

One way to start to answer these questions is to look at what the market says through job postings. As Patrick McKenzie stated, most jobs actually aren’t posted and most positions aren’t filled through job postings [2]. Nevertheless, analyzing the public record of the market can provide valuable insight.

Research

I manually went through 151 job postings. Below are my findings:

Frequency of Words in Titles

The following words appeared in the title of job postings at least 4 times.

Locations

The following are the top six locations by number of job postings:

1. California, USA - 49
2. Washington, USA - 21
3. Massachusetts, USA - 21
4. United Kingdom - 12
5. Michigan, USA - 6
6. India - 6

Industries

The analysis of the job postings by industry was somewhat subjective. I determined a position’s industry by looking at the company’s listed industry on it’s wikipedia page. I also considered focus areas in the job posting’s description.

Education - Degree

Education - Field

Languages

Top 6 Audio Related Skills by Number of Postings:

1. DSP - 106
2. Speech - 48
3. Audio Formats (Transcoding, Codecs) - 41
4. Transducers (Microphones, Speakers, etc) - 40
5. Real-time Concepts - 35
6. Sound Design, Sound Engineering, Acoustics - 34

Top 8 DSP Related Skills by Number of Postings:

1. Noise - 30
2. Echo Control - 22
3. Filtering - 21
4. Sound Effects - 12
5. Reverb - 12
6. Equalization - 9
7. Fixed Point; Floating Point - 9
8. Compression - 8

Notes

[1] At first glance, asking this question appears to go against the mindset of striving to be an excellent engineer not bound by a stack. Patrick Mckenzie makes the claim that one is “… not defined by your chosen software stack”. He says that “If a Python shop was looking for somebody technical to make them a pile of money, the fact that I’ve never written a line of Python would not get held against me.” Talented engineers are rare — vastly rarer than opportunities to use them — and it is a seller’s market for talent right now in almost every facet of the field. Everybody at Matasano uses Ruby. If you don’t, but are a good engineer, they’ll hire you anyway. (A good engineer has a track record of — repeat after me — increasing revenue or decreasing costs.) Much of Fog Creek uses the Microsoft Stack. I can’t even spell ASP.NET and they’d still hire me. [A]

I think what Mckenzie is saying makes sense. I don’t think my original question “What technologies and concepts should one study?” is in contradiction to his sentiment. Part of the reason to specialize (thus learning a stack or domain) is in order to market yourself [B]. How will people know that you are an excellent engineer? Specialization helps one market themselves and expand their network. My theory is when your reputation is established in the community, then it will likely be eaiser to be in a situation where you are hired to work on technologies you aren’t familiar with as Mckenzie expresses.

[2] McKenzie wrote, ‘“Read ad. Send in resume. Go to job interview. Receive offer.” is the exception, not the typical case, for getting employment: Most jobs are never available publicly, just like most worthwhile candidates are not available publicly (see here) …’ [A]

[A] McKenzie, Patrick. Don’t Call Yourself A Programmer, And Other Career Advice. Blog. Kalzumeus Software Blog. Publish 29 October 29 2011. Web. 28 July 2017.

[B] Sonmez, John. Should Software Developers Be Generalists or Specialists? . Blog. Simple Programmer. Publish 19 June 2017. Web. 13 August 2017.

Data