Or maybe he's old enough that he's used to thinking in assembly. I learned firmware on 8051 assembly, I've used C mostly since then but always with a reference,

Or maybe he's old enough that he's used to thinking in assembly. I learned firmware on 8051 assembly, I've used C mostly since then but always with a reference, and only the last few months finally am getting into C++. That doesn't mean I don't understand how firmware works. I know what's going on deeply under the hood, and I understand systems architecture. I know how to debug the stupid SPI interface when you're talking to an Analog Devices ADC that just won't respond for no clear reason. I know how to read the datasheets for parts and pick reliable ones that can be sourced readily and have sane interfaces. I have no idea what a linked list is. I do know pointers, but not super well, I just know that they're a spot in memory that gives you the address of another spot in memory, like the program counter. I know my limitations, I'd never try to interject in dealing with a system that has a full OS on-board, and I'd refer questions about encrypted bootloader based firmware upgrades to someone who knows what they're doing. But I still know what Mode 2 SPI is, and the typical noise levels on different kinds of shielded cable. That's not nothing. shrug I think the best way to determine if someone is a decent engineer is to get them talking about previous projects. If all they can do is talk about it at a high level and they don't seem to have any real knowledge of the implementation details, they didn't do the work themselves. I once had a guy who claimed to be an instrumentation engineer, but didn't know (even vaguely) how you would go about measuring temperatures in a process you're dealing with. I could be wrong (often am), but anyone who has done instrumentation but has never encountered a thermocouple... well, that would be a very unusual history.