This post is the other side of the coin: older programmers think that when they entered the industry it was "the golden era", and everything since then has gone downhill. This is akin to someone in the late '90s asking all entry-level programmers "you mean, you don't regularly disassemble your object code to verify that the compiler did the right thing? What's wrong with you, why are you relying on your tools so much?"
The fundamental issue is that the industry is maturing, but the names of the positions for which you are hiring hadn't quite kept up with what you are looking for. People whose primary job is to make sure that data gets from the database to HTML and back really don't need to know what is under the covers. This position is called "product programmer". Their job is to translate whatever your UX guy cooked up into things that actually work. If you then need to make sure that whatever they made scales up to thousands of requests, you need to have a different person called a "performance developer" - these people really hate translating UX wireframes into code, but once that part is done, they can optimize everything up and down the stack with their eyes closed.
Also, this is a personal pet peeve of mine: if you are asking what a singleton is in a job interview, you are interviewing for the wrong thing, so no wonder you are getting the wrong interviewees.
It means you can do both UI and server code, so you have a wide variety of knowledge in the many competing front-end and back-end frameworks out there, but you are not quite an expert in anything. At your last job you learned all the magic incantations of jQuery, Rails and MySQL, but but today you are expected to learn all the magic incantations of React, Node and Mongo. Specifically because you are expected to change your toolkit quickly, you do not dedicate any time to scratching the surface.
Certainly when hiring for "back-end developer", I expect deep knowledge of OS- and DB-level concepts like indexing and garbage collection.
Likewise, when hiring a "front-end developer", I expect deep knowledge of various mobile, desktop and tablet devices and the behavior various browsers exhibit on them.
Things like get vs post, encoding, basic headers (like accept etc) should be familiar to anyone dealing with the client side development regardless of the tools/frameworks.
And then on the backend some basic SQL, basic understanding of indexing, FKs, PKs, maybe simple inner joins is also something that someone doing anything DB-related on the backend should be familiar with (unless we're talking someone who is only familiar with nosql dbs) regardless of the tools/frameworks/orm etc.
I have to agree.
The database indexing "how" also seems to fall into this; Maybe you understand what the limitations of the decision are, but even this is moving more into Architect or DBA roles.