I can understand your complaint here, and I agree with you that people can easily go too far in the direction of 'when to implement' versus 'how to implement'—b

I can understand your complaint here, and I agree with you that people can easily go too far in the direction of 'when to implement' versus 'how to implement'—but I'm pretty sure the key is (1) Both are required, (2) it makes more sense for one of these things to precede the other. However, I think that you’re also conflating two approaches to learning ‘context.’ One gives people an elaborate index for finding implementations when required, so that they become capable ‘solution googlers.’ This is unquestionably an inadequate approach to education. However, there is another approach to context which emphasizes principles. ‘Principles’ can be a vague word itself, but I’ll try to be more precise about it: you have understood something ‘by principles’ when you first understood a more general structure, then, in order to learn the more particular thing, you understood which parameters must be supplied to the more general structure in order to get the more particular one. E.g., you learn principles of programming languages first, then can understand new languages as parameterizations of your prior, more general knowledge. I think the context material in ADM serves as a nice guide for acquiring principles in this sense. The bit I quoted is largely significant because of their emphasis on principles. It’s interesting that you think ADM would be the book for faking an interview. I have the exact opposite stance. If I wanted to impress a typical software person (e.g. a yet to be determined interviewer), I’d learn a lot of the details from CLRS, rather than going for ADM.