11 ms·

My favourite interview question

126 points by joksnet 16y ago

deleted 16y ago
[deleted]
roadnottaken 16y ago
What if your candidate isn't familiar with Monopoly because, say, they didn't grow up in the west?
- derefr 16y ago
  Perhaps hand them the rule-sheet?
  - metageek 16y ago
    Available online, even: http://www.hasbro.com/common/instruct/DeluxeMonopoly.pdf http://www.hasbro.com/common/instruct/DeluxeMonopoly.pdf
  - jarek 16y ago
    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.
- logic 16y ago
  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.
  - dazzawazza 16y ago
    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.
    - deleted 16y ago
      [deleted]
- deleted 16y ago
  [deleted]
- nopassrecover 16y ago
  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.
- pragmatic 16y ago
  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?
edw519 16y ago
What I’m about to say will be blindingly obvious to the Enterprise crowd...The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications. What a refreshing statement at a time when we're bombarded with so many annoying "SQL is Dead" posts. Try designing an enterprise production/distribution system where: - set-ups must be minimized - backlog must be minimized - inventory must be minimized - trucks must be full - warehouse space is limited - deliveries must be on time, but not too early - sales people must have stock on hand - plant absorption must be maximized - bills must be paid on time - down time must be zero - working capital must be put to the best use - stockholders must be satisfied Say what you want about enterprise programmers, but they get stuff built that handles all of these while academicians fuck around with linear algebra and OO castles for years. After this, Monopoly sounds like a day off. Great post!
- dazzawazza 16y ago
  Of course many of the concrete methods enterprise developers use come from these 'academicians' so don't be too quick to judge them. We all stand on their shoulders... it's fine to give em a good kick every so often but remember who is holding us up.
  - edw519 16y ago
    I agree that we all stand on the shoulders of giants, just not the same ones you cite. As a trained mathematician, I wish I could agree with you and cite all the wonderful applications of classical thinking that I've used to solve real enterprise problems, but alas, I can't. It was only after I abandoned the constant search for "elegant" solutions to real world problems that I was able to embrace good old fashioned "blocking and tackling" to solve the problem at hand. I've lost track of how many times I was challenged to "use the simplex method" to attack multiple simulaneous mutually exclusive constraints when the most effective approach ended up being, "Put all the data into a relational database and keep spitting it out different ways until our people figure it out." The scientist in me wishes it wasn't true, but the pragmatist knows better. Sorry to dump on the academic world so much, but I suppose I wouldn't if I could cite more success stories. The Monopoly example just struck a nerve; a classic example of the difference between theory and practice.
MoreMoschops 16y ago
My favourite interview question is "When can you start?"
mathogre 16y ago
No one here or on the original page seemed to consider they should design a Monopoly game on the net to be "fun." Especially since Hacker News is about and for entrepreneurs, it would seem natural to turn an idea like that into money. Monopoly is a game. It should be fun. It had better be fun, or the design doesn't matter because it won't sell. What makes the game fun? Part of it is the interaction between players, laughing, joking, scheming, and posturing. How do you bring that to a game played over the net? Is text chat sufficient, or can you easily do voice? What do you display to the players? Certainly part of the board needs to be displayed. When I play, I like to see what people have for properties and money. Will I be able to see that Alice has a stack of $500 bills or that Bob has nothing larger than a $50? The original question is a very cool thought experiment, imho. My initial reaction was that to design this, I'd want to sit and play some games of Monopoly to see what to include and to see what the game is really all about. I've played hundreds of games of Monopoly, but that's not the same as designing a fun game to play over the net. Running through this little thought experiment helps raise many questions about how the game will work. Does each player have a complete client, or is this a server based system (or is it somewhere in between)? How do you handle dice rolls? How quickly can people start a game? You need to know what you're going to create before you start applying tools to create it.
- raganwald 16y ago
  I didn't get into what I would call the "product management" aspect of the question in that post, but if it doesn't bore you to hear it, I have participated in interviews where this question was asked of non-technical people, specifically a product manager and a web designer. I don't remember if "fun" was specifically discussed, but the discussions were more focused on what users would do and see, very much in keeping with your second paragraph. The product manager was also asked to consider the exercise from a competitive perspective. What could be done to differentiate a new site from an existing, popular site? is the strategy to be simplere and easier? To cater to power users running into limitations of the existing site? And so on.
  - mathogre 16y ago
    Not only do I think the "project management" aspect is interesting, I think it is essential! I develop s/w in an R&D environment. My users are very specific about how they use information, but know almost nothing about s/w development. Likewise I know little of their specific domain, but can develop whatever tools they need. While I can craft and code algorithms that should dazzle them, if it doesn't solve their problem they won't use it. For me, design has to account for the users' experience as well as developing clever and efficient algorithms to solve problems. I really love the original question, Reg. It was fun.
kenjackson 16y ago
If the candidate uses up all of the interview time trying to obtain perfect requirements, we have a problem I don't know how long your interview is, but if its just an hour and if the game is as ambiguous as you seem to say it is, I think its the fault of the interviewer, not the interviewee. The interviewee doesn't know what your schedule is -- unless you tell them, "You must code monopoly by the end of this hour, warts and all". But otherwise, I think its reasonable to take the full hour on requirements. In real life, an hour on requirements doesn't describe if there should be a splash screen or not.
phuff 16y ago
"If the candidate uses up all of the interview time trying to obtain perfect requirements, we have a problem. In the software development I do, the requirements are never perfect. I don’t demand that a candidate try to create an agile, iterative process on the spot, but I look for someone who knows when to say 'close enough, let’s move forward.'" I think this is a great reason why most interviewing techniques fail. The interview is not a reliable model of the work environment. This is especially true given the fact that people love "gotcha" interview questions which are essentially brain teasers which require you to know some arcane trick to get the question right. I have seen great candidates spend a lot of time trying to understand a simple problem in an interview. These are people who under normal working conditions would never waste tons of time trying to get a perfect spec before starting work. But, because of the types of interviews people try and pass over as being "reliable indicators of future performance" candidates get stuck trying to find the trick in each question. If you have a candidate spend their entire interview trying to tease out a spec it sounds like a better indicator of the low quality of the interviewer rather than the candidate to me... When people start heading that direction in an interview, be sensible and say, "Do you feel like you need a complete spec before going on? I promise there's no trick I'm trying to get you to fix" and you'll get the response you're actually looking for.
RiderOfGiraffes 16y ago
I know this is kind of beside the point, but my response would ne pretty simple - I've never played Monopply, and have no idea of its structure at all.
- raganwald 16y ago
  This has been posted before, with extensive discussion: http://news.ycombinator.com/item?id=2063092 http://news.ycombinator.com/item?id=2063092 ;-)
billmcneale 16y ago
In my experience, it's already hard to get a good read of a candidate within 45-60mn without adding external entities. Monopoly is not just an external entity, it's a pretty big one with tight cultural ties. If the candidates you interview were not born in the same country as you, the best case scenario is that they played Monopoly in a different language and the worst case scenario is they never played it. I prefer to focus my interviewing on questions that rotate around pure coding (if that's what the candidate is interviewing for) and even then, I hardly find the time to dig as deep as I'd like.

126 points by joksnet 16y ago

deleted 16y ago

[deleted]

roadnottaken 16y ago

What if your candidate isn't familiar with Monopoly because, say, they didn't grow up in the west?

derefr 16y ago
Perhaps hand them the rule-sheet?
- metageek 16y ago
  Available online, even: http://www.hasbro.com/common/instruct/DeluxeMonopoly.pdf http://www.hasbro.com/common/instruct/DeluxeMonopoly.pdf
- jarek 16y ago
  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.
logic 16y ago
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.
- dazzawazza 16y ago
  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.
  - deleted 16y ago
    [deleted]
deleted 16y ago
[deleted]
nopassrecover 16y ago
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.
pragmatic 16y ago
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?

edw519 16y ago

What I’m about to say will be blindingly obvious to the Enterprise crowd...The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications. What a refreshing statement at a time when we're bombarded with so many annoying "SQL is Dead" posts. Try designing an enterprise production/distribution system where: - set-ups must be minimized - backlog must be minimized - inventory must be minimized - trucks must be full - warehouse space is limited - deliveries must be on time, but not too early - sales people must have stock on hand - plant absorption must be maximized - bills must be paid on time - down time must be zero - working capital must be put to the best use - stockholders must be satisfied Say what you want about enterprise programmers, but they get stuff built that handles all of these while academicians fuck around with linear algebra and OO castles for years. After this, Monopoly sounds like a day off. Great post!

dazzawazza 16y ago
Of course many of the concrete methods enterprise developers use come from these 'academicians' so don't be too quick to judge them. We all stand on their shoulders... it's fine to give em a good kick every so often but remember who is holding us up.
- edw519 16y ago
  I agree that we all stand on the shoulders of giants, just not the same ones you cite. As a trained mathematician, I wish I could agree with you and cite all the wonderful applications of classical thinking that I've used to solve real enterprise problems, but alas, I can't. It was only after I abandoned the constant search for "elegant" solutions to real world problems that I was able to embrace good old fashioned "blocking and tackling" to solve the problem at hand. I've lost track of how many times I was challenged to "use the simplex method" to attack multiple simulaneous mutually exclusive constraints when the most effective approach ended up being, "Put all the data into a relational database and keep spitting it out different ways until our people figure it out." The scientist in me wishes it wasn't true, but the pragmatist knows better. Sorry to dump on the academic world so much, but I suppose I wouldn't if I could cite more success stories. The Monopoly example just struck a nerve; a classic example of the difference between theory and practice.

MoreMoschops 16y ago

My favourite interview question is "When can you start?"

mathogre 16y ago

No one here or on the original page seemed to consider they should design a Monopoly game on the net to be "fun." Especially since Hacker News is about and for entrepreneurs, it would seem natural to turn an idea like that into money. Monopoly is a game. It should be fun. It had better be fun, or the design doesn't matter because it won't sell. What makes the game fun? Part of it is the interaction between players, laughing, joking, scheming, and posturing. How do you bring that to a game played over the net? Is text chat sufficient, or can you easily do voice? What do you display to the players? Certainly part of the board needs to be displayed. When I play, I like to see what people have for properties and money. Will I be able to see that Alice has a stack of $500 bills or that Bob has nothing larger than a $50? The original question is a very cool thought experiment, imho. My initial reaction was that to design this, I'd want to sit and play some games of Monopoly to see what to include and to see what the game is really all about. I've played hundreds of games of Monopoly, but that's not the same as designing a fun game to play over the net. Running through this little thought experiment helps raise many questions about how the game will work. Does each player have a complete client, or is this a server based system (or is it somewhere in between)? How do you handle dice rolls? How quickly can people start a game? You need to know what you're going to create before you start applying tools to create it.

raganwald 16y ago
I didn't get into what I would call the "product management" aspect of the question in that post, but if it doesn't bore you to hear it, I have participated in interviews where this question was asked of non-technical people, specifically a product manager and a web designer. I don't remember if "fun" was specifically discussed, but the discussions were more focused on what users would do and see, very much in keeping with your second paragraph. The product manager was also asked to consider the exercise from a competitive perspective. What could be done to differentiate a new site from an existing, popular site? is the strategy to be simplere and easier? To cater to power users running into limitations of the existing site? And so on.
- mathogre 16y ago
  Not only do I think the "project management" aspect is interesting, I think it is essential! I develop s/w in an R&D environment. My users are very specific about how they use information, but know almost nothing about s/w development. Likewise I know little of their specific domain, but can develop whatever tools they need. While I can craft and code algorithms that should dazzle them, if it doesn't solve their problem they won't use it. For me, design has to account for the users' experience as well as developing clever and efficient algorithms to solve problems. I really love the original question, Reg. It was fun.

kenjackson 16y ago

If the candidate uses up all of the interview time trying to obtain perfect requirements, we have a problem I don't know how long your interview is, but if its just an hour and if the game is as ambiguous as you seem to say it is, I think its the fault of the interviewer, not the interviewee. The interviewee doesn't know what your schedule is -- unless you tell them, "You must code monopoly by the end of this hour, warts and all". But otherwise, I think its reasonable to take the full hour on requirements. In real life, an hour on requirements doesn't describe if there should be a splash screen or not.

phuff 16y ago

"If the candidate uses up all of the interview time trying to obtain perfect requirements, we have a problem. In the software development I do, the requirements are never perfect. I don’t demand that a candidate try to create an agile, iterative process on the spot, but I look for someone who knows when to say 'close enough, let’s move forward.'" I think this is a great reason why most interviewing techniques fail. The interview is not a reliable model of the work environment. This is especially true given the fact that people love "gotcha" interview questions which are essentially brain teasers which require you to know some arcane trick to get the question right. I have seen great candidates spend a lot of time trying to understand a simple problem in an interview. These are people who under normal working conditions would never waste tons of time trying to get a perfect spec before starting work. But, because of the types of interviews people try and pass over as being "reliable indicators of future performance" candidates get stuck trying to find the trick in each question. If you have a candidate spend their entire interview trying to tease out a spec it sounds like a better indicator of the low quality of the interviewer rather than the candidate to me... When people start heading that direction in an interview, be sensible and say, "Do you feel like you need a complete spec before going on? I promise there's no trick I'm trying to get you to fix" and you'll get the response you're actually looking for.

RiderOfGiraffes 16y ago

I know this is kind of beside the point, but my response would ne pretty simple - I've never played Monopply, and have no idea of its structure at all.

raganwald 16y ago
This has been posted before, with extensive discussion: http://news.ycombinator.com/item?id=2063092 http://news.ycombinator.com/item?id=2063092 ;-)

billmcneale 16y ago

In my experience, it's already hard to get a good read of a candidate within 45-60mn without adding external entities. Monopoly is not just an external entity, it's a pretty big one with tight cultural ties. If the candidates you interview were not born in the same country as you, the best case scenario is that they played Monopoly in a different language and the worst case scenario is they never played it. I prefer to focus my interviewing on questions that rotate around pure coding (if that's what the candidate is interviewing for) and even then, I hardly find the time to dig as deep as I'd like.