Nowadays when I interview people, I try and come up with an example that feels like a "real" problem you'd realistically solve on the job, but isn't too hard, usually something involving building an index or some basic concurrency. It's still not perfect, but I do work pretty hard to try and make the problems feel fair and actually something you'd do on the job. I also generally don't concern myself with compiler/syntax errors unless they're extremely egregious, since I think those errors can typically be explained by nerves and realistically won't be much of a blocker in a real job.

I really hate the contrived problems that interviewers pull from HackerRank and its ilk. Even if you could glean useful information from watching someone program a knight hopping around a phone dial pad (a real problem I've gotten, which I'm highly skeptical of its utility), it comes off as pretty irritating to the interviewee. You're not solving little programming riddles on day to day work, you're solving engineering problems, and I think that these leetcode questions don't reflect that.

I think there's evidence of this too; you can study for these leetcode questions and get better at them, so what exactly are we testing? You're not testing the person's experience, you're testing how long they spent on hackerrank the night before, or how many interviews they had recently.