I recently went on a couple of interviews and all of them asked a one or two design questions, like how you would design a chess, monopoly, and so on. I didn't do good on those since I am a college student and lack of the experience of implementing big and complex systems. I figure the only way to improve my design capability is to read lots of others' code and try to implement myself. Therefore, for those companies that ask these questions, what are their real goals in this? I figure most of college grads start off working in a team guided by a senior leader in their first jobs. They might not have lots of design experience fresh out of colleges. Anyone could give pointers about how to practice those skills? Thank you very much
closed as too broad by Greg Hewgill, Matthew Flynn, GlenH7, gnat, Bart van Ingen Schenau Oct 25 '13 at 9:43
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
The goal of an interview for a job where you will need to think is not if you can regurgitate known facts but rather how well you understand various things. Sometimes the facts are the indication of this knowledge (knowing what every place
When a question that is very broad is asked, it is an attempt to see how well you are able to work through the question. Asking "How do you implement a game of Monopoly" wants you to think through the problem. How do you represent the board, the cards, the placement of the tokens, the rules for the special squares, the houses and hotels and property values...
The interviewer wants to see you work through the problem and talk about the data types being used and the like. When you hit an area where you are unfamiliar with, how you work through that part of the problem is another key point of the question.
If one was to go and read the implementation of Monopoly (bad-games monop) and then reimplement it, you aren't likely to gain anything besides knowing that implementation. When asked a question of how would you add a feature of Fast Food Franchise (a monopoly based game), or anti-monopoly you'd be at a loss.
The way to handle this is to actually sit down and design or think through the design of complex systems. Try implementing the game on your own. Though, I can assure you that if you can rattle off the game design in the interview, a good interviewer will switch to another game or problem that you aren't familiar with in an attempt to see how well you solve the unknown - because thats what programming is really about, solving unknown problems and debugging the empty file.