[ohdannyboy]

I'm currently doing interviews for a senior firmware dev position and was stunned by this. Today I talked to a guy who couldn't tell me what an interrupt was in any technical detail. His coding was worse than a first year college students. 5 of the 6 people I've talked to so far bombed the coding portion.

[AlotOfReading]

This isn't intended as a rebuttal, but I've learned to stay away from deeply technical questions in embedded. As long as the interviewee is sufficiently paranoid about C, is recognizably experienced via conversation, and knows the basic concepts I don't press too hard on their specific skillset.

There are just too many niches where the knowledge we each consider necessary simply isn't. I had one particularly bad interviewer grill me on how the ARM GIC worked in detail (e.g. interconnect details, differences between versions, etc) because they considered it basic knowledge. I've personally never needed to know anything about it that wasn't in a TRM.

[greyhair]

I agree. Why memorize something that is well documented? Do you understand basic interrupt management and the existence of interrupt controllers? Good. Understanding basic concepts matter, but silicon implementations of a concept? No.

One question I have found useful in embedded development is asking someone to discuss the difference between a thread and a process, and the difference between thread based OSs and process based OSs. It is a general question, not bound by anything like CPU architecture, but just gives an idea into whether the person is comfortable about general memory domains.

I have mentored people, bright programmers that never worked in small embedded systems, that initially tripped all over the thread model, but eventually came to understand it.

[ohdannyboy]

Im pretty new to interviewing so I appreciate the feedback. I think I'm dong OK with respect to that but I'll make sure not to assume my own expertise are trivial.