> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.” > Interviewers want to know what’s going on in your thought process. It’s importa

> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.” > Interviewers want to know what’s going on in your thought process. It’s important that they know how you’re making decisions. How are you qualifying or disqualifying ideas? Why are you choosing to implement something in a particular way? Did you spot a potential problem in your code? What was it? That is a very good way to hire people that are good at interviewing or selling themselves, not so much for very good developers. Speaking loudly about every tiny decision you take for simple algorithms is very hard and inefficient. It is even worse when you have a lot of experience, because you just know which designs will be wrong or not without even thinking twice about it. It is okay to expect communication about the overall design, specifications, input, outputs and behavior, not about the algorithm itself. If spoken human languages were efficient at expressing this kind of thoughts patterns, we wouldn't have invented mathematics notation or programming languages. > “I wonder if … hmm … well, I was thinking about implementing this as a depth-first-search, but given a constraint around ___ I think a better approach might be ___, what do you think?” If you have this kind of expectations, you are again hiring people that are good at interviewing, that is all. I have been a developer for 15 years and I don't know how most of the basic algorithms are called in English, because it is not a useful vocabulary in my everyday work. I make specific algorithms to efficiently solve specific problems. I do not blindly copy patterns from Stack overflow or from a book. I would not know what is a "depth-first-search" unless I start searching and looking for some code in Google either.