> I have to disagree about the uselessness of a technical interview. I'm 100% with RethinkDB that any competent programmer should be able to figure out how to r

> I have to disagree about the uselessness of a technical interview. I'm 100% with RethinkDB that any competent programmer should be able to figure out how to reverse a singly-linked list in some reasonable time. (http://www.rethinkdb.com/blog/2010/06/will-the-real-programm... http://www.rethinkdb.com/blog/2010/06/will-the-real-programm...). I had the initial phone interview with RethinkDB and they were asking me questions about what is a B tree and how to use them to implement a filesystem/database, what is the pros and cons of structure A vs. structure B, etc. I understand wanting the best of the best, people who have implemented filesystems before, etc., but I think it's pretty unrealistic to expect someone three years out of college who has not been working in the same area of specialization to just know this stuff off the top of his head. Wouldn't it be much more realistic to basically give someone the Wikipedia entry for various data structures, tell them something about the data and workflows, and then ask which structure(s) they would use and why? After that interview, I was sure I wasn't getting the job, but I wasn't very upset. They seemed to have unreasonably high expectations, and that's not exactly the most healthy work environment.