I'm so disappointed with companies who choose to interview this way.
I've also been in interviews where one is asked to write code (pseudo or otherwise) during the session. I believe these kinds of tactics and those which ask for many hours of personal time in advance to submit a solution are rubbish. (1) it's a tall order to ask so much of a person emotionally (in the interview) and physically (full weekend of work), and (2) it's a poor means to assess ones ability to solve real problems.
Now I admit that there are some dev jobs which require constant creation and improvement of algorithm-like solutions. But for most of us, building line-of-business or straightforward consumer applications, we don't face these challenges on a regular basis. So if you're in the latter camp (and a lot of us are) then right there it's a poor intersection of daily work and interview technique.
If you do happen to have this type of challenge on a regular basis, then for goodness sake, give the candidate an environment where they can write real code and not whiteboard things. This way you're really seeing what they can do and how they code. Maybe even make it a pairing exercise and try to help them feel safe and not stressed. Simulate your real team - in mine, this problem would probably be tackled by a group as I've found that the more complex a problem is, the better return on time you get when you add developers to the conversation. The paper and whiteboard abstraction, stress and chaos is not what you want your potential candidates to assess your working environment on. And if you really don't have this kind of daily work environment, then why simulate it for an interview!?
As many of you know, DHH/Jason are quite wound up about this "chaos development" subject which seems to be popular lately. It must have bothered them because they've just released a book about it. m.signalvnoise.com/the-calm-compan...
Great work Nero on your solution and please don't use a poor experience like this to measure your ability as a dev. You clearly know what you're doing!
Personally, I'd choose to do this with a peer, come up with something like your (very clear!) visual mapping, and then write a failing test. This way I have a clear path to the goal with the implementation code. Would you do it different? Great! That's fine. And I hope you'd be lucky enough to do it in some peace and quiet or with a trusted, and calm colleague.
The stress and pressure created by solving nonsense, unrealistic problems in interviews doesn't help anyone. Please stop it.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.