I give live coding tests generally based on the level they claim to be at in the language. It doesn't have to be perfect as I'm more concerned with why they're doing a thing. I usually pick something fairly basic with some edge cases just to see if they mention it.

As opposed to homework, it also proves that you can at least basically work in the language in question (I've had a couple of people who got to my round but seemed to know almost nothing about a language they claimed a lot of experience in (like declaring variables and struct members wrong... seriously). We also caught someone that didn't seem to have done the homework themselves.

If the candidate makes mistakes or gives an imperfect solution, I try to gently guide them to where we need to be. I ask them to explain why they made decisions they did, any edge cases, and how to improve performance or scale it. I expect them to ask questions when something is vague (and usually something in my problem can be interpreted one or two ways for this reason) because these are things they will encounter working with stakeholders and other engineers. If they can't do that live and on-the-fly, they're probably not for us. I fully expect nerves to be a factor and account for that; we're all nervous in interviews.