A four-layer PCB on GitHub doesn’t automatically make someone a hardware engineer.
But neither does an engineering degree.
I see both mistakes when people evaluate embedded and hardware engineers.
One candidate has built ESP32 boards, written firmware, designed a PCB and has a great-looking project portfolio.
Another has an EE degree and can explain the theory all day long.
Neither tells me whether they can actually engineer a product.
The real question is what happens when the thing DOESN’T work.
Can they explain why an I2C bus becomes unreliable as capacitance increases?
Can they debug a board that resets intermittently under load?
Can they work below the HAL when the abstraction stops helping?
Do they understand EMC, power integrity, thermal problems, tolerances, DFM, DFT and what happens when you manufacture 10,000 boards instead of one?
And equally, can the graduate who knows all the theory actually pick up a scope and find the fault?
“It works on my bench” is not production engineering.
The best embedded and hardware engineers I’ve worked with have both.
Theory gives you the mental model.
Hands-on experience teaches you what reality does to that model.
That’s why I think hiring managers need to stop asking simply:
“Degree or self-taught?”
A much better question is:
“When the hardware behaves in a way you didn’t expect, how do you figure out why?”
I went into this in more detail in my Medium article:
https://lnkd.in/g32Sz7Cj
For the hardware and embedded people here, which matters more when you’re hiring: formal theory, hands-on experience, or the ability to connect the two?
#EmbeddedSystems #HardwareEngineering #Firmware #Engineering