Most postings for tester jobs these days call for test automation as part of the job description. Test automation is code. (Duh!) It is code that does not ship, and might not need to be particularly efficient, and its development process may be lightweight, but still, it is code that is expected to perform its intended purpose, will be checked into source control, may need maintenance, etc.
That’s the same sort of thing the Devs do. So if a company does coding interviews for Devs, expect them to also do coding interviews for their testers, who write code.
All the advice that I’ve seen and heard about doing coding interviews emphasizes that you’re supposed to ask questions about the problem you’ve been given, and talk about what assumptions you are making and what you’re thinking about as you go through the problem. You might be forgiven syntax mistakes if you make it clear that you have a reasonable implementation in mind.
To that, I will add – offer test cases. After all, testing is what we do. In fact – try to write the test cases first. If you’re given a problem with sample output, spare a moment’s thought for trying to come up with another case or 2, preferably demonstrating correct handling of an error or an edge case. And do pay attention to that sample output – does it actually show the data asked for by the problem statement? (I got a coding problem where that wasn’t true … clever!)