3 ms·
This post is a good example of why fact based interview questions are not useful. It's how information is gathered and applied which separates the wheat from t
by planetjones 11y ago
This post is a good example of why fact based interview questions are not useful. It's how information is gathered and applied which separates the wheat from the chaff.
Einstein puts it best:
One of Einstein's colleagues asked him for his telephone number one day. Einstein reached for a telephone directory and looked it up. "You don't remember your own number?" the man asked, startled.
"No," Einstein answered. "Why should I memorize something I can so easily get from a book?"
- thesimpsons1022 11y agoanytime I hear an Einstein story I assume it's made up.
- minthd 11y agoWell, he also said that imagination is more important than knowledge...
- danieltillett 11y agoThis is my rule too. I actually use the stronger rule which is anything attributed to anyone famous was not ever said by them.
- AnimalMuppet 11y agoThere's a similar story in "You Must Be Joking, Mr. Feynman". Feynman looked up something on an anatomy chart of a cat. A biologist was ribbing him that he had to look it up. Feynman said, "You mean you spent four years memorizing something I could look up in 15 minutes?"
- copperx 11y agoFeynman was not a medical doctor, I don't understand why he would be teased about not knowing the anatomy of the cat.
- pluma 11y agoReasonable question, but I'm pretty sure the person was just happy there was one thing they knew better than Feynman (who seemingly knows everything else).
- cafard 11y agoAs I recall, it was Feynman giving a presentation in a biology class he was taking, and the biology graduate students saying Yeah, Yeah we know that; Feynman then said that no wonder he could catch up to graduate level if they spent all that time memorizing cat anatomy. And I'm not sure that Feynman had quite the name outside the physics community at that point.
- sixdimensional 11y agoThis... a thousand times this!!! I think it is very reasonable to answer "you know, I don't know the answer but I can find it quickly using [google|man|stackoverflow|a book|etc]" to a technical interview question for which one does not have the exact answer. Of course, being able to find it isn't everything - you also need to be able to understand, evaluate and apply what you find. But it is a step in the right direction, and given the wide scope of what developers/engineers must understand these days, I think a totally reasonable consideration.
- sago 11y agoThat was my first thought today. Faced with a programmer who had to look up how to determine array length, what would you conclude about their skills? I seem to remember a Joel on Software post a while ago that said that deep and specific API knowledge was a must, and I remember disagreeing rather strongly with that too. The last company I ran, we used a programming test in a language the candidates didn't know. It seemed to be a better predictor than the C++ test it replaced. Because it separated knowledge and understanding. I'd rather have people with deep understanding who can offload their knowledge retention burden, than trivia-gurus.
- austinjp 11y agoKnowledge. Understanding. Experience. They all seem necessary for optimal performance. And they all seem different. Yet they all rely on the first: knowledge. At some arbitrary point of abstraction, the ability to manipulate accumulated knowledge becomes understanding. This seems best gained through practical (rather than theoretical) experience. But it's all based on knowledge. Certainly "understanding" appears to be more valuable, as evidenced by examples given here comparing understanding with knowledge. But is that an arbitrary distinction? Is understanding predicated on knowledge? It seems to be. Is practical experience better than theoretical? It feels so. I wonder if the distinctions we draw between these concepts is somewhat arbitrary. I struggle to pinpoint the phase-shift at which accumulated knowledge becomes understanding, and what signifies a collection of knowledge that had failed to become understanding.
- sago 11y ago> I wonder if the distinctions we draw between these concepts is somewhat arbitrary. Yes, that is a feature of all language. But I think I was specific about the knowledge I meant. Namely, deep and specific recall of the API. Contrasted with understanding of a range of ways an API might have been structured or defined that would allow someone to program effectively in an environment they had no experience of. Of course, one can define that as 'knowledge of a range of ways an API might have been defined', but them's language games. Beloved of undergraduate philosophy majors, but pointless beyond that, I'd say. I wasn't making a point about words, but about the way we approach syntactic recall in programming languages as a proxy of programming competence.