[learc83]

Many problems have solutions that were worthy of publication and took a lot longer than 30 minutes for very smart people to solve. So if you don't already know the answer or the answer to a very similar problem then yes objectively they are hard problems.

[milemi]

But you are supposed to know the algorithms and approaches that apply to the problem, that's the whole point. It took humanity tens of thousands of years to come up with the first script, but nobody wants you to invent the English alphabet in an interview, you're expected to know it.

I also can't remember ever being asked to solve a problem whose solution would have merited publication in my lifetime, and I was born around the same time Unix was.

[learc83]

There's a difference between knowing which class of algorithms to use or even which specific algorithm to lookup in a given situation and knowing exactly how to implement the specific pet algorithm of an engineer on a power trip without using reference materials. This kind of adversarial process is nothing more than a hazing ritual. Other industries think we're insane, and the vast majority of companies that do this style of interview just do it because they want to do what Google does not because they have any evidence it works.

>I also can't remember ever being asked to solve a problem whose solution would have merited publication in my lifetime, and I was born around the same time Unix was.

We've had different experiences then. I've definitely had to implement algorithms designed after 1971.

[milemi]

Software is very different from any other type of engineering I can think of, so I'm not surprised that the interviewing processes would be different. Two different aeronautical engineers for example may come up with two different solutions, but I don't think the better one would be better by a factor of ten, let alone something like a million which is common with software. If any aeronautical engineers read this I'd like to be corrected if I'm wrong.

I agree that for GUI work you probably don't need this, but for a back end position I would like a person for whom this kind of interview isn't a big deal to prepare for.

I'm curious to hear what the post 1971 algorithms in question are.

[learc83]

Wow you are really invested in the current interview process. I've never met anyone who defended it quite so vigorously.

Any engineering disciplines that deal with designing processes are very similar to software engineering. It's nowhere special enough to demand a completely unique hiring process.

Even if it were, I'd like to see some hard data to support the current interview best practices.

>I'm curious to hear what the post 1971 algorithms in question are.

Off the top of my head: You've had a question with Red-black trees? B-trees? Quad-trees and oct-trees?

[milemi]

There is no way you were asked to implement any of those in an interview.

[learc83]

For quad-trees and oct-trees--they are fairly common in gaming and not a particularly time consuming to implement.

For Red-Black and B-Trees, I've never heard of anyone being asked to implement the entire thing from scratch, but significant portions sure. Also explaining the implementation of significant portions.

Here's a similar post from 2015 by tptacek

>You're a 55-year old engineer who graduated from school in '81. You're being interviewed by a 24-year old engineer who graduated 2 years ago. You're asked, in an "algorithm interview", to explain some detail of the implementation of an AVL tree.

>In reality, despite the fact that they're covered in CS courses, virtually nobody uses AVL trees in industry. In fact, people barely use balanced binary trees at all, and when they do, they use red-black trees, and they use someone else's implementation, because they're a bear to debug.

>The 24-year old has an advantage with this question because they were recently taught about, and perhaps had to do exercises/homework/tests based on, AVL trees.

>That this happens is stupid, because it's very unlikely that conversance with AVL trees is going to make much of a difference to your on-the-job performance. Almost all the narratives you can come up with about this involve reading tea leaves and are shot down easily by better selection/hiring/interviewing techniques that answer questions more directly.

>This line of questioning can go too far; I don't, for instance, think knowing the big-O characteristics of an AVL tree is unreasonable (it's a balanced binary tree, and you should have the complexity of operations on those in resident set throughout your career).

Here's another coment from tptacek in the same thread. If you don't know who he is--you definitely want to hire him if you can. Him failing out of your hiring process would be a travesty.

>I was asked to do Bellman-Ford. I bombed that question, and was so shaken that I bombed the rest of the interview as well.

>The irony was, I'd just spent the preceding 2 years writing multicast link-state routing code. I could have coded a decent C++ Bellman-Ford in a couple hours, but couldn't pull it out of my head on the spot in an interview without babbling. (I tried to dodge by describing link-state LSP forwarding and then Djikstra, but wasn't given credit for knowing the more sophisticated algorithm).

>Algorithm interviews suck. We should stop doing them entirely.