If you are asking interview questions that has one beautiful precise answer, you are doing it wrong. Good interview question should start with something very simple that even very beginner can think and answer, then gradually add complexity and constraints little by little.
Example:
1. Write function that multiplies two integers.
2. What if these numbers were real numbers but computer can only operate on integers? How do we use same number of bytes as ints to hold a real number?
3. What if I wanted infinite precision? What would be run time of your algorithm and storage complexity? (don't insist that candidate must hit the known optimal).
4. Can I have complex numbers as well?
5. Imagine complex numbers not only has "i" but also "j" and "k". How do we handle this?
It is astonishing how many candidates won't be able to move past #2.
The key is to look at how candidate approaches handling complexity, create representations and use it to craft clean solutions. Whether they eventually arrive at known optimal/great answers is unimportant.
Above example is not a test of your programming skills. May be you are great NodeJS ninja who doesn't need to care about any of this. I think there is two types of hiring that often happens (1) for a specific project, specific task (2) long term member of the mission that company has.
For #2, I prefer to hire people who are generalist problem solvers. They need very strong coding skills but more than that they need to be able to operate in new domains easily and adapt. If I was running a startup, I would need them to work on MySQL database one day and react-native stuff other day and perhaps also pick up some of deep learning practitioner skills two months down the line. Above example question doesn't expect candidate to be familiar with floating point representation but it is interesting to see what they might have thought if they were the ones doing it. Assuming everyone works with numbers all the time, people are hopefully familiar with basic issues of precision, rounding etc.
There's not one kind of programmer. You may not be good at algorithms, theory of computation or numeracy. There are huge swaths of important work that don't include these attributes. But there are also many that do. And for those, you may be unqualified as this is not a particularly challenging or deep question for this branch of our field.
I would ask them to propose one that they think is satisfactory. Interviews shouldn't be game of secret answers that one is out for hunt. There shouldn't be any adversarial component in interviews. I often imagine candidate as 1-person startup who discovered this problem, perhaps not in very polished well defined form. As an interviewers I'm just thin air in his room observing the process of polishing, thinking and solving :).
I agree that "read my mind" is a terrible form of interview. One issue with the "let the candidate guide the conversation" approach as you are outlining here is that it is very very time consuming to train new people to administer this kind of evaluation in a repeatable, fair way. Giving the full definition helps the evaluation move along a bit faster, too. Then, it does not create an opportunity for evaluating "how do they explore the problem?"
Example:
1. Write function that multiplies two integers.
2. What if these numbers were real numbers but computer can only operate on integers? How do we use same number of bytes as ints to hold a real number?
3. What if I wanted infinite precision? What would be run time of your algorithm and storage complexity? (don't insist that candidate must hit the known optimal).
4. Can I have complex numbers as well?
5. Imagine complex numbers not only has "i" but also "j" and "k". How do we handle this?
It is astonishing how many candidates won't be able to move past #2.
The key is to look at how candidate approaches handling complexity, create representations and use it to craft clean solutions. Whether they eventually arrive at known optimal/great answers is unimportant.