Occasionally a question that is asked at an interview comes up - "how would you design Amazon Web Services" or "how would you write Google" or some such question.
These questions find their way to SoftwareEngineering.StackExchange in hopes of getting an answer for the next time they are asked on an interview.
Often, these questions are closed - why is it that they are considered poor questions here?
There are several aspects to this question that make it a poor question to ask on Software Engineering.SE, and some that also make it counter productive to have planned out for an interview.
The first aspect is that the question is too broad. The "How do you build Amazon" being asked here is akin to going to Home Improvement.SE and asking "How do you build a house?" There is no way the totality of that question can be answered in a meaningful way in this text box - the topic is far too broad.
To an extent, it is exactly that broadness that the interviewing is asking. This question isn't one like "how many ways can you use static in Java" - which has an answer. The interviewer is coming to you like a business person would with some question that you need to drill down into to ask - and clarify the question.
However, as a question on a Q&A site, with you asking the question you don't know all the questions and the scope of the question the interviewer has in mind. One interviewer may want you to drill down into the shopping cart side of Amazon, another may want to want to drill into the virtualization of AWS, another may want things about product recommendation or customer purchase prediction.
Amusingly stated in a comment:
Your "friend" should have closed the interviewer's question as "too broad." In other news, "design a big distributed system" is not a requirements specification. – Robert Harvey
The Q&A format that Stack Exchange uses works best when there is a clearly defined problem. With the Amazon question, asking "how do I build and collect data for A/B testing - I've done XYZ, but I have trouble with this design for dealing with..." could be a reasonable question - it is one problem that can be asked and answered, and not to be overlooked found when someone else is searching for the same thing.
The asked, answered and found steps are key parts to how Stack Exchange works - remember that the question isn't just for you, its also for the next person asking the question.
Next, it's counter productive. Lets say you get asked a question on how to implement Monopoly and you had no idea didn't get the job and went home to study Monopoly implementations. A week later, another interview, and you are asked how to implement Monopoly again and you rattle off the implementation that you've memorized (just like the how many ways can you use static in Java question asked just before). It is clear that rattling off Monopoly from rote doesn't mean you understand it, so the interviewer asks how you would implement Risk...
The key to this example with why its counter productive to try to have a pre-constructed answer for this question is that the interviewer is trying to find your boundaries. By going with a pre-thought out answer that boundary hasn't been determined. It's the process of thinking through these questions as part of the interview that the interviewer wants to see - and will ask you question and question again until that process is clear about how you think of design.
And so, while there may be an answer that can fit in the space (you talk about the circular array for the board, the stacks for the cards, the rules engine for implementing how the different cards behave, the rules for the game, etc...) that might fit here, by having a thought out answer you're going to be asked them again and again until you are asked one you don't know - you've only wasted your time and that of the interviewers up until that point.
I will point out that studying BSD Games/monop which is written in classic C will likely have difficulty when the interviewer says "let's try that again in C#" or "let's change that design to anti-monopoly"
One of the best places to ask such broad questions is Chat. The wide range of the question and understanding that it's an interview question can be better addressed in an interactive way rather than a question and answer format. The dialog between the person asking the question and the person answering it is an important part of the process of this type of question and understanding the design aspects of it.
Some interviewers ask questions with specific answers in mind. All other answers are unsatisfactory to them other than the one they want. Even if its wrong.
The difficulty with such questions is that the only person who knows the answer the interviewer was looking for is the interviewer. They may not have liked your design because of some opinionated blog post they read a year ago, or that its not cutting edge enough, or that you didn't implement their favorite Pattern.
Asking such a question here results in answers that are just speculation. We weren't the interviewer and we can only guess at what issues the person had with your design or solution.
A good interview question does not have an answer that the candidate knows; the candidate is expected to be able to discuss different options, with some options being thrown in by the interviewer.
The questions is asked to find out how (or if) the candidate thinks, not to get an answer to the asked question.
On SE sites questions are asked to get answers to the question.
