For context here, I'm a college dropout. I made it through two years before I discovered that I could skip right to having a job, and for where I was in life, it was the right decision for me. But seriously, what's the deal with this hatred of "Big O" notation?
This isn't some cryptic language only for use by CS PhDs. It's not even a concept that's hard to explain to someone who isn't in our industry!
"The question we're trying to answer here is, how does our solution scale as the problem gets bigger? Are we able to solve it in the same amount of time regardless of size? Does our solution take more time as the problem gets bigger, but only in proportion to how much bigger the problem is? Or does our solution take much, much longer as the problem gets bigger, to the point where it's no longer feasible to solve?"
Asking a candidate to be able to have a conversation about this -- how do time and space complexity scale -- is not unreasonable. This is the difference between designing a workable solution early, and discovering that what worked great in a unit test and some one offs behind the scenes fell over in production.
Similarly, I see no problem in expecting a candidate to have some familiarity with the basics of simple data structures. I don't generally rewrite them either! But I use data structures all the time, exposed to me via the standard libraries of programming languages that I use, and if I don't broadly understand how they work, when they are appropriate and when they're not, and when one choice is superior to another, I'm not doing my job.
I agree that in a lot of instances, Google is the answer. But Google is of no help if you don't know what to ask, or worse, if you don't even understand that there's a question to ask.
I'm not defending the truly awful interviews that I believe really do happen. But let's not pretend that it's not important to understand how these details work to get proficient, or even adequate, at our jobs.