It's knowing how low level hardware operates and knowing how to dig yourself out of the various gotchas like for example figuring out that a last minute replacement of the crystal oscillator by the HW team with a cheaper one is now screwing up your boot process or that the reason your products are starting to go haywire after 6 months is an interrupt triggering too many writes to the flash, wearing it out prematurely, etc.
Sometimes being an embedded dev is dead easy. Other times you are dealing with a GCC chain from 2003. 2 layers of some 3rd party of libs that someone bought in 2005 because the VP was good friends with a buddy in some other company that made something similar (which you may may not have the code for). With 64k of flash and RAM. And the vendor ground off the chip numbers and put their own sticker in place. Playing detective, historian, and making good guesses as you may not even have access to the firmware anymore. Then on top of that sometimes you are really lucky and have a debug port and can play the printf logging game to see what is going wrong.
Condolences on the loss of coworkers.
But this seems interesting to software people who haven't been doing embedded, but who can wrangle C well enough to adapt (quickly?) to embedded constraints and interfaces.