Firmware engineers. Basically C programming and working close to the hardware.

My experience with this (as a C and C++ developer who's worked with embedded systems before) is those kinds of job postings tend to require an engineering degree, and most electrical engineers I've talked to want to do hardware not firmware (and didn't like their programming classes).

You could try either relaxing the degree requirements, or reaching a wider audience -- I generally don't see firmware jobs advertised on HN and StackOverflow and those are basically the only two places I ever pay attention to job ads. Depending on your existing volume of applicants you might also ask them to attach a semi-trivial C assignment to their application. Yes, this is accessible to anyone who can google, but you might weed out the disengaged who don't care enough to read the instructions that way.

Hmm, as andrewljohnson said, I expect that the posting impacts who applies, but I would expect that to disproportionately turn up applicants who can write C.

Another dynamic at play is the fact that those who don't have useful skills apply more often as they continue to be out of work, that doubtless accounts for some of it.

Still a bit strange.

Some examples of coding questions I've asked in the past: reverse a string in place. Ones count of an integer. I'm testing if they understand pointers and bit manipulations for example. These should be answerable in 5 minutes max in 5 lines of C code. The incorrect answers candidates generate surprise me.

Yeah, certainly stuff one should be able to manage if they're going to be working on firmware. Could you link to a posting you've got up somewhere?

In my interviewing experience (looking at the time for something not dissimilar), lots of people think that 'knows C' and 'embedded systems' are the same as "I took a single module involving C at university, and by the end of it, my things were only randomly segfaulting maybe 70% of the time."

Or they've never touched either C or an embedded system in their life, but somehow it ends up on their CV and they tell you about how passionate for learning they are. Which may well be true, but it raises questions about your honesty and/or capacity for introspection. Also, bare-metal embedded really isn't the place to learn C[1], given that most failure modes are "It doesn't work. And maybe something caught just fire."

[1] Ask me how I know...

I have had great luck hiring game devs and cross training into embedded.

"Oh I have to stream data into my processing routines with not nearly enough bandwidth? No problem."

I've also had smiles of delight when devs got 100% raw access to every little bit of hardware. Discovering DMA controllers is /fun/ for them. We came super close to getting a decompression routine running completely by our DMA controller!

Most people in this area are now older. I'm approaching 40 and I was recently at a tech demo and everyone around me seemed to be older than me. I remember taking Assembly in college and our professor explicitly telling us that we would not need to know any of it, but it was a good foundation to build on. As far as I know, of the people in that class I'm the only one that ended up actually writing a ton of assembly after joining a semiconductor company. Most of the embedded people were from EE, but didn't actually have as much of a programming background. I had approx. 2 college courses dealing with hardware in undergrad and that was not enough.

So, it seems you need to either accept a recent CS grad who seems adept at programming and can learn, or pony up the 200k+/yr to poach someone if you want to hire quickly. Most people I know that have done embedded work tend not to move around a bunch and aren't motivated by small amounts of money to move jobs, so you'd have to offer a large incentive to find the good people.