> One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of som

> One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea. > These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs. Then the questions should be more like: What data structure, library, method, steps, would you use to solve this problem and why. What are the tradeoffs of your choices, etc? All of this can be answered in fairly high level pseudocode too and still show that they understand the concepts etc.