3 ms·

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 re

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-programmers-please-stand-up/ http://www.rethinkdb.com/blog/2010/06/will-the-real-programm...). " Some were shooting their pre-canned answers at me with unreasonable speed." This should not be possible for all questions in a technical interview. Especially if you are a startup, you can use your own original problems, especially ones you've actually had to solve. Aim for actual coding questions though rather than too puzzling ones that are often just memorized (implement quicksort, detect cycle in linked list in O(1) space, the random puzzles companies love to ask). Of the people I've worked with, there is a high correlation to job performance to performance in a tech interview. (which for new grads is strongly correlated to their college CS grades). Of course, passion is also a decent indicator, but it is highly correlated with raw competance. That said, I wouldn't hire anyone lacking either. Disclaimer: I'm coming from the background of a systems company. For those making CRUD apps, tough coding questions might be less relevant.

BrandonM 16y ago
> 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.
utahmadmike 16y ago
Usaar333 - Here’s some food for thought: There is a difference between -capable- and -willing-. Years ago I hired a brilliant developer that didn’t do anything because the work was below him. A good interview should determine culture, willingness, and competence. If your dev-group works with b-trees daily, then include it in the test. For me, hiring someone who knows the answer is less important than hiring someone who can find the answer. In a dynamic - always changing environment - I would rather hire the latter.

BrandonM 16y ago

> 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.

utahmadmike 16y ago

Usaar333 - Here’s some food for thought: There is a difference between -capable- and -willing-. Years ago I hired a brilliant developer that didn’t do anything because the work was below him. A good interview should determine culture, willingness, and competence. If your dev-group works with b-trees daily, then include it in the test. For me, hiring someone who knows the answer is less important than hiring someone who can find the answer. In a dynamic - always changing environment - I would rather hire the latter.