So, is that really knowing "enough" to avoid the things you mention, or can the heuristic be that you should know the standard library?

There are things built into some standard libraries that are able to be combined in a way that produces a list intersection, but that are O(n^2). I prefer working in high level languages as much as the next person, but there's no substitute for knowing basic algorithms and data structures.

I just demonstrated a substitute for knowing basic algorithms and data structures.

Yes, you just demonstrated an example of a case where a developer is not hurt by not understanding algorithms or runtime complexity.

Here's one where they are: In python, the in operator works on both lists and sets. For one, large numbers of elements will perform very quickly. For the other, it will perform very slowly. If a developer doesn't understand how they work, and where it's appropriate to use each, they can still do something completely terrible without even straying away from basic APIs.

While it seems like you're moving goalposts, this example also appears to be something a person could know without touching on nested loops or O(n) at all.

Case in point, 10s of Googling produced this link: http://stackoverflow.com/questions/2831212/python-sets-vs-li... ...and I don't even use Python yet.

Is it possible to write working code without understanding O()? Definitely.

Is it helpful to understand? Definitely.

Of course, but neither was your point. You were rebutting that algo & bintree knowledge are unnecessary in the vast majority of companies, in favor of the pursuit of O(n) knowledge in candidates. None of your examples validated this, and "should" became merely "helpful."

I suppose I considered it reasonable to consider things that are helpful should be done.