That would be an excellent question to ask during an interview.
If you were interviewing with me, I'd ask you to do the (usually expected) ASCII/array-of-graphemes version first. If you did that, you'd pass, and get a positive shout-out in the feedback session for asking about multibyte chars.
If you, after solving the array-based form, had some ideas or even working code for how to handle multibyte characters directly, without falling back to the standard library of $language's idea of "what is an iterable character-equivalent unit in a string", and demonstrated similar insight in your other interview problems, I'd give a positive shout-out with the addendum that we might be interviewing you for the wrong (too junior) position.
In my experience, most people don't ask about multibyte chars. That's fine, if they solve the problem. It's not a positive or negative. If an interviewer is building questions with hidden "must-ask" gotchas like that, I think they're doing themselves and their candidates a disservice.
Something interesting does happen occasionally when candidates do ask about byte-width (or equivalent less-common but still very important gotchas like pointer/word size, endianness, etc. in relevant problems): some people ask the question, solve the naïve form of the problem, and then offer some thoughts as to how they'd handle the broader multibyte case. But some other people act as if knowing that gotcha means they won't or shouldn't have to continue solving the problem. I've had candidates tell me that they "figured it out" and wanted to go on to the next challenge at that point, without writing a line of code. I've had candidates tell me flat out that writing non-Unicode aware string processing algorithms was unrealistic and a waste of time, and that they wanted a problem that was more real-world or suited to their level of skill. Those things will also get you a shout-out in the interview review session, but not the good kind.