
My favourite interview question - joksnet
http://weblog.raganwald.com/2006/06/my-favourite-interview-question.html
======
edw519
_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!

~~~
barrkel
May be completely besides the point, but my first OO instinct upon approaching
the question is to model rules etc. as objects themselves. Only the most naive
OO modeler would think that OO objects must be nouns within some physical
analogue of the system - to my mind, anyhow.

~~~
dspeyer
Why would you want to do that? They have no state. You're almost never going
to do anything with them except invoke them from specific places. This sounds
like complexity for its own sake.

~~~
barrkel
First up, there's nothing wrong with immutable objects; indeed, immutable
objects have benefits that mutable objects don't. So not having mutable state
is not a good argument against modeling them as objects in an object-oriented
language.

Secondly, rules do have state, in so far as one rule is distinct from another.
Perhaps a rule has preconditions (which could be represented as a binary tree
and evaluated through recursion) that must be true before the rule is
"active". Perhaps rules have effects, a list of state changes that they impose
on the rest of the game world. You could model these as functions, or
alternatively again as trees, evaluated through recursion. If the rule system
needs to be flexible enough, they could be serializable and deserializable
from a text or binary format.

If the game is a simple one, with a fixed set of rules that never change,
there's little need for this. But if you look at a game like Monopoly, there's
a lot of complexity that comes up in real-life games that isn't so simple to
encapsulate in rule lists, such as making complex deals, haggling, borrowing
money from other players, even receiving charitable donations from other
players to prevent the game ending prematurely.

Move further into business rule systems and the need for flexibility increases
again. I've architected systems which needed a generic rule-based system for
data validation and workflow transitions; and these rules had themselves rules
for when they applied, as older rules needed to be grandfathered in to older
data, but expired for new data.

------
mathogre
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
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
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.

------
phuff
"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.

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

------
kenjackson
_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.

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

~~~
derefr
Perhaps hand them the rule-sheet?

~~~
jarek
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.

------
billmcneale
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.

------
RiderOfGiraffes
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
This has been posted before, with extensive discussion:

<http://news.ycombinator.com/item?id=2063092>

;-)

