I agree that there are many reasons why someone can "fail" a technical interview (I wrote about some of them here[0]). It's just as important "how" you solve the problem and that you come off as someone people will want to work with.

[0] http://reginaldlong.com/i-failed-my-tech-interview-and-i-don...

Neither of which can be solved by 'studying' for an interview. I'll argue that the required skills are on the interviewer, not the interviewee. As an interviewer I'm trying to assess a skillset, be it social, be it technical. All the points you listed (except #5) I deem to be a failure on the part of the interviewer:

1. You didn't make enough progress on the problem.

The interviewer didn't properly explain the scope of the problem.

2. You were too slow and didn't get through all of the problems.

Again, a scoping issue on the interviewer's part. When I interview, I have one _single_ problem that I pose. I interview largely for embedded security folks, so I write this on the board:

void func(char* arg) { char buf[128]; strcpy(buf, arg); }

And I will ask them to explain what's wrong with it. Most people can answer that question fairly easily. With this simple problem on the table I now have a base to start more questions from:

- How would you fix this problem? - In a large codebase, how would you find this problem? - What's really happening here on a machine level? - What sort of system-level mitigations can I implement?

These are all branches I can take, and once I feel like the interviewee is out of his depth in any one of them I jump back up. I'm trying to assess the skill-level of the person, not whether they meet some minimum bar (though I can do this afterwards, of course).

3. Your solution is complicated.

There's a little bit of shared blame here. The playing-field isn't level in an interview as the interviewee is naturally going to be nervous. You as an interviewer can help level it a little by giving some broad strokes help. "That solution looks like it might end up a little complicated. Do you think there's a better one?". I have given no technical guidance, but have given the interviewee a chance to step back and think.

4. You didn't communicate well enough with the interviewer

Everyone works differently. When I'm solving a problem, I like being alone in my head to focus. Some people more naturally are drawn towards collaborative problem solving. An interviewer that doesn't recognize this is a poor interviewer.

You as the interviewer can solve the problem by occasionally asking "So, what direction are you thinking?" or "Can you write me out on the whiteboard where you're going?".

5. You ignored the interviewer's feedback

Yeah, ok, that one is on you.

There is a wide disparity between "embedded" type software dev interviews and "crud" type software interviews. Amazon, Google, FB are CRUD type. Their interviews are exclusively Algos and data struct memorization and slapping perfect code on the whiteboard in 20 mins.

> void func(char* arg) { char buf[128]; strcpy(buf, arg); }

I'd much rather solve this one - and talk about maintaining legacy systems, than any of the other interviews I've done.

I'll be honest with you, I've conducted some attrocious interviews. It's taken me a long time, and a LOT of interviews, to get to the point where I feel like I'm not horribly butchering them most of the time.

I found that I really like the "pick one problem/question and go deep and/or wide" approach. The above example I can go anywhere from compilers (Q: "What's the smallest function a compiler could legally output given this code?" (I love this one :P)) to C (Q: "How is 'buf' allocated?") to static analysis (Q: "How would I statically find all instances of this pattern?") to exploits (Q: "How would I exploit this vulnerability?") to mitigations (Q: "Given a stack overflow, what can I do to make it harder to exploit for the attacker?"), etc. etc. etc.

Out of curiosity, were your interviewers largely young? 20-28 years old?

Most of my interviewers were between 20-30s, but I've also interviewed with people old enough to be my parents.

That still leaves more than a few decades worth of an active programming lifespan out. Assuming you're in your early 20's, your parents are likely in their early 40's; retirement age is still in the late 60's.

It's a young field, there will be more and more people who code into their 70's and 80's as the first batch of gen-X matures.

This was good from the discussion you linked:

As a counter anecdote, I had someone tell me they did an interview loop where the guy interviewing had social anxiety problems so he would talk to a hand puppet instead of the interviewer. He got all the technical questions correct and was hired, apparently, so there's that.

Sure, but just as these big tech companies have processes that's optimize for removing false positives, candidates end up having to study for interviews to optimize for being excluded as such.

Can you elaborate on how the ideas(essentially treating interviewing as a skill) in the blog post exhibit post hoc fallacy?

"I got a tech job after doing these things, therefore these things helped me get the tech job."

There is a lot more nuance to tech job interviewing (including luck that you got a good interviewer/interviewer was not in a bad mood), despite the changing landscape which emphasizes trick coding.

post hoc, ergo propter hoc :)

I hate using the Latin name of logical fallacies since it tends to lead comment threads into ad absurdum flamewars. :P

Mildly relevant: http://www.smbc-comics.com/comic/citations-needed

Why? Maybe I'm just a logic nerd, but I see no harm in using Latin terms wherever appropriate.

For whatever it's worth, I appreciated his use of English. In this case I don't think I would have had trouble parsing 'post hoc ergo propter hoc', but about half the time when someone uses the Latin phrase for a logical fallacy (or other concept) I have to look it up to make sure I haven't misremembered its meaning. Trivial inconvenience, sure, but multiply that by everyone else in the same boat and surely it outweighs the extra effort/space taken to type out a slightly longer, easily understandable English version.