For some, it could be anxiety. I sometimes choke on really simple questions in interviews that I know I could easily answer if I were home alone. I have anxiety issues in general, though.

I think it's also important that sometimes it can be misunderstanding the question.

I know it sounds silly because it's written clearly here, but in a spoken interview it's possible an interviewee can miss a detail and suddenly think they're faced with travelling salesmen. Or are worried about I/O

Of course in those situations, the "right" thing to do is ask for clarification, or think out loud. And an interviewer should make sure the interviewee is solving the right question (in the real world, people help each other).

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?

Never-ending projects that never deliver, and management that never looks at the code. Also, cheating your way through college - which is basically a requirement for a lot of programs that offer a vertical learning curve, programs spoiled by the fact that many of the people who take a CS program have been hobbyist programmers for years.

After the second semester, CS students divide into three groups:

1) stressed out hobbyist programmers having their mind blown by the complexity of what they're learning,

2) people with no programming experience failing to learn to program (because the intro courses don't actually have any lectures about the basics of programming) and switching majors to business or engineering (because they've already taken calculus), and

3) other previous non-programmers who are copying other students' work or googled answers from the internet.

Type 3) eventually graduate, get jobs based on having the degree, and never finish a project in a programming role by utilizing a combination of charm, excuses, and transferring between jobs before they have to show their work. If they can paula = "Brilliant"[1] long enough, they can get into management before they are exposed.

So many of the people I did CS with never even learned basic programming skills before they got their diploma. This is at a major state university with a very well-regarded program.

[1] http://thedailywtf.com/Articles/The_Brillant_Paula_Bean

Haha, the longer I stay in the software biz, the more I believe paula = "Brillant" to be a true story. The sad thing is, that there are tons of talented programmers out there who actually know what they are doing, getting rejected interview after interview because of "culture fit", while charlatans like paula BS and charm their way into job after job, trashing their projects and moving on to the next one as soon as their ruse is about to be uncovered.

Chalk it up to yet more evidence of how tech interviewing/hiring is utterly broken.

ive been paula in 2 jobs recently....unintentially. i specificaly asked if they wanted to give me a hard technical interview....both greatly objected including one who said they trusted me despite only having 1 year or programming experience....for a six figure senior lead roll.

Both seemed to really liked hiring odd canidates but were no slouches on coding.

Your comment is bullshit. Some of the best people I've worked with, both in and out of college, didn't even begin programming until taking their first CS course in college. No cheating or adderall involved.

You aren't doomed or damaged if you haven't programmed before hitting college. Claiming that is slandering a generation of engineers.

I'm criticizing a lot of CS programs, not programmers who didn't program before college. There are plenty of good programmers who never attended college for computers at all. My own mother started programming after majoring in English in college, learning in a training program at her job in her mid-20s (because she wanted to move out of a management track.) She went on to a 40 year career, and inspired me to become a programmer.

I can see why my comment could be seen as slandering all non-hobbyist programmers rather than programs that don't bother to teach programming because they expect you to already know when you arrive, but you would probably have to skip the second sentence of the first paragraph, and the first parenthetical in item 2).

Thanks for the rage, though.

Again, I watched people graduate who couldn't fizzbuzz. They got jobs, and they still couldn't fizzbuzz. These were friends, who I liked very much as people, and I'm as happy that they got good jobs as I am sure that anybody who hired them should be fired.

> but you would probably have to skip the second sentence of the first paragraph, and the first parenthetical in item 2

No, I think you're just poor at communicating. Your claim was "After the second semester, CS students divide into three groups", and then listed those three groups, zero of which involved a person who was new to programming doing well. You had every opportunity to hedge your statement, and you did not.

Because I intentionally excluded that category, under the qualification that I was talking about programs with a vertical learning curve, that also had intros to programming that didn't actually have lectures about programming. You clearly read those words, so the problem is either reading comprehension or being intentionally obtuse.

They're called "weeder" classes, and probably every CS department has them. You take your intro classes then they dump you into algorithms.

My colleague theorizes that many of the developers that we're interviewing with 12 years of experience actually have the same year of experience 12 times. That is, they move from job to job after 12 months and do the same stuff again and again without any kind of growth.

It's common with people that have only done green field work. They learn all sorts of cargo cult practices but aren't their long enough to learn their lesson.

People that have worked in brown fields are often selected out by recruiters because they think it's harder to build a system than to maintain one.