I ask about time complexity, and all the basics, but it's just a bunch of malarkey. So I spend more time quizzing them about technologies I don't know on their resume and getting something out of it for myself. It's easy enough to tell when someone's full of shit, but asking them to describe the tradeoffs between the technologies they've worked with seems more valuable than watching someone sweat-ily cramming out some crap imperative code for a toy problem and telling me they got it down to nlogn. Oooo ee!
[0]: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
So keys and contacts are both modern revisions.
As much as we like to complain about interviews, the alternatives that more accurately reflect the work environment are much more strongly hated.
One of the most accurate interviewing methods is a work trial: Bring the candidate in for a week and have them work the job. Their peers and managers rate their performance.
It's great for revealing how a person works. But think about what's required: You would have to take a week off of your primary job every time you wanted to interview at another company. A company could only interview one candidate per week.
Some companies try this, but it over-selects for unemployed young people. They either give up or start bending the rules when qualified applicants refuse.
A man, on his hands and knees, searching diligently for something on the ground.
Another man, walking by, stops to help search. After a few moments he asks "what are we searching for?"
The first man replies "My contact lens"
After a minute or two the second man, frustrated, asks "Where did you lose it?"
The first man replies "Way over there, but the light is better under this streetlamp."
Coding interviews kinda feel like that to me. We can't measure what's important, so we'd better measure what we can measure extremely rigorously.