I love how the candidate integrates a lot of ES6 features and even basic algorithms into this. I would kill for candidates like this when I interview. It doesn't only show that they keep updated in the field which is important on its own - it shows that they understand the fundamentals.
When I'm interviewing I _am_ interested in seeing this in a candidate. At the end of the day the candidate _did_ solve the problem.
At the outset, the interviewer placed a premium on time which the candidate ignored. The candidate made assumptions that the question was contrived therefore the solution offered was simply a place to make speaking points as well as test the interviewer's code literacy and as a result, spent the entire interview rewriting the system rather than filling in the blanks and moving on as asked.
Did the candidate prove adequate experience? Sure. But at the day of the day, I feel the interviewer made a very reasonable decision to dismiss the candidate based on the fact that the response ignored the implied time constraint for the sake of adding superfluous nonsense.
If I ask someone to fix a simple bug in some of my code and come back to see the code completely rewritten, 3 times the length with prince of darkness and tortoise and hare stuff mixed in, that would likely be the last time I ask them to touch my code.
If I were the candidate, though, I'd first explain the idea of the solution (takes half a minute), then discussed ways to implement it (a minute or two), then went with a particular solution (counter, bitmap, two chasing indices, etc). I'd keep feedback from interviewers constantly flowing.
Interviewers use filters like this question to weed out employees they don't want. What's wrong with interviewees using filters like code style and problem-solving priorities to weed out employers that wouldn't be a good fit?