5 ms·

Perhaps - but this is why trick questions are terrible in interviews. They tend to be around trivia, and encourage people to guess at a response. If you want

Perhaps - but this is why trick questions are terrible in interviews. They tend to be around trivia, and encourage people to guess at a response. If you want to test someone on whether they can admit they don't know, just ask increasingly tough questions and see how they handle it.

MichaelCrawford 11y ago
Over the summer of 1986, I wrote a large chunk of a Common LISP interpreter. That fall I applied for a software engineering job at Microport, a UNIX SystemV vendor. Chuck Hickey, the president, asked me to write down the fastest possible implementation of strcpy(). Honestly, I had no clue. I wound up with a six dollar per hour telephone technical support job. This despite that at my previous job, I designed then - in one long night - flawlessly implemented the Common LISP symbol scoping rules, as specified in Guy Steele's book of the same name. This leads me to assert that it would be more productive to challenge applicants, during interviews, to write some of the same kind of code that their resumes claim they have previously written. At that LISP job, we were not concerned with performance, rather we were concerned with complying to the Common LISP specification. My resume doesn't make the claim that I studied computer science. It is quite clear that I have a BA in Physics from UC Santa Cruz, that I majored at first in Astronomy then changed to Physics at Caltech, and that I attended grad school in Physics at UCSC. Despite that it is quite common for interviewers to ask me questions that only those with graduate CS degrees would have any clue about. This finally lead me to pointing out, well before the interview, that I regard myself as a Software Engineer and not a Computer Scientist. The two, while conceptually related, in reality are quite different. Consider that a mathematician can derive the catenary curve by solving a differential equation, while a civil engineer is the reason that the Golden Gate Bridge isn't likely to collapse anytime soon.

MichaelCrawford 11y ago

Over the summer of 1986, I wrote a large chunk of a Common LISP interpreter. That fall I applied for a software engineering job at Microport, a UNIX SystemV vendor. Chuck Hickey, the president, asked me to write down the fastest possible implementation of strcpy(). Honestly, I had no clue. I wound up with a six dollar per hour telephone technical support job. This despite that at my previous job, I designed then - in one long night - flawlessly implemented the Common LISP symbol scoping rules, as specified in Guy Steele's book of the same name. This leads me to assert that it would be more productive to challenge applicants, during interviews, to write some of the same kind of code that their resumes claim they have previously written. At that LISP job, we were not concerned with performance, rather we were concerned with complying to the Common LISP specification. My resume doesn't make the claim that I studied computer science. It is quite clear that I have a BA in Physics from UC Santa Cruz, that I majored at first in Astronomy then changed to Physics at Caltech, and that I attended grad school in Physics at UCSC. Despite that it is quite common for interviewers to ask me questions that only those with graduate CS degrees would have any clue about. This finally lead me to pointing out, well before the interview, that I regard myself as a Software Engineer and not a Computer Scientist. The two, while conceptually related, in reality are quite different. Consider that a mathematician can derive the catenary curve by solving a differential equation, while a civil engineer is the reason that the Golden Gate Bridge isn't likely to collapse anytime soon.