This is pretty significant. I recently had the opportunity to sit in on some meetings & IM conversations with a recruiting team at my workplace, and was pleasantly surprised with how detailed they were in honing their interview approach.

One proposed open-ended interview question in particular (these recruiters utilize both coding exercises & open-ended questions, plus some other stuff), "What's the difference between the stack and the heap?" was shot down for a number of reasons - colloquially, these refer to two different pools of memory wherein variables can be allocated. But stacks and heaps are also specific data structures, so there's some ambiguity. Most importantly, it's surprisingly difficult to answer that with anything that's 100% correct (e.g. "the stack is for variables with known lifetimes, whereas the heap is for those with unknown lifetimes" is really just a convention, and there are plenty of exceptions w.r.t. data structures of size that isn't compile-time constant, or dealing with polymorphism in certain languages). And since the question is rooted in fact, vs something that's intended to be debatable, lots of people won't throw forward the thoughts they have that are only 80% correct - they effectively freeze.

At one company we were reviewing the interview questions we used for graduates, and we had to take one out about a hypothetical factory manufacturing widgets. It was actually a simple maths problem about widgets per hour given various inputs. But the grads would freak out at the word "widget" and derail the interview demanding an explanation of what exactly a widget was, what it was used for, etc etc. I personally thought that that was an excellent filter actually, but I was overruled...

In manufacturing, you use the term "part" for one instance of a unique thing, and "part number" for a class of identical parts. But people who have never been in a factory may not know that.

If we'd have said parts we would have got the same reaction, parts for what? what are they made of? they would have asked. As I say it was meant to be a simple maths problem, but what many of them failed on was what was an even more basic skill of extracting the relevant parts of a sentence.

That's a deep question. Allocating large objects on the stack is usually frowned upon. (Especially in places with small stack limits, such as the Linux kernel.) It's common to allocate just the header for a variable sized object on the stack, but put the bulk data on the "heap". C++ vector classes do this. On-stack variable size arrays were in the C standard for a few years, Microsoft didn't implement them, and they were kicked out of C as a feature. Stack variables are usually live enough that you want the top of the stack in the cache, and big on-stack objects can break that.

Should programmers in interviews know that?