Yes, it's supposed to be unclear because I expect the candidate to clarify the requirements. Jumping in to implementing something would be a bad move. Asking questions like these would be a good first step.
I think of it as the FizzBuzz version of getting requirements for the thing you're supposed to be doing.
>Jumping in to implementing something would be a bad move.
I would expect a skilled programmer to be be able to make intelligent inferences about the intended behavior in the face of ambiguous problem statements. FWIW, I would probably explain my reasoning as I went -- would you interrupt a candidate to say you'd rather see a different behavior (ex: my prototype would return a list with an empty string, but maybe you'd rather an empty list), or just silently judge them? Also, it look me about 2 minutes to produce a reasonable prototype -- maybe if the challenge were harder I'd expect someone to ask more questions up front, but in this case it's trivial to iterate.
If the only thing you are testing for is the instinct to clarify unclear requirements, you'll surprise people who are used to the leetcode-style, thereby getting false negatives. It's just as much a trick question then, just in a different dimension.
Oh, I hate this. I get your point but as a potential new hire of your company I'm also interviewing you. This means that if you state a problem in a very ambiguous way (like you did in your first message) that's already a red flag for me. Sure, I don't expect 100% accuracy in your problem statement, but I don't expect either lazynnes for the sake of "let's see if the interviewer asks good questions before implementing anything".
That's fine. I don't think every job is a fit for every person or vice versa. Your reaction is a positive one for my question - if you don't want to work where you have to clarify ambiguous requirements then you wouldn't want to work for the company I'm at, and it's best we figure that out as early as possible, like in the phone screen.
Both sides have a point. Perhaps your parent runs a shop where ambiguous requirements are one of the biggest problems they face, whereas you prefer to work in roles where the requirements are already established and you focus on working within them.
I think of it as the FizzBuzz version of getting requirements for the thing you're supposed to be doing.