This could be a good question for interviews. A good candidate should be able to come up with several solutions for implementing strings, and explain the pros and cons of each solution.
If their day to day job is solving hard problems at scale then maybe. But most companies overestimate the complexity of what they are really doing.
What would tell me how they write real world systems - and how I interview - is to give them a simple real world skeleton of a problem with failing unit tests, sit them down to a computer and make them make the tests pass.
If I am hiring an architect level position, I am not going to have then write algorithms on a board. I am going to do the same set of tests as above and have them design a scalable, fault tolerant system and have them draw it out.
I've been through enough interviews on both sides. The only thing that will tell you anything of importance is paying candidates to perform real tasks.
If doing algorithms on a whiteboard is part of the job; then sure, go for it. But I suspect very few of the really good coders out there would make much of an impression in that setting.
I’m rarely concerned about the right answer in an interview, because those are generally searchable.
“Just doing real world stuff” might be another useful but separate part of an interview.
When I'm working on solving real problems, I'll come up with ideas that make your head spin. Put me in front of a whiteboard and feed me canned problems with right/wrong answers and you won't ever see me again.
Also, solving problems without considering all the (or at least multiple) solutions isn’t really a very useful skill.
That said, all this varies by the role. If I was hiring a contractor position or regular web dev then “solving the problem” is an essential skill and solution bikeshedding might not be. But I’m hiring developers for low-ish level work on lib style code with 30 year maintenance windows. It’s radically different from creating a web stack with maybe a 5 or 10 year total lifespan.