As the author points out, he hasn't encountered that problem in the real world in 15 years. So it's one of those essentially entirely hypothetical interview problems. Maybe some insight can be gained about how the candidate solves the problem. I wonder if it's as straight-forward as it seems though.
Really, you'd be using UTF-8 these days, which was designed with unambiguously back-iterating in mind. Or you'd solve the author's shipping problem the way he did. So in fact, the most practical solution to the problem in the vast majority of cases is: use a better encoding/data structure. Even if you've got a legacy data set in such an obscure encoding, I think it'd be faster and less error prone to convert to a better encoding and work from there.
So if you encountered this problem in the real world, you'd most likely take a step back and see if you could avoid/work around it entirely, avoiding some messy, inefficient algorithmic solution. At an interview you're trying to find out if the candidate is suitable for the kind of real work you'd be hiring them for. Is it really beneficial to get them to solve some problem that you'd really try to avoid entirely in the real world? Sure, the candidate might spot the insanity of the problem, but in an interview, the problem wouldn't present itself the same way it might in the real world. There's no macroscopic context.
I'm not sure I'd have the presence of mind in such an interview situation. Nerves may just push me into autopilot and make me find an algorithm. (note: I've been on both sides of the interview game; more frequently in the interviewer's chair)
