My friend just published this. What everybody think?

I think he is exactly right, it's an awful interview question:

I understand that there is never enough time in a startup. I’ve been on the other side of an interview process a few months ago. But I never took a shortcut. Maybe arrays are the only thing those “brain-dead” people remember from C++ class they took 10 years ago to fulfill their Computer Science degree requirement...

Right on.

Interview questions should be thoughtful, thought-provoking, and relevant to the work we do.

When I'm interviewing, I always ask the first question: "Please pick your favorite project and describe it"

In order to be an engineer on a project, one has to understand it to such level of details, a computer can get it:)

Great number of people, claiming to be experienced, fail to provide a clear picture of the project they choose to discuss. Yes, they give rubber stamp answers or telling about the routine they followed, but not the clear picture of what the project was about, why it was needed, what were the motivation behind technology selection, etc.

If an interviewee can passionately and clearly elaborate the project, this is a good conversation starter into more detailed and technical questions.

Hiring a person, who spent their professional lifetime thinking only about perfecting array search algorithm is the path to gather a group of nerds, not the team of engineers.

What you're really looking for is clarity of thought, and passion for what they do.

Also, someone who is comfortable learning, since every new project has new learning, right?

Adam, it's also about thinking like an engineer. The job of an engineer is not to push the problem to the technical framework of choice (ROR, Node, Spring, etc), not to re-engineer the world, but engineer the framework of abstractions, which helps solving the real problem at hand.

The language, chosen by the interviewee to describe the project, tells me if this thinking process was done or it was all about using the frameworks created by someone else. Did they understand the product and business goals? Did the team established corresponding engineering and design priorities? What were the main set of abstractions?

Here is an example, to me, of a good project description:

http://www.quora.com/Shreyes-Seshasai/Posts/Tech-Talk-webnode2-and-LiveNode

They stated the product priorities, translated these to technical priorities, built necessary abstractions and then described the technical implementation details.

Here is the bad one, to me... http://www.slideshare.net/kvzaustin/asana

No words about asana or the problem they are trying to solve. Just bunch of "technical porn" slides about uber cool framework, which focused mostly on decreasing the amount of code to write and real time sync.

These type of questions are designed to filter out ppl who can't program. The problem is you're often asking a question a developer will never see in the real world, and doing so in a higher stress situation than a developer will likely ever experience while coding.

You will certainly filter out ppl who can't program. You will also filter out ppl with anxiety issues, with asperger's & the autistic, and also many self-taught developers.

In many if not most people, anxiety already shuts down or severely inhibits critical thinking skills, and there are few scenarios in all of creation more anxiety laden than an interview gauntlet. The scenario is entirely artificial and you really don't learn anything except how high this pledge can jump. It is literally and definitionally hazing, not to mention a lazy interviewing technique.

You will learn more from a candidate by having him dig into his past and having him describe a harrowing problem and his creative solution. You will learn more by going out to a group lunch and see how he behaves. You will learn more by giving him a description of your most common real world algo and having him code a simple implementation of it without being under the spotlight.