Everyone thinks they're better at interviewing than they are. They often have a survivorship bias. In clueful companies, it's not that dead weight doesn't get hired. It just gets washed out. Interviewers tend to remember the people they end up working alongside.
There are dev questions that are harder to study for. They tend to be open ended. A few of my favorites:
* Describe some code that tends to follow you from project to project (I mostly interview C devs, so I tend to ask this as, "what's in libyou.a?"). What's in your bag of utility functions?
* What's the worst library you've ever worked with and why did you hate it?
* Estimate the amount of time it will take you to complete system X. Drill down, both by forcing the candidate to specify components (do an informal design exercise) and then cost each of those components. Estimation is an extremely important skill regardless.
* What's a piece of functionality that tends to crop up on lots of projects that you'd never implement yourself if you had the option of using a library? (Usually, I'm trying to get C programmers to tell me that they would not in fact hand-hack doubly linked lists out of structs with nested struct pointers).
* Describe the last system you contributed significantly to; how did those contributions break down structurally (did you write libraries for X, Y, Z; did you write plugins for X, Y, Z; did you extend the engine in X, Y, Z ways). Now describe the trickiest bug you ran into on that project.
For C devs, I always used to ask, "You're testing a component you just wrote and finding that it crashes in malloc. Diagnose the problem." This is less relevant now, but there are probably surgical questions you can ask e.g. a Python dev that verify that they actually have the experience of working professionally in the language.