Hacker News Reader

Comment by fragmede | Hacker News Reader

I'm surprised at this list of questions. Didn't everyone get the memo that "brainteasers are a complete waste of time?" from a year and a half ago?

http://techcrunch.com/2013/06/22/the-technical-interview-is-...

View on HN

I didn't see much that qualifies as a "Brain Teaser" - most of these are algorithmic questions. Knowing when do implement a depth first search != brain teaser.

Actually a crapload of efficient algorithms are applications of "clever" tricks. They're not necessarily intuitive, and the people that can recite them in interviews have very often already seen the solution (or the same general pattern applied to a similar problem). In that sense, they are very much like brain teasers.

If every programmer should be able to construct complex algorithms from first principles in a 10 minute window under the pressure of an interview, we wouldn't have so many algorithms named after the people who discovered them.

I don't follow your argument. Candidates for a lot of software engineering roles are expected to know a certain selection of fundamental algorithms, including things like DFS and Dijkstra's. The companies I have interviewed at have been very clear about what is expected knowledge. I don't see how this is at all relevant to being able to construct it from first principles. That's the whole reason you're expected to know it!

If you're talking about "tricks" like the tortoise and the hare solution to detecting if a graph has a cycle, then sure, I can get behind that. However, there is a base of algorithmic knowledge that you are expected to know, and it is entirely irrelevant whether or not you can construct it from scratch.

Ok but the question is why are some of these questions even considered the 'base' level of knowledge for interviews? At least on the front end side we still ask about these algorithms even though binary search trees and Djikstra's have almost no application in our work.

The reason for these questions being considered 'fundamental' seems totally contrived, and that's that everyone studied them in their CS program, not necessarily because that's the kind of knowledge you apply day to day.

Graph traversal is quite relevant to DOM manipulation. More generally, these sorts of "classical" problems come up more than one would assume at first glance.

I believe that understanding the theoretical backing is very important for making correct software design choices, at least at the positions I have held. Moreover, this base knowledge is a proxy for general awareness of complexity analysis and architectural trade-offs (why do we pick this structure over that?). I agree that we needn't consider single-source shortest paths every day when programming, but for companies that want to be sure they are making good hiring choices, this seems reasonable to me. Graphs, for example, come up so often in practice, which is why I refer to them as fundamental. It's not like we're talking about red-black trees here. Again, it's a proxy for one part of what makes a great programmer.

If you wrote code that requires graph traversal in DOM, you are doing it wrong.

Well, "a lot of software engineering roles" have requirements and knowledge expectations that are far out of line with what the job actually requires. There are some "fundamental algorithms, including things like DFS and Dijkstra's" that simply aren't applicable to a lot of software engineering roles, big and small.

Most of the questions and interview ceremony around these things, especially for the aforementioned positions for which they're largely irrelevant, are exercises in hazing, ego building/busting (depending on which side of the interview you're on), and petty power plays.

Reply on news.ycombinator.com