[mbrumlow]

Maybe, or maybe they are missing out.

Binary-tree traversing is a rote memory sort of thing. Somebody who can come in and play 20 questions about an algorithm and answer them perfectly shows me nothing other than they studied that algorithm and have a good memory. It does not show me any insight into how they solve problems which have not already been solved for them. It won't show me how they do under stress with a completely open ended question.

I don't work at google so I won't speak to their daily work, but very rarely should you be writing your own binary tree or traversal code. If you should find yourself on that task you hopefully won't be doing it from memory / without reference because unless that is the ONE thing you know like the back of your hand, even then you are likely going to make mistakes.

I also feel that anybody who has actually been productive on a large successful project does not have time to commit to learning things that can be looked up when needed. There has only been a few times that I have actually needed to implement any of these algorithms in the last 10 years. Of those they were very low level and implemented in a kernel driver where libraries are not so abundant. Can I remember all the fine details today? No. Did I make a system that runs on hundreds of thousands of linux systems across the world? Yes. If I were interviewed on the fine details of implementing some of these algorithms and data structures would I pass? Not likely. Does this make me a bad programmer? Depends who you ask. If you ask the guy interviewing me Yes. If you ask my boss and the many customers who use my product No.

Memorizing algorithms does not make you a good programmer. Knowing how to apply and when to apply them does. The hard part was done when the algorithm was created, not regurgitating an implementation.

Now you might say hey, they should at least know binary tree! Sure maybe they should have some knowledge of it, but there will always be some algorithm you don't know. I would feel completely different if Google said "Come ready to talk about these 5 algorithms and maybe implement one or two". That falls inline fairly well with the author of the article. At least then somebody can say, "Hey, I don't have time", or "Sorry, not interested". And both sides can have their expectations insync.

Now don't get me wrong. We are talking about Google and Amazon. So yeah, somebody there might need to know something about these algorithms. But I doubt they all do. The Few interviews I have been on at these organizations I was not even convinced that all the people interviewing me would be able to pass the round of 5 had they interviewed each other. I should note not all the people who interviewed me gave me that impression. I did meet some really nice people that I thought I would enjoy working with.

I also don't think that these companies don't take into account that some people just interview badly. There is a lot of stress involved. While I think people should be able to work unders stress, I think the type of stress these interviews cause is something entirely different. I live a fairly stress free and carefree life. But when I went to interview at Google my stress levels were so high that I felt sick and worn out for days after. What I am getting at is I am presented with hard problems and short deadlines daily at work. Not once did any of those challenges cause me any level of stress. On the other hand trying to figure out what the interviewer really was asking and cramming to memorize algorithms caused so much stress I did not sleep for days days before the interview. It's not that I was up studying, its that my mind was racing and I could not sleep if I wanted. I just lied there in bed staring at the ceiling. I think they call that anxiety.

> Interview process: complete success.

It was a failure because they wasted everybody's time. Had they been more upfront on what they were looking for then he could have declined without costing both the company money, and him time and stress.

[Apocryphon]

I would feel completely different if Google said "Come ready to talk about these 5 algorithms and maybe implement one or two".

Very good point. The amount of memorization involved in the process is excessive. It'd be helpful if each candidate was told what subset of all possible problems they should focus on.

[stcredzero]

Binary-tree traversing is a rote memory sort of thing.

But the real value is in being able to analyze an application's performance and deal with concepts like recursion.

I also feel that anybody who has actually been productive on a large successful project does not have time to commit to learning things that can be looked up when needed.

Some important concepts aren't the kind of thing that you "look up" then read a one paragraph blurb for 3 seconds. The pitfalls of concurrency and the pitfalls that ACID transactions are supposed to protect against are two more examples.

[mbrumlow]

> But the real value is in being able to analyze an application's performance and deal with concepts like recursion.

Implementing a delete on a binary search tree or traversing one has nothing to do with analyzing performance. If you want to ask questions that require recursion don't make them dependent on algorithms that require rote memorization. Or at least have a alternative recursion question if the candidate says - "Sorry, I don't remember all the rules for this algorithm". Or even be ready as a interviewer to go over how said algorithm works and see if the candidate picks up quickly. If you wanted to really talk about performance then you can talk about WHEN to use a given algorithm and WHY. You don't want to ask questions that there literally is ONE (maybe two) answer that are correct. You don't want to ask questions that when asked WHY the answer "is because that is how the algorithm dictates it." You want to ask questions that are open for interpretation that you then can ask the candidate why they chose that solution. This gives you much more information.

> Some important concepts aren't the kind of thing that you "look up" then read a one paragraph blurb for 3 seconds. The pitfalls of concurrency and the pitfalls that ACID transactions are supposed to protect against are two more examples.

Let's not conflate algorithm implementation from rote memory with not wanting to answer any technical questions. You can't just come in and start talking about ACID transactions and concurrency as if that is what people have been objecting to. Those are valid topics and I doubt most people would have any qualms talking about them. As those are concepts, not rote memorization. You have to have a good understanding of the problems to know where the pitfalls are and know how to spot them. Implementing a algorithm rally covers higher level concepts other than simply regurgitating something like "traverse the left subtree of the root node, accessing the node itself, then recursively traverse the right subtree of the node ....".

I think what most people are suggesting is that there is too high of a penalty on not being exposed to a given algorithm. It is not that these people incapable understanding the algorithm or even implementing one. They simply don't remember. I think this is because a large number of people working at google are fresh out of school. They literally have no experience other than the rote memory required to pass their classes (yes, I simplified that a bit).

I will say that I did find a correlation to the age of the interviewer and the type of question asked. The older 30+ and 50+ guys that interviewed me asked practical questions not related to a specific algorithm. The youngest interviewer I had was a complete hothead and started out the interview saying "he was not your normal interviewer so he was going to ask the hard questions" Then proceeded to ask me a rote memory question about a algorithm. Either I had knew it and memorize it or not. That is not a hard question. The hard question have nothing to do with a defined algorithm. They are often open ended and leave lots of rope for you to hang yourself.

[stcredzero]

If you want to ask questions that require recursion don't make them dependent on algorithms that require rote memorization.

Yes, surely! Have the algorithm explained, or even diagrammed for them with pseudocode.

Let's not conflate algorithm implementation from rote memory with not wanting to answer any technical questions. You can't just come in and start talking about ACID transactions and concurrency as if that is what people have been objecting to.

Let's not conflate the need for a good background with rote memory. I object to rote memory being rewarded by interview questions. I also object to programmers who maintain they don't need to know any of this stuff at all, because they can just Google it and spend a few seconds reading the Wikipedia article. Where in the Dickens did you get the idea I'm Captain Rote-man?

One purpose of training in a highly skilled field is to teach people how to avoid the egregious gotchas. Go ahead and read my other comments in this thread and on this site. I'm not the all conquering champion of rote memorization you seem to think I am.

[mbrumlow]

My apologies. I must misinterpreted your reply.

If I read them in a different mindset then i can take them as a complement to what I said. That knowing how to analyze application performance and concepts like recursion are more important than rote memory. And that interviews should focus on things that can't be ""look up" then read a one paragraph blurb for 3 seconds". I can fully agree to that.

Once again, I am sorry I misread your reply and dumped a wall of text on you.

[stcredzero]

You might enjoy this Feynman story:

http://v.cx/2010/04/feynman-brazil-education

[mbrumlow]

Thanks for this. I did enjoy it and it!