Every single interview I've been at was just like that. I remember one guy asked me "do you even write unit tests?" to which I gave up and honestly answered "why are you even implying that I don't?". This was one of the first questions and the dude had absolutely no ground for phrasing his question this way. For god's sake, ask me about my favorite book, or about my favorite computer scientist, or about my favorite programming language - there is so much you can talk about figuring out what kind of an engineer I am.

A typical programming interview is a sham: an interviewee googles questions and an interviewer googles answers, and the job offer comes as a positive probability of them googling the same thing.

And the most ridiculous thing of all, is that more often than not, after drilling you on various hashing techniques and optimizing tricky algorithms in space and time and quick-sorting bible on a whiteboard, they'll assign you to a high-school level job - pushing SQL statements and HTMLizing the output, web 2.0 style. Yikes.

For how aggressive some interviewers are, I believe half of that aggression comes from the interviewee. If they start with some passive-aggressive questions and you get defensive then you're just as much a barrier to communication as them. When you read someone else's answer to an interview question and are struck by how well they answered it is rarely because they had a witty answer that stunned the interviewer, but rather that they were open, honest, and entirely non-aggressive and so were able to show how smart they really were.

Who wants an employee who never questions the requirements?

I can't think of a better way to end up in project management failure than to start writing a solution to a problem you don't understand.

(1) Sure, the problem was somewhat unrealistic/simplified. It's just an interview question; you're not being asked to actually build the damn thing, just sketch how you'd build what the interviewer is asking you to implement.

(2) Making an initial observation about the difficulty of actually assessing frequency of word usage is great and probably better than just talking about implementation techniques, but the interviewee kept coming back to it, even when the interviewer wanted to move on. That is just obnoxious.

When you know what your assumptions about a problem are then it quickly becomes clear what questions you'd have to ask if you were going to actually implement your solution. Having a solid definition of your assumptions also lets you create a good base for building a solution and determining if it is at all feasible.

More than you might imagine.

Think of all the people you've worked with, in whatever capacity, who never question requirements. It seems likely they will hire people of the same sort, not just because they might have a bias toward the "good" employee being subservient, but because someone who questions the requirements to them will inevitably want them to question the requirements to their superior. They've already spent their career up to this point avoiding this, it seems unlikely they'll take some action now that prevents it.

Based on a metric of producing code that fulfills the requirements, they may be as much an A player as the assertive developer down the hall. The thought of including assertiveness in measuring employee performance has never occurred to them. You say to them that only "A" players hire equally capable people, but they respond by saying that they are an "A" player. It is the start of an unreasonable argument.

Perhaps they should hire for assertiveness, but that's a matter of convincing people that their method of analysis is wrong. That doesn't get solved with platitudes; it gets solved by showing that encouraging assertiveness provide more value that the security of the status quo. How to show this, though, is something I am still trying to figure out.