Simply select a different game that's culture-appropriate. If you're interviewing in Asia, perhaps Go would be more appropriate. (And I believe the original author has a thing or two to say about that game as well. :)
Or don't even pick a game; I love "design an elevator control system". Most anyone looking for a programming position has interacted with one at some point in their life, and while you could easily mire down in details, it's not so complicated that you couldn't give it a fair hearing in the context of an interview.
There's a million things like this in our everyday lives that make great fodder for mental exploration in an interview.
The rules of Go are well defined, the interesting thing about Monopoly is that it's 'loose' definition replicates many of the real world problems that arise in a devs life.
One of my first Uni projects was to write an elevator control system and as you say, it's very revealing.
Take any problem where there are rules and n exceptions to those rules. All salesmen get cost * x% commission on an item EXCEPT when it's a a) our annual year end sale then they get y% or b) when it's an internet sale then they get z%.
That's the pattern to all this, rules and exceptions and how easy it is to change those rules (because they change constantly).
So do you put all that into your SalesPerson object or is there a better way to abstract the logic of commissions?
I've had similar interview questions before about different types of boats (I know barely anything about boats). The secret here of course is to demonstrate how you can deal with unknowns, turn it into a problem you understand and then solve it. If anything, you have greater opportunity to demonstrate yourself here.
Reading through a rule-sheet, even carefully, is not going to give you the type of understanding of game dynamics playing even 10 games would give -- and which would be fairly useful in this task.