> That they can code independently
You are testing that they can code independently by forcing them to code in a group setting? "Guiding them, explaining, understanding their rationale" is about the exact opposite of testing for "can they code independently". Not to mention all the usual issues that whiteboard "coding" resembles real world coding not at all.
Especially if you are just talking simple string manipulation which can be done with just loops; either you are asking the candidate to reinvent the wheel of a library function they use all the time and should never write by hand in a real world codebase or your example is contrived in other ways in which the real answer is way more complicated due to performance issues (because low level string manipulation likely is a performance issue).
This is exactly where it becomes a trap, too: in a real world application I'd need to evaluate any and every string manipulation written by hand to test it for performance issues and determine the appropriate string manipulation tools for the job. In C# today that includes knowing when to use a StringBuilder versus knowing a lot of gory details of Span and String.Create and a deep rabbit hole of memory management issues (.NET strings are immutable, so this pretty much accounts for all real world string manipulation in .NET today that it is never "just" string manipulation). Other languages have related memory management concerns, but different dialects and mental overhead. Also, it's 2021 and no one in the real world should be doing any string manipulation at all without accounting for Unicode, so in a real world application you need to make sure you are using your platform's correct APIs for "rune" manipulation rather than raw codepoint manipulation for Unicode safety.
In a whiteboard exercise you are probably going to tell me "don't worry about that" or "just keep it simple", but that's the biggest "reasoning" behind potential edge cases and after a number of years of professional work I can't shut off that firehose of practical concerns and it will take me a while to get to the "simple exercise" because my brain has lots of in-grained habits at this point and you are asking for "coding insight" like the real world, but in no way like an actual practical programming issue and the real programming issues still get in the way because I "know too much" at this point to react well in any "simple" problem.
The other trap here is "soft-skills", again deeply contrary to "coding independently": while "coding" you want the candidate to express themselves out loud and communicate their rationale. While many of the pop psychology ideas of "right brain, left brain" are mostly wrong (or at least wildly over-generalized), the basic idea applies here well: you are asking candidates to light up two very different sections of their brain all at once. Maybe for someone far more used to pair programming that's a bit like walking and chewing bubble gum at the same time, but for someone used to "coding independently" (as you are asking to test) that's a lot more like those stupid pat your head and rub your tummy at the same time "tests". You can do it, it takes a lot more energy and conscious thought, and it doesn't "feel natural" for "coding independently" at all. I don't know about anyone else, but I find that not just incredibly draining but a migraine trigger and it is very hard for me not to end nearly every interview with a nasty migraine.
> think about the problem, reason about the potential edge cases
You'd test for these better with creative problem solving exercises. Everyone likes to make fun of those "silly Microsoft-style questions" like "describe all the functions of Vending machine to me like I've never used one" or "how many spherical elephants can you fly in a Boeing if the Boeing were made out of Legos you had to assemble from scratch but assume the fully assembled plane could still fly for some reason" or silly things like that, but they actually do a stronger job of exploring someone's creative problem solving skillset than any equivalent "coding" exercise, if the person truly has never encountered that specific problem example before (which is the hard part Microsoft found that people started to collect them and prep for them).
That's what I mean by "what are we actually testing for here?" If we are testing for creative problem solving, coding is rarely the best way to test for that. (Especially coding for "simple" things like string manipulation. That may be a domain someone has explored to considerable depths, and come out the other side where that is no longer a creative problem solving exercise but a boring, practical "construction" project with existing boring blueprints. Most algorithms questions test if a candidate can follow blueprints, not if they can problem solve.)
> communicate their rationale
Here's where we see the true crux of my question "what are we actually testing for here?"
If we are testing for soft-skills, test for soft-skills. "Coding" isn't a great time to test people used to "coding independently" for communication soft-skills (see above).
The HR world has centuries of knowledge on how to run soft-skills interviews (and how not to run them to avoid discrimination). "Coding" veers towards that "how not to run them" side because of that pat your head and rub your tummy effect. At best, it's not a great test of real world soft-skills performance. At worst, it's potentially discriminatory versus neuro-diversity.