
My favourite interview question (2006) - danso
http://weblog.raganwald.com/2006/06/my-favourite-interview-question.html
======
hagmonk
So I tried a new approach inspired by this kind of interview question. In a
nutshell: it aims to simulate the interactions you'll have with the candidate
when they receive their first project, without the time burn of a full pair
programming day.

1) determine the system the candidate will design. It should be an internal
system or an internal oriented problem, not an external thing like Monopoly or
URL shortening services.

2) stack your interview team with a mixture of people who can contribute
different thoughts to this problem. Engineering, UI, marketing, management,
etc.

3) first interviewer of the day introduces the topic and helps the candidate
understand some of the internal lingo and bootstrapping questions they'll have
right off the bat. The first interviewer is pretty crucial because the
candidate has to be prepared to write things down and carry information across
each interview.

4) all subsequent interviewers come in and ask two questions:

* What problem were you given to solve?

* I'm an expert in technology / business area X. How can I help?

By the end of the day when they're having their likely optional interviews
with more senior people, they should look disheveled but pretty happy, because
now they're pitching to senior management an idea they collaborated on with a
wide variety of team members.

They should have a whiteboard full of stuff, stacks of paper, whatever. You
should get a good idea of how they organize themselves under pressure.

The interview team should have a good feel for how the candidate leveraged
them for answers. The interviewers should have done a lot of talking! There
should also be clear evidence of the candidate getting _better_ towards the
end.

At the conclusion they're tasked with taking a step back to the higher level
to explain the idea to management - regardless as to whether management is
technical or not, they should be expected to walk away understanding the big
picture. Having non-technical "business" people contribute to the interview is
critical, since they help the candidate understand some of the human
requirements.

I could go on and on, I'm pretty excited about how this technique has worked
so far. The key element is deliberately having the candidate carry knowledge
between interview teams. I'm sure I'm not the first person to think of this :)

EDIT: styling

~~~
Stratoscope
Thank you, that sounds like a brilliant technique!

One question: Do you let candidates know ahead of time what the interview
process will consist of? That sounds like an important step that many
companies leave out - whatever interview process they use.

I think if I knew before arriving that this how it would work, I'd be a lot
more excited about the interview and better prepared too.

~~~
hagmonk
Yes, the candidate should know in advance if there is a particularly
structured interview technique being used, for sure.

Because it also requires a lot of mental commitment from the interview team as
we'll as the candidate, I'd recommend using this technique as the final
hurdle. I don't think you want to phone screen someone, then just toss them
into this process. You need to have them cross some basic technical gate (like
FizzBuzz, a take-home coding project, whatever), and have them meet a handful
of people first, just to make sure they pass those early smoke tests.

In fact I think this technique works best when you want to seal the deal with
a very strong candidate who is entertaining several options. Interviews should
always be a two-way process, and if a candidate walks away from your
interviews thinking "I had real trouble getting my point across to those
people, I would never work there" then that represents _success_ for the
interview process.

The strongest candidates tend to be the ones least influenced by money and
more interested in the problems, the people they will be working with, the
culture and the environment of the organization. So having your interview
process structured around revealing that gives you the best possible chance of
matching your team with people excited to be there.

Conversely if you're a candidate, even if the company you're applying with
doesn't seem to have thought too deeply about this stuff, don't despair.
Hiring is one of the hardest things to do and also tends to be done by the
seat of the pants (Amazon seems like a notable exception) _You_ can impose
your own structure by asking the right questions and making special requests
of the recruiter. Tell them you want a chance to write code with someone! Or
that you want to mock up a UI that solves a problem they have. Or you want to
see what their strongest engineer thinks of your design for this service
you've put together.

It doesn't matter if you're desperate for the job, or whether you wish they'd
stop calling you ... this kind of stuff makes you stand out in the crowd as
proactive and motivated by the right reasons.

------
malkia
The problem with this question is that if you've asked someone who's played
Monopoly a lot, also the old DOS version, and the latest EA versions - he/she
might stick to concrete implementations and go in details how it could be done
(since it's out there).

[http://www.abandonia.com/en/games/895/Monopoly+Deluxe.html](http://www.abandonia.com/en/games/895/Monopoly+Deluxe.html)

[http://www.textmodegames.com/download/monopoly.html](http://www.textmodegames.com/download/monopoly.html)

And here complete list:

[http://en.wikipedia.org/wiki/Monopoly_(video_games)](http://en.wikipedia.org/wiki/Monopoly_\(video_games\))

[http://www.mobygames.com/search/quick?q=monopoly](http://www.mobygames.com/search/quick?q=monopoly)

~~~
alangpierce
You would probably also get the opposite problem: I bet some people
(particularly international candidates) have little to no experience with
Monopoly, and the question would be unfair to them. If the goal is to start
with their vague understanding of the game and see what gaps they fill in and
what assumptions they make, then it doesn't work very well if you have to
explain the game from scratch. It also takes quite a bit of time to explain
the game if someone hasn't seen it before, which doesn't feel like a very
efficient use of interview time.

~~~
malkia
Yup. Asking poker, bridge, santase, chess, etc. rules at interview is tricky.

------
stevebot
I would much rather hear about their past projects and have them clearly
convey design decisions that they made before then have them work on a "on the
fly" question. Everybody has off days, not many people have whole off years or
careers. Just because I can't design Monopoly in one hour on a certain given
day doesn't mean I do not have the relevant experience in my past, whether it
be professional or as an undergrad.

~~~
yannyu
It's not as though this is the only question by which the interviewee will be
appraised. This is one more tool in the kit alongside asking about previous
projects, interesting classes, career goals, overcoming tough situations, etc.

Whether or not questions like these are effective, the point of them is to
engage with someone in a way that illustrates how they tackle complex, loosely
defined issues: the majority of engineering problems in a nutshell. In most
modern tech companies, good communication and not being afraid to ask
questions are absolutely essential. Someone who will take an incomplete list
of requirements and draw up an entirely incomplete product without questions
or discussion is as much a liability as someone who takes the requirements and
does nothing, paralyzed by indecision and not knowing what to do. And
oftentimes, candidates aren't perfect but you're going to hire them anyway.
Going through this process can illustrate how you would expect to interact
with the candidate and where the initial rough spots will be as the candidate
begins working with the team.

From another point of view, candidates are usually more than prepared to talk
about anything on their resume. In some cases, this is equivalent to listening
to someone give a prepared speech. Asking them free-form questions like the
above can be a good way to understand how the candidate reacts in situations
where they aren't fully prepared. For some positions this is irrelevant, but
for others it's incredibly important to have some measure of poise and
thoughtfulness when engaging with someone who doesn't necessarily agree with
everything you say and is questioning your thought process.

In short, these kinds of questions aren't primarily testing your design and
programming abilities, but your ability to communicate and reason with another
person in a technical context.

~~~
stevebot
You missed my point. People are prepared to talk about their resume, but when
you dig in to their past experience and specifics that is where you get to the
interesting discussions.

Case and point:

Tell me about a design pattern you used on X project?

A singleton? Ok, why did you use that?

and a long discussion about testability and architecture ensues with questions
from both sides. That is WAY more like the communication that happens on the
job than a contrived problem which in many cases is disconnected from real
life constraints.

------
jcadam
I remember being interviewed in the DC area, where I was asked a question
involving subway systems and routes. Being a mid-western lad completely
unfamiliar with subways (and mass transit in general), I had a lot of trouble
visualizing it. I would imagine that people who rode mass transit on a regular
basis wouldn't have as much difficulty. Got a job offer anyway, though.

------
Xyik
Love how every time a post concerning interviews pops-up on hackernews
everyone gets defensive. Like all things I think the nature of the interview
should reflect the role the developer will have when hired. If the developer
won't be in charge of developing an entirely new system or project on his own
it seems overarching to ask this type of question. At the end of the day the
core attributes that matter are intelligence, ability to learn, experience and
motivation. In this case, this question really only tests experience.

------
serve_yay
I once got a similar question, but with Battleship. I don't really enjoy these
high-level design things, they seem silly and irrelevant to me, but I can see
how someone with different interests would like it. (That particular place
made me an offer, I'm not doing sour grapes.)

~~~
sfbushstreet
If you practice ALL of these questions for at least TWO passes:
[https://oj.leetcode.com/problems/](https://oj.leetcode.com/problems/) , you
can get a software engineer role in at least one of the famous tech companies,
e.g., facebook, linkedin, google, amazon, microsoft, ...

Nowadays, very very few companies innovate in recruiting.

I've interviewed with most "hot" companies, and I can find most interview
questions (>90%) from
[https://oj.leetcode.com/problems/](https://oj.leetcode.com/problems/), exact
same question.

~~~
pc86
I mean, yes, but if you can write passable code in two of [C++, Java, Python]
for 170 problems of varying levels of complexity, I don't think it's much of a
stretch to say you're a good programmer and could probably get a SE job at a
company I've heard of before.

------
sparkzilla
The best interview question is "Why wouldn't we hire you?' You won't believe
what people will say, in their urge to confess their sins.

~~~
scarmig
"I'm going to ask for a lot of money."

True-est, and it's the perfect filter.

~~~
nostromo
I've actually heard, "you can't afford me" in an interview before. (It was not
technically an interview, but a meeting between my boss and someone he wanted
to recruit.)

I think my boss (CEO of a mid-sized public company) took it as a challenge and
gave him a very large offer -- which was politely refused.

------
protomyth
I generally went with a question my friend told me, "what was the last non-
work, non-school program you wrote?". The theory being that a person who has
used programming for something personal was probably a better candidate since
they saw personal value in their profession.

~~~
whyaduck
In a good week I work 50 hours. In a bad week, 80 or 90 (or more). In my spare
time I have family commitments, play guitar, draw, paint, hike, ride my
mountain bike, and travel. Ask me that question and I'll probably find a way
to wind up politely and leave.

~~~
ColinWright
I'm sure there are many here who would agree with you, but let me offer an
alternative viewpoint. You said:

    
    
      > Ask me that question and I'll probably
      > find a way to wind up politely and leave.
    

The implication is that rather than opening a dialog with someone to (a) find
out why they think that question is relevant, and (b) offer reasons why you'd
be a good fit _despite_ not working with code outside your job, you'd simply
leave?

For me, as a potential employer, that would be a good reason not to want to
hire you. It makes you sound like you would not be an easy person to work
with. It sounds like if someone came to you with an unreasonable software
requirement you would simply shut them down without trying to find a way to
deliver something that finds a good balance between what they've asked for,
and what can be done.

But perhaps that's not the impression you intended. If not, could you expand
further?

~~~
gknoy
You have a very good perspective on what an employer would love to hear from
someone, regardless of whether they code for fun on the side.

However, as an employee, such questions might be highly correlated with past
companies that are looking for people who do not have family commitments, or
who are willing to do unpaid extra work at home "for fun". As an interviewee,
it makes me wonder, even if only fleetingly, "Will I be discriminated against
for not being (young+single)?". (Are we even allowed to ask about marital
status or age?)

Even if such a thing was never your intention, the interviewee might have had
prior bad experiences with those who ask such a question, and view cutting the
interview short as a way to ensure they don't get mistreated later.

~~~
ColinWright
In that case, just as an interviewer looks for indications beyond a single
question, so should an interviewee. Cutting an interview short because of one
indicator seems short-sighted. Surely better would be to use it as one
indicator, and then start looking to see if there are more.

But I understand the point point of view, I'm just trying to give some
balance, and point out that the black/white attitude this suggests is
sometimes a clear indication that you are not cut out for a particular
position.

------
luu
Am I the only one who thinks that this kind of design question is the new "how
many gas stations are there in Manhattan?"

In both cases, the point isn't to get the right answer, but (allegedly) to see
how the person thinks. With the estimation question, the trick is to make up
some plausible-ish numbers and then multiply and/or add them to get a
plausible-ish result. If someone's seen one of those before, they'll nail it
for sure. If not, it's a crapshoot. In theory, you're measuring whether or not
someone's able to reason well enough to spontaneously estimate something off
the top of their head, but comparing the number of people who've seen those
question before vs. the number of people who can answer that type of question
without having ever seen it before, what you're really filtering for is people
who have heard of or seen Fermi questions.

A while back, someone's interviewing experience got posted to HN and they
mentioned that they got asked to design a URL shortening service maybe five
times. They failed it the first couple of times and got progressively better
each time. I doubt the interviewers meant to measure whether or not this
person had done enough interviews to catch on to the style of questions that
are currently trendy, but that's what they actually measured.

I think the most common objection to this is that the point of these questions
is to drill down and figure out how the person really thinks, but in empirical
studies on interviewing, they find the actual evaluation of chatty questions
like this is heavily influenced by all kinds of biases. Techniques that have
more clear-cut evaluation criteria, like work sample tests, and even
completely non-technical interviews like behavioral interviews end up being
better filters. Even then, the filtering isn't "good" (IIRC, the last time I
read one of those studies, work sample tests score the best, and had a
correlation of around .5 with an ideal filter), but it's better.

For these kinds of questions, even if you haven't seen the specific question
before, there's all sorts of interview gamesmanship that helps tremendously.
One thing in the blog post, not spending an hour on requirements gathering, is
an example of that. In real life, if you're going to write an application from
scratch, spending more than an hour on requirements gathering is perfectly
reasonable for a lot of problem domains. But if you're playing the interview
game, you know that you have, at most, an hour to sketch out the entire
problem, so you have to cut the requirements gathering phase short (but not
too short). The post mentions that this gets at real skills. That's true. It
does. The problem is that everyone who's seen this kind of question five times
is going to be good enough at the interview gamesmanship that they don't need
to have good real skills to breeze through the "don't spend too long talking
about requirements" sub-filter.

~~~
melvinmt
The paradox is that the best programmers tend to be the worst at interviewing
(because they usually get hired quickly) and the worst programmers gradually
get better at interviewing (after doing lots of them).

------
pearjuice
I don't have been to coding interviews recently but is this what it is like
these days? How long do these questions generally take to complete? When I
hear white boards, UML diagrams and OO-design I am thinking about investing at
least a few hours.

Back in my day there were no interviews like these. You just dropped your CV,
had a chat with the guy and if it clicked you got a contract with a month on
(paid) trial. When I hear things like this I am thinking about all the people
who are investing an (unpaid) day (sometimes even recurring interviews, what!)
solving questionnaires with no real context during the job.

Is it really this bad?

~~~
rhc2104
Paid trials also work (for example, I was a contract-to-hire at my current
job).

But many people don't want to leave the security of their current job for a
temporary contract, so you would need to spend more time vetting those
candidates.

~~~
veb
New Zealand has this law, in which new jobs have a 3 month 'trial period'.
(unless specified otherwise in the contract). So if someone's hired and it's
clear they cannot code or interact well with the team they can be let go as
long as it's within that 3 month period.

Personally... I don't like it. But I do understand the logic, and how it helps
businesses from making expensive mistakes in regards to hiring.

------
malyk
I just spent a few months interviewing developers in all career stages. I ask
a problem in a similar vein that's designed to get both of us up in front of
the whiteboard working out the design of a problem together. In those 20+
interviews I've seen all kinds of answers to the problem, some bad, some ok,
and some pretty good. I can learn a ton about you as a developer with this
question. And almost without fail the candidate ends the interview with
something along the lines of "that was a fun problem to work on".

I combine that problem with developng a simple end to end feature together and
the combination of that with a high level design problem turns out to be a
really good indicator of how someone actually performs on the job.

------
danso
Probably should have checked before posting...this was discussed 4 years ago:
[https://news.ycombinator.com/item?id=2062889](https://news.ycombinator.com/item?id=2062889)
(so I guess it's eligible for re-discussion)

I stumbled across it doing a Google search for "interview question elevator
design"...I haven't been asked in a technical interview about how I would
implement the logic for an elevator controller, but I heard about the question
second-hand at a college job fair...and since then, I still think about that
question. In fact, I think I've thought about it almost every time I've ever
waited for an elevator in New York (that, and the story of the poor woman who
was crushed while stepping into an upward-shooting elevator in Midtown a few
years ago)...so...4 times a day, times 6 years...and I still haven't come up
with enough optimal algorithms to cover all the edge cases and scenarios that
I come across :)

The Monopoly question that the OP mentions is good, but I think is a bit
problematic since not everyone has played Monopoly. And not everyone is
familiar even with the standard rules. But everyone's been in an elevator
before, and virtually no one thinks about how complicated an elevator's
operation might be: it's one of those incredible, life-changing inventions
that you take for granted after the first time you've pressed a button. So I
think it's great material for an open-ended technical question.

The single-elevator logic is convoluted enough: If the elevator is going from
bottom floor to 10th floor, obviously it should stop if someone on the 5th
floor signals their intention to go up. But what if, after the 1st floor door
closes and the elevator starts moving, a 2nd-floor person wants to go up?
What's the cutoff in last-second button pushes to prevent the elevator from
too abruptly stopping?

And of course, the more complicated logic is if someone on the 5th floor press
_Down_ while the elevator is heading up. Then you have to implement a queue
system. But simple FIFO may not be efficient...if the elevator is moving up,
and someone on the 5th floor presses _Down_ , and then, someone on the 7th
floor also presses _Down_...it would seem that the elevator should stop at the
7th floor first, on its way down.

And then things get really complicated with even just one more elevator,
particularly with race conditions. If both elevators are moving up, and a 5th
floor signal for "Down" is followed by a 7th floor signal for
"Down"...ideally, the first elevator to finish its _Up_ job will take the 7th
floor...Should it also take the 5th floor _Down_ job? Or let the other
elevator handle that? And should that decision change if the 7th floor person
signals their intention to go to the 4th floor, whereas the 5th floor person
most likely just wants to go to the bottom floor?

Beyond the interruption/queuing logic, there's a lot of interesting discussion
about how the elevators should be positioned during idle time. Presumably,
they should return to ground floor in the mornings, and stay near the top (or
at least midway) during the beginning of lunch, and the end of the day.

What I like about the elevator question is that elevator algorithms are their
own science. But a lot of the complexity can be realized just by taking the
time to think about all the scenarios you've encountered as an elevator user.
And so given the typical technical interview situation, it's a good test of
the candidate's reflection, ability to ask questions of the requirements, the
ability to apply heuristics for good non-optimal solutions, and the ability to
not let edge-cases dominate the thinking.

~~~
ant6n
I lived in a building (6 floors) where the elevator appeared to be always in
one of four states: Door opened, going to floor n, waiting for input inside
elevator, waiting for input from anybody. It only remembers a single floor -
where it's going now. Once it goes into the input state, it's a race among
everybody who wants to take the elevator to push the buttons.

I was never quite sure whether the 'waiting for input inside elevator'
actually existed, because every once in a while the elevator would get
summoned by someone else before I could give it a destination when inside.

I guess this is a bit off-topic, it's just to say that even very simple logic
can solve the problem, in a possibly infuriating way. ;)

~~~
justizin
Yeah I'm pretty sure the elevator, at least that old one, doesn't know if
you're in it, though more modern ones will open the door as you walk up.

------
bahmutov
I ask a JavaScript developer to debug a small problem and then come up with
functional approach to solve it. Makes for good step by step exploration. Each
step can be expressed in single English sentence and then coded directly into
JavaScript. Much more precise than designing OO hierarchy.

[http://bahmutov.calepin.co/functional-javascript-
interview-q...](http://bahmutov.calepin.co/functional-javascript-interview-
question.html)

~~~
illicium
Designing a system architecture (Monopoly question) and solving a practical
coding problem are different skillsets, so ideally you would ask the
interviewee both types of questions.

------
ignoramous
related:
[https://news.ycombinator.com/item?id=8399767](https://news.ycombinator.com/item?id=8399767)

actual blog:
[http://www.gamasutra.com/blogs/MarkMennell/20140929/226628/M...](http://www.gamasutra.com/blogs/MarkMennell/20140929/226628/Making_FastPaced_Multiplayer_Networked_Games_is_Hard.php)

------
supsep
I beg to differ, Monopoly can be done using 'simplistic' object design. An
array is the monopoly map, a user is an object and the bank is a singleton.
Done.

~~~
pearjuice
supsep, you are a great candidate but unfortunately you don't seem that great
of a fit for our Abstract Enterprise Java culture. I am sure there are a lot
of other companies who adhere to your mindset!

~~~
cunac
true, some of us prefer real money (enterprise money) and some startup options
(monopoly money). Go figure which one will feed you :-)

