Great article, folks, read it if you have any interviewing responsibilities! IMO.<p>Interviews are recognized as hard. With my experience, somebody asks me about some silly simple code problem, I never know what level they're going for. Is this in a server environment? IoT? Will it have uptime metrics? Is it business critical? Or just some utility.<p>The answer depends on all that. But no, usually they just want to know if I understand cooperative threads or something. Then I vector off - is blocking permitted, or do modifications occur in a driver or interrupt routine, other time-critical code? What is the threading situation? Hyperthreads? Multi-core? Different architectures e.g. DSP vs app processor? Power critical? Scheduling constraints?<p>No, they just want to see if I understand standard library locking mechanisms. No, I haven't used them in years (I do IoT etc where lockless queues and zero-kernel-call mechanisms are important) but let me Google something!<p>If the interviewer even appreciates my questions, then we can have some kind of meeting of minds. Else, it's a waste of time for both of us. We're just too far apart, operating at different layers of the software layer cake.<p>So thanks for listening to my personal rant about interviewing. Like belly buttons, everybody has one.