Earlier quoted context omitted.
I disagree. You need to be able to find existing working solutions and use them, sure. But you also need to be able to do this kind of thing yourself if you can't find an existing solution, because that also happens all the time. It's that ability that they were testing. That's perfectly valid. They should however have told you that before the test.
Yes, they should have been more specific. Problem solving skills go a long way especially in programming. But then the question is how far should you go down the rabbit-hole. For example, how many variables can someone use? How optimized should the code be, regarding memory and speed? Are you looking at the code to be understandable? Should I use comments? Should I use for or while?
> For example, how many variables can someone use?
I've never heard of an interviewer explicitly limiting this, but if you have enough variables that you're asking, it might be a sign you've missed a more elegant solution to the problem...
> How optimized should the code be, regarding memory and speed?
Don't spend a lot of time on something before you know if it's what they want. You shouldn't go all the way through debugging the naive solution before you know if they're looking for something optimal; you shouldn't look for a very complex but theoretically optimal solution if they looking for fizz/buzz level of complexity.
To make it more concrete, many of my candidates just say something like "I could put everything into an array, sort it, and print it", maybe even adding "in O(n) memory and O(n log n) time". When that happens, I write down "quickly got naive solution", ask "what if we don't have O(n) memory?", and wait for them to (or help them) come up with something else. That's great from my perspective, as is asking me explicitly how much RAM is available / how large the input may be / if I want an optimal solution or an easy-to-understand one.
> Are you looking at the code to be understandable? Should I use comments?
In general, they're probably looking for it to be understandable, but they should know if you're coding under time constraints on a whiteboard that it's hard to revise quickly, that you can't fit a lot of stuff there, and that it's a lot faster to say aloud what you might otherwise put in a comment. If they don't make allowances for that, you'd probably hate working with them anyway...
Consequently, understandability might be more be about picking a meaningful variable name or thinking for a moment if you actually need to special-case some path before adding that extra if statement. Maybe drawing a quick diagram of your data structure.
And if you have extra time (a judgement call: maybe if you have a working solution, they aren't trying to move you on to another problem, you have don't have anything more to ask them), you could refine a bit.
> Should I use for or while?
They should know you haven't had the chance to read their internal style guide. They shouldn't care about this.
I also think they should give you significant leeway for minor syntax errors (saying, missing a ";"). There's a line somewhere between that kind of nitpicking and needing to see that you actually understand the language's syntax. It differs a little by interviewer. If you're anywhere close to the line, they should point out what's bothering them (perhaps saying "the compiler says ...") and give you an opportunity to correct it. If they don't, again they're probably kind of a jerk.