raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Monday, June 12, 2006
  My favourite interview question


Some years back, I was interviewed by an interesting start-up in Palo Alto. I was really tempted to take their offer, mostly because:
  1. One of the interviewers was an avid Ultimate player;
  2. Stanford. In walking distance. (And the regular Stanford Friz-ball variant game);
  3. They asked me a question which has become my favourite interview question to ask and to answer.
The question they asked was:

How might you design a program that lets people play Monopoly with each other over the internet?


Of course there’s a lot to be learned on both sides when an interviewee is asked to design something and explain their design. Both parties learn a lot about each other’s communication styles and approach.

It works both ways: for example, if I were sketching out a design and the interviewers repeatedly interrupted me to discuss my UML notation, I could infer certain things about their culture.

Those kinds of issues apply to any reasonably sized design problem. Anything larger than, say, “write a procedure that reverses a string in place.” But let’s look at three of the characteristics of the game of Monopoly that I find attractive for this exercise:
First, Monopoly is poorly defined. Chess, for example, is rigorous. The official rules of Monopoly are silent on some critical questions and vague on others. A tournament-playing aficionado will realize this immediately, but it’s easy to guide a candidate to this realization by asking some of the well-known FAQ questions.

This ‘problem’ makes it a great interview question. It drives a lot of valuable interaction between the candidate and the interviewers. You have to ask questions, make assumptions, and know when to stop gathering requirements and start driving the design.

There have been some blog posts pointing out that even trivial requirements can have many hidden implications. A determined and finicky developer can drive questions for the length of the interview. I think Monopoly’s missing requirements actually improve its suitability as an interview question.

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

Another good way to move forward for both interviewer and candidate is to say, “ok, we’ve covered the most important requirements. Let’s make a bunch of assumptions and document them. In a real-world situation we could obtain feedback on the assumptions after presenting an initial approach.”

After all, who’s to say that a programmer, designer, or architect is always 100% beholden to others for requirements?

The second reason I like this problem is that Monopoly requires more than just a simplistic object design. What I’m about to say will be blindingly obvious to the Enterprise crowd (sorry, not you over there with the Greasemonkey script that translates your web email to Klingon). 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.

Now let’s talk about ‘object-oriented programming’ for a second. 99% of the stuff you read discusses modeling real-world physical objects. Things. Nouns. It is a Kingdom of Nouns. Most candidates start every design by dutifully listing all of the nouns they can think of and then they spend the rest of the time available thinking about piling them into phyla, hierarchies of “IS-A” and “A-KIND-OF.”

This approach, which I will call “noun and verb,” is so limited I’ll dare to call it brain damaged. In fun. But seriously, competent software developers spend much more time on relationships, responsibilities, and constraints than they do on trying to prematurely optimize reuse through inheritance.



Object Design: Roles, Responsibilities, and Collaborations focuses on the practice of designing objects as integral members of a community where each object has specific roles and responsibilities. The authors present the latest practices and techniques of Responsibility-Driven Design and show how you can apply them as you develop modern object-based applications.

Now let’s ask a question about Monopoly (and Enterprise software). Where do the rules live? In a noun-oriented design, the rules are smooshed and smeared across the design, because every single object is responsible for knowing everything about everything that it can ‘do’. All the verbs are glued to the nouns as methods.

Let’s take a look at a simple rules question. If a player owns Baltic Avenue, can she add a house to it?

Well, there’s a bunch of stuff about whether she can afford it and whether there is a house available in the bank. Where does that live? In the bank object? And there is a bunch of stuff about whether it is either the player’s turn or between turns. Where does that live?

And there is a bunch of stuff about whether the property already has four houses. Where does that live? Somewhere in the property hierarchy? Sounds reasonable. Now what about mortgaged property? If Baltic is mortgaged, the answer is no. That’s easy. But what if Mediterranean Avenue is mortgaged? And what if, for example, Baltic has one house but Mediterranean has none? Where does that logic live? Both of these last two questions involve knowing something about the other properties of a colour group.

Now you can debate which verbs belong to which nouns, but here is an opportunity to step back a bit and consider the larger implications of maintaining such a ‘classical’ OO design.

Consider a ‘noun and verb’ design. First, an easy question. How well does the design document the actual game of Monopoly? If someone were to read the source code, do you think they could learn how to play the actual game?

Is this a stupid question? I think it strikes at the root of sustainable software development. In real world applications, software lives for a long time and teams change over that time. Programmers are often asked to maintain software with insufficient training in its intended use.

OO programs can be brilliant communicators in some designs (“here’s everything I need to know about a Money Transfer”) and terrible in others. I think this is part of the appeal and effectiveness) of the Domain Specific Language approach. It does a better job of communicating its intentions than a simple OO design.

I’m not saying that a DSL is right for Monopoly. Or wrong. Just that it’s valuable to consider this issue when discussing an approach. There is a lot of opportunity for a candidate and the interviewers to learn about each other’s thinking that goes way beyond coding if you spend a few moments discussing the importance (or irrelevance) of a design that communicates its intentions. And I think that makes Monopoly a good design subject.

Another issue about the rules. In software development, requirements often change. What kinds of requirements changes are easy with the design? What kinds are difficult?

I suspect it’s easy to change the prices and names of properties, but very difficult to change the fundamental rules. Well, it’s probably easy to introduce the popular ‘lottery’ variation where fines are paid into a pool and anyone landing on Free Parking’ scoops it up. But some of the more esoteric variations would require making lots of changes to many different classes.

The ‘noun and verb’ design is tightly coupled, and distributes the rules across the design. If you really want a mess, consider that popular computer versions of Monopoly allow you to pick and choose rules variations for each game.

The key to making this easy is to find another way to represent the rules. I generally provide hints along these lines by asking the candidate how they plan to implement the Chance and Community Chest cards. What is the relationship between the cards, special squares like “Luxury Tax,” and introducing variant rules?

(You can probably save yourself a lot of interview time. Instead of all this hoopla, ask the candidate to describe when they have actually used the Strategy, Visitor, and Command patterns outside of a framework.)
The bottom line is that designing a Monopoly game requires giving a lot of thought to representing the rules. There are a lot of ways to do that. I’ve hinted at two, and you I’ve heard of a lot of other interesting approaches. It’s a great chance to really go beyond OOP 101.

Now to close as rapidly as possible with what I consider an essential characteristic of a good design problem, and one that applies here. Monopoly is too large to solve in one interview. This is related to the vague requirements characteristic I mentioned above.

The reason this is important is that it forces the designer to pick and choose what elements of the design to solve in limited time. Some candidates will fail outright because their problem solving style is to consider all of the implications before starting. It’s easy to spend hours on a problem like Monopoly. But will you get up and apply the marker to the white board?

>Does a candidate start with the trivia? Who cares how to represent the colour of a property? CSS? A getter in each object? Yawn. I’ll prod him to move along.

Perhaps a candidate spends all of her time working in an area of the problem she knows well. Some candidates can spend forever engineering a Monopoly Online site up to Web 1.0 scale. Or building FTD.com-like reliability. Whatever.

I’m not saying that’s bad. Or good. But I will say that given a problem too large to solve in the time allotted, there’s fantastic value in evaluating what’s important. And that cuts both ways. If you think that some of the OO design choices are critical but the interviewers hand wave it and want to see how you plan to handle 10,000 requests per minute, that’s revealing.

Summary

I like asking (and being asked) about Monopoly because it provides fertile ground for discussing issues that are critical to judging both competence and cultural fit, like:
And now, if you have a moment, I’d like to ask for your feedback. Is there a better design question to ask? What is your perspective as an interviewee? What other issues about a design should be discussed during an interview?

I’m looking forward to hearing from you. Thanks in advance!

Update: A cautionary note

Some people have objected to this question because it may be a trivia challenge: how well does the candidate know the game of Monopoly? In the comments I mentioned that the question really only applies to candidates that already know the game.

Others have suggested it may be a form of “guess the design I’m thinking of” where there is exactly one right answer, the design the interviewer has already come up with. I think this is a legitimate concern.

It really applies to any interview question. For example: “name your three strengths” or “tell me about a challenge you faced in your last position and how you overcame the obstacles.” If an interviewer is looking for something specific, they can and will twist any interview question into a variation of “guess the answer I’m thinking of.”

I won’t say that Monopoly is somehow better than other questions in this regard, nor is it worse. If you have an interview based on reviewing a candidate’s past accomplishments, don’t you think there are some interviewers that will discount those that don’t fit their personal criteria for merit?

I once had an interview where the interviewer spent forty minutes talking to me about my education, and something like fifteen talking about my fifteen years (at that time) of actual career experience. Bias in an interviewer is orthogonal to the choice of interviewing technique.


What do these two cautions have in common? Only that the most important thing for a successful interview is that the interviewer be genuinely seeking out a view of the candidate’s strengths and weaknesses. All I can really say about this question is that if (and it’s a big if) the interviewer is sincerely attempting to evaluate a candidate’s technical ability, and if the candidate has some familiarity with the game, then the session can be very productive.

Update: Some relevant links

It would be ludicrous to think of hiring a juggler without first seeing him perform. That’s just common sense. Yet when you set out to hire an engineer or a designer or a programmer or a group manager, the rules of common sense are often suspended. You don’t ask to see a design or a program or anything. In fact, the interview is just talk.


Hiring a Juggler


The bottom line in my interviewing technique is that smart people can generally tell if they’re talking to other smart people by having a conversation with them on a difficult or highly technical subject, and the interview question is really just a pretext to have a conversation on a difficult subject so that the interviewer’s judgement can form an opinion on whether this is a smart person or not.


The Phone Screen


Think of three things you want the interviewer to know about you that you think they are unlikely to find out if they ask all the questions. The important ideas are that (a) you want the interviewer to know about each of the three things, and that (b) the interviewer is unlikely to ask about all three if you don’t exercise some control over the interview.

Take control of your interview


In case you didn’t know this, about 1/3 of all technical interview questions worldwide are variants of “How do you fit 10 pounds of crap in a five-pound bag?” Examples: how do you reverse a string in place, how do you sort a billion numbers, how do you write a decent compiler back end for an architecture with only four frigging registers, how do you handle fair scheduling when someone just forked off 1000 copies of some Towers of Hanoi simulation, etc.

Interviewing Ruby programmers


I’m exaggerating a lot, but the point is, when you select 1 out of 200 applicants, the other 199 don’t give up and go into plumbing (although I wish they would… plumbers are impossible to find). They apply again somewhere else, and contribute to some other employer’s self-delusions about how selective they are.


Joel on Hiring


And then there is the issue of why would someone care if I knew how to write a file copy function, ahead of what the difference between an interface and an abstract class was. Or when would I use encapsulation? Or in my design, how would I choose between polymorphism or inheritance? Or what pattern would I recommend for dealing with a general or specific problem?


What’s with the programming test!?


I know lots and lots of interviewers, at many companies, who’ve decided that they can fully evaluate you based on whether you can solve some particular convex optimization problem (or graph-search problem, or logic problem, or whatever their pet Elephant Question is), and they ask every candidate this question regardless of their background or experience. In fact, I’d estimate that some 10% of all technical interviewers ask the same questions, year after year, and they could care less about your experience.

The Truth About Interviewing

Labels: ,

 

Comments on “My favourite interview question:
I've played half a game of Monopoly in my life, and I was too drunk and sleepy at the time to pay much attention. If you asked me that question, you'd then have to spend much of the subsequent interview explaining how to play the game to me. Which could in itself be interesting, but it would stress the requirements capture part of the question a bit more than you probably want.
 
I forgot to mention that the prelude to the question is "Are you familiar with the game of Monopoly?"

If you don't know the game reasonably well, there isn't much point in this specific question.

But don't worry, there are others, oh boy are there others :-)
 
It's really hard to identify competent programmers. I like your approach however I think it's too involved for an interview - unless the candidate is going to be there for hours.

I've had success with identifying a hobby that the person has and then getting them to describe it in detail. Woodworking is a good one for getting to know how they think, how successful they are, etc.

A mechanic friend of mine said that one of the best way he has for determining how good a mechanic someone will be is to hand the person a broom and see how he/she cleans the floor. I haven't tried this one yet but I think it may work with programmers who know how to operate a broom.
 
There's no doubt in my mind whatsoever that no-one should be hired without hours of interviewing. But that's another topic, and one that is very well covered on various blogs.

What I would say is that perhaps this shouldn't be a weeder question. Hopefully you've already phone screened a candidate and conducted some other good interview stuff.

Now you've already determined that the candidate is competent and you want to know whether they have star quality architecture skills.

When I was asked this question, I had already passed a phone screen and a long phone interview. I was then flown to California for a day's worth of interviews with the team.

I also recall an entertaining math/logic puzzle I had to solve. But it was really an "aha!", so I don't ask it.
 
A much better (IMHO) question is: "design a control system for an elevator." This has the advantage that (a) everyone is very familar with elevators, (b) there's lots of interesting quirks, such as having more than one elevator shaft, and (c) it's far, far more difficult than it seems at first.

Doesn't sound too hard? What if the elevator is on the first floor, has just been called to the fifth floor, and someone on the third floor presses the down button? The elevator should not stop on the way. (!)
 
I was once asked to design software that simulated a soda vending machine. It covers basic rules and object design, and isn't as complex as Monopoly.

It is always a good idea to ask if a developer has used patterns like Command or whatever outside a framework. Few developers know patterns, fewer know how to use them, and the one you want to hire has used them effectively.
 
(c) it's far, far more difficult than it seems at first.

That's part of what I like about Monopoly. But I totally agree about elevators. The game "SimTower" was born when the author became interested in the heuristics needed to make elevators work efficiently in tall buildings. There's a lot of strategy involved.

I was once asked to design software that simulated a soda vending machine. It covers basic rules and object design, and isn't as complex as Monopoly.

I really prefer to hit on at least one issue orthogonal to the obvious physical entities. It's not immediately obvious to me whether a Soda Machine has this characteristic. But maybe I'm just failing the interview :-)
 
Interview questions like that are generally a good way of discounting qualified people who don't happen to have an *immediate* knowledge of Monopoly (or whatever other 'clever' topic you pose).

I've seen variations of this flawed interveiwing technique such as "You have 30 minutes, now code a fully-functional calculator."
 
This tip is dumb - finding a good programmer through an interview process is an art form, and not something can always be determined from an interview - the problem with interviewing is that the interviewer is usually done by dumbazzes.
 
Interview questions like that are generally a good way of discounting qualified people who don't happen to have an *immediate* knowledge of Monopoly

See my comment above: I forgot to mention that the prelude to the question is "Are you familiar with the game of Monopoly?"

Once again, don't worry, there are others, oh boy are there others.
 
Just out of curiosity: is there something I wrote that implies that this is the only question I ever ask while interviewing?

I also ask situational questions, I also ask for someone to write some actual working, debugged code, I also ask for someone to solve a logic puzzle, and on and on ad nauseum.

This just happens to be my favourite question.
 
I hire programmers by asking programmers I know and respect who they would recommend. The people recommended need to have worked with the person making the recommendation.

There is a lot more to building a successful development team than being able to design something in an interview (such as interacting with others). Some people are actually very good but freeze when first assigned a design.

They work on things using their subconscious mind and they can have a great answer for you ten minutes after the interview is over.

I do like the find out what books a person owns (technical and non-tech), what movies they like and why, do they play a musical instrument, do they try out new programming languages for fun, etc.

Overall, I look for interesting people with the obvious skills/experience needed, intelligence, curiosity, and drive. Anything else can be picked up on the job.
 
There is a lot more to building a successful development team than being able to design something in an interview

Of course. Is there anything in the post that suggests otherwise?
 
Like others have commented, I'm embarrassed to say that I'm not very familiar with Monopoly!

However, I do feel that these types of questions may tell you more about how well a person's brain works under pressure rather than whether or not they'd actually be a good programmer, or even a good architect.

I've also found that, sadly, many people seem to study for these types of questions, including general patterns-and-practices topics.

I've been thrown many times interviewing people for web developer positions who were great at these questions, yet always left me feeling uneasy about their actual abilities, and sure enough I've been burned before.

I now always ask them the one question that nobody ever seems to have a scripted response for:

"Can you make a website?"

You'd be amazed how many people applying for web developer questions are completely thrown off guard by this question. The first responses are usually "huh? what? um.. what do you mean?".

"You know: a website. Can you make them?"

Then the candidate will usually bite "Um... you're going to have to give me some specifics."

Of course then this continues for a bit, but I only dish out as little specifics as possible.

Usually from this line of questioning, I've found that it's both much easier to find out if they can both grasp high-level concepts like architecture, as well as actually develop something, rather than questions like "how would you reverse a string...", etc.
 
Of course. Is there anything in the post that suggests otherwise?

Uh, yes? Like the entire premise that asking a question such as the "favorite question" is actually useful?
 
As an employee applying for a Project Management position, I was asked to document the requirements of building a Peanut Butter and Jelly sandwich.

I was given 15 min.

I also had the chance to review answers back from other job candidates for similar positions later on.

Similar to your example, I liked it because it revealed a lot about the candidates, and as an interviewer, it's nice to have a question that demonstrates skills.

One feels one is judged a lot more on merit.

An interesting side note, I've noticed that the decision on who was going to be hired was decided long before this question was asked and the answers read.

It became more of a "Where exactly does this person fit?" and "What projects should we give him" sort of question
 
Like the entire premise that asking a question such as the "favorite question" is actually useful?

Just because I assert that it is a useful question does not imply that I assert it is the only useful question.

As to whether it is useful, if you do some googling you will find there are many dissenting views. There are also people who challenge whether it is useful to pose logic puzzles, or useful to ask someone to write code in the interview. And I do all three of these things.

I do not assert that this type of question is infallible. My experience is that it does present some false negatives: good people who don't "interview well."

However, I have found it to present few false positives: I have not met a lot of people who do well with this type of question but cannot design software in the field.

That being said, there are many complex dynamics involved in building a good team, and that is why I believe that to select a core person I need a long process involving many different types of investigations.

And yes, references from people I trust are some of the better indicators.
 
many people seem to study for these types of questions, including general patterns-and-practices topics.

And this is bad because...?

I have found that candidates (myself included) are quick to mention their experience when engaging in a spirited discussion about the merits of a design choice.

If I mention a rules engine, for example, some candidates are only too happy to talk about how they tried that on such-and-such a project and what happened.

Overall, I'm conent with the idea that people will study for an interview. If I wasn't, I wouldn't publish my favourite question :-)
 
I was asked to document the requirements of building a Peanut Butter and Jelly sandwich.

Another well-known problem is to designa spice rack for the visually impaired.

Stuff like that makes me wish I'd studied Industrial Design. We have two terrific schools here in Toronto, OCAD and Sheridan, and I'm jealous of the cool stuff the students do every day.

The annual engineering problem at OCAD is to use a single piece of paper to somehow keep a raw egg from breaking when dropped from a balcony.
 
And this is bad because...?

Well, your rules engine is a good example because in that scenario you say that the candidate related it to an actual project he worked on.

A bad example is when a candidate studies for these type of questions and can talk about them all day "in general", yet they may not be able to actually apply it to a real world situation.

I always try to avoid questions to which I think the candiate could give a scripted response, and instead try to think of questions which they could only answer if they had the experience, in addition to the book knowledge.

An example I like to use is asking the candidate how they would program the front page of Amazon.com. Again, this gets them into high-level concepts such as overall architecture, performance requirements due to the traffic of the site, etc.

However, I can also drill them in detail such as how to create stylesheets or how to make different components of the page re-usable, if I feel that they are answering my questions with too much "fluff".

I feel it's difficult to do this when the topic is something that is too far from a real-world environment, such as the Monopoly or elevator examples.

For web development, questions like "Make Amazon.com" or "Make ebay.com" tend to be good examples because a) Everyone knows it, and b) You can ask both high-level and specific questions that relate to your position.

For application developers I would probably ask questions like "How would you make Microsoft Word?". It still gives you the flexibility of the Monopoly example but you get the added benefit of being able to drill them down if you feel they are reciting a bunch of buzz-words they studied on somebody's blog :-)
 
During interviews I'm only interested in two questions, and they are questions that I pose to myself:
1. Are the "lights on"? In other words, is this person responsive?
2. And, is this someone that I want to work with? Because no matter how brilliant they are I don't want them around if it's going to be a strain to be in the office. Are they abrasive, or have poor hygiene?

I usually know the answers to both of these questions in the first few minutes, and then it's just a matter of getting to know them.

BTW, I consider fondness of UML and design patterns as a negative point, but I'm willing to ignore these bad habits if it's a nice person.
 
A bad example is when a candidate studies for these type of questions and can talk about them all day "in general", yet they may not be able to actually apply it to a real world situation.

First, great comment, thanks!!!

I do not ask candidates to "talk in general" about approaches. Let's say, for example, that a candidate seems to think for a while and then says "this is a good place to use a DSL."

"Ok," I smile. "The whiteboard is waiting." The acid test is whether the candidate can (a) design a decent DSL for Monopoly, and (b) design an architecture for implementing the DSL.

If someone is able to read a few blog posts, google some terms, and then hoodwink an interviewer, then either they are very, very bright or there may be another explanation.
 
What do you mean (or what did the interviewer mean) by "referee the game"? Do the players ask questions of the referee in a natural language? Or is the game being played on the computer, so that the referee just has to put up a message when a player tries to do something illegal? What about questions such as the one in one of the FAQs: "Can a player borrow money from another player?" If the referee is just quietly watching the game play, how would it ever know about such borrowing? Perhaps it has to know about any transaction that affects any player's bank balance (er, money stash), but how do I say "borrow from Harry" to the referee?

Solving the stated problem is, I suspect, overwhelmingly dependent on the details of the environment in which the program must operate. I guess one could design a "next action" panel in which all the possible actions for the player at a given time are specified. But in that case, the referee function has already been performed in the process of showing the valid next actions.
 
Solving the stated problem is, I suspect, overwhelmingly dependent on the details of the environment in which the program must operate.

First, it isn't really a 'problem to be solved.' I don't treat it as an exercise in 'guess the design I'm thinking of.'

The questions you pose are part of the requirements gathering process. The important thing is to ask the questions and to proceed with a design that is reasonable for whatever constraints the interviewer imposes in response.

JM2C, but if I wrote the whole thing out as formal requirements, a lot of the value of the problem would go away.
 
@Reginald Braithwaite - the logic question you linked to seems to have only half the answer.

http://www.techinterview.org/Solutions/fog0000000095.html

It doesn't seem to say anything about doors which are prime numbered. These should also be open. Just one more reason why I hate these logic puzzles. I don't feel that it tells you anything about a person other than they are good at logic puzzles.

http://www.kirit.com/Interview%20by%20under-constrained%20programming


K
 
In the same way that people nominate interview questions as a good way of revealing characteristics of the person being interviewed, the question reveals characteristics about the person asking the question. Favourite questions are ways for people to find other people like themselves, rather than whether they would have been a good fit in the team.

The only way of finding out whether someone would be a good fit in the team is to hire them, and find out with actual practical experience. As this is, in turn, not a practical approach, it would be more honest to simply note that such questions are filtering methods rather than identification methods.

It's pretty obvious when someone's trotting out a favourite interview question, and I can assure you that the answer has a hell of a lot more to do with stabbing in the dark for the precise answer that they're looking for, than actually solving the question.

It's a process of 'hunt the button', as the fact remains that there are numerous correct answers, of which a set of those correct answers is not going to be understood or accepted by the person asking the question!

This is a particular problem for me, since my answers tend to be lateral and mistakenly assumed incorrect, when in fact it's precise and would work just fine.
 
It doesn't seem to say anything about doors which are prime numbered. These should also be open.

Are you sure? Perhaps you could write a brief simulator to see what happens.

For example, two is a prime number. Is the second door open or closed?
 
the answer has a hell of a lot more to do with stabbing in the dark for the precise answer that they're looking for, than actually solving the question.

This is a danger with any interview question, such as asking what books they have read recently or how they would handle a hypothetical on-the-job situation.

Is Monopoly is any worse for this than other design or programming tasks? Or is the very concept of 'design this' or 'program that' suspect in your view?

Quite possibly, the fact that the question is a favourite may be the characteristic that makes it inapproriate for me to ask.

Sometimes a favourite question comes with the emotional baggage of how the interviewer thinks the question is best answered.

I personally don't think there is a "best" answer: I'm biased towards candidates that suggest there are many right answers and who can discuss the merits of different approaches given different requirements and expectations.

p.s. Maybe I would be more effective asking about elevators while Robby asks about Monopoly?
 
"I think this is part of the appeal and effectiveness) of the Domain Specific Language approach. It does a better job of communicating its intentions than a simple OO design."

Please give a concrete example. What is the difference between a DSL and a library? How would the rules not be spread across the DSL?
 
Please give a concrete example. What is the difference between a DSL and a library? How would the rules not be spread across the DSL?

Is that your favourite interview question?

I wouldn't rely on my answer for a really good introduction to the subject. You might want to look into Ruby on Rails as a very popular example of a framework with is DSL-centric. How does it differ from frameworks that are library-centric?
 
I was once asked to describe the process of making a cup of tea. After explaining that I didn't drink tea, I thought it best to describe the process of making the worst cup of tea in human history. This way, the drinker would be warned that a non-tea-drinker is not a good maker.

I managed to make the interviewers laugh while indicating the appropriate steps. I got the job.

Rob Lang
 
This is a great discussion because it gets at the huge question of what quality software is. And we want to know if a potential coworker knows what that is.

I do not want a programmer who makes an excuse of not being an architect. That programmer will soon be creating random classes and methods with no cohesion and coupling all over the place.
 
Sometimes a favourite question comes with the emotional baggage of how the interviewer thinks the question is best answered.

Yes, that is the point I was making.

Another approach would be to ask questions about problems neither of you know about, and see how well you work together to solve the problem.

I've had a read through your web site, and appreciate the honest effort you're making to present and understand problems. Very enjoyable read.

It's a bit hard to have a converation through a web page though, as I had to make a specific effort to bookmark and check back to see if you had responded.

Not sure how to solve that one, except wait for the Web to re-invent the mailing list. :)
 
Great article!

but you've never played monopoly with a real band of cut-throats like myself and my family - bailing out mortgages and then tripling the rents - forming allegiances against other players and then double-crossing - rent-splitting, private loans with interest... !
 
Interesting article. One of my favourite things to find out in an interview is whether the candidate is capable of saying "I don't know". It's amazing how many people just will not say those words. The one question that seems to trip up most people who claim to know databases and SQL is "What is the HAVING clause used for in SQL"?
 
Something that I have picked in the many interviews I have conducted over the last year is the difference in approach when someone is confident in themselves even when the territory is unfamiliar. Poor candidates will waste time wafting on about anything but the question where as a strong candidate seems capable of getting to the point quickly or asking a pertenant question that will direct the conversation. Poor candidates will rarely say "I don't know".
 
I've been asked this very question in an interview a few years ago. We went through 5 variations of "requirements" within 20-30m, which indicated how malleable the design was, etc.

One thing that comes out of such a question is how quickly someone can think on their feet, and do they have a portfolio of experience to draw on to at least start a discussion quickly. (It's an interview, not the design stage of the best product ever)

That said, the most evil variation was along the lines of multiple players, each with a unique path through the "game board". That makes for some interesting rule variations on its own.

Lastly, a note on your blog site - how about some dates along with the timestamp? No idea how old/stale these postings are.
 
how about some dates along with the timestamp? No idea how old/stale these postings are

Good idea, I'll look into it. In the mean time, have a look at the URL for each post.
 
Holy crap, I'm not going to hire a coder who cannot reverse a string. This is something that is basic, and the ppl who cannot reverse the string I will send to you anonymous-3:53 PM :)
 
Holy crap, I'm not going to hire a coder who cannot reverse a string. This is something that is basic, and the ppl who cannot reverse the string I will send to you

Nothing in this post should be construed as suggesting that anyone who cannot reverse a string is worthy of employment as a programmer.

This is not the only question I consider asking, just my favourite.
 
Thank you for the post, I have heard that many questions asked during interviews are puzzle-like questions similar to one at http://www.technical-interview.com. I myself had phone interview with Microsoft and they ask me coding questions. I guess it all depends on the guy who is interviewing you.
 
I came to this blog since I was asked the Monopoly question for design. I thought it was not a question for developers and architects to be answering.

The Internet industry is now over 15 years old and we are still asking questions like Monopoly, and language syntax.
The question we need to ask is: "Can the individual solve problems or are they mostly glorified typists (coders)?". It is time for us to start asking questions of HR, Account and invoice problems rather than some games and syntax.

For example:
While walking in a forest, you come across a river and want to know how deep it is; how would you find out how deep it is ?
or ask question like:
"How would you design an application for viewing all invoices which are over due by 30 days?"

These should be the questions for IT professionals with > 5 years experience and have atleast 2 languages experience.
 
Rajeev:

The question we need to ask is: "Can the individual solve problems or are they mostly glorified typists (coders)?". It is time for us to start asking questions of HR, Account and invoice problems rather than some games and syntax.

I'm having a little trouble understanding your comment. Are you suggesting that Monopoly is a question to discover if someone is a glorified typist, and asking someone how to formulate a SQL query to obtain invoices 30 days overdue os a question for people with five years of experience?
 
Reginald:
I see how what I wrote can be understood as you said in your note. I meant to say we need to start asking more questions for experienced developers design questions which do not deal with games but with business problems.
Not a lot of people in the industry have game development and/or design experience.
However, I observe that it does not matter what one answers in most of the interviews whether it is a design question or implementation question. The main reason I make the comment in this paragraph is if the answer one gives is not the same the interviewer has then you did not pass according to them.
 
Rajeev:

s if the answer one gives is not the same the interviewer has then you did not pass according to them.

This is a very good observation, and a major problem with many interviewers. of course, it applies to business problems as well as to more abstract problems. Some interviewers have a pet architecture for business applications, and if you do not propose it, you “lose.”

For example, if they ask you how to build an invoicing application, they might be looking for very specific opinions about what logic belongs in PL/SQL, what logic belongs in a middleware server, what logic belongs in a "controller" layer, what logic belongs in the view, and so on. They might have extremely rigid ideas about whether an ORM is required, and if so, whther it is database-driven (like ActiveRecord) or object-driven (like Hibernate).

I think a good interview technique is one that reveals something about the candidate about you, while a bad interview technique reveals something about the interviewer.
 
I just tried the elevator question. I failed to engage the interviewee in the idea that this was an opportunity to run with this and show off what a great designer/programmer they were.

I think one needs to provide bounds on this question. I framed the question as: "Ok, the boss has hired you, and he walks in saying: 'We need to build an elevator controller.' Describe what you might do or ask to figure out what the boss wants, what the platform is, and the like. Assume the language is object oriented. Also assume the controller is receiving messages as text, and sends messages as text."

In addition to that, I think I also should have steered the interviewee to: A. Describe the state machine, B. map out the API, and C. Ask me or invent anything that furthers your description over the next 10 minutes.

Really, you are looking for anything that showcases an interviewee's abilities. The real goal is to engage them in that manner.
 
If you want good programmers then you need to look for attitude and interest as much as ability. If the attitude and interest is good they will learn/acquire whatever skills you require of them as soon as you point them in the right direction. We've all go to learn new stuff every few years anyway.
And if you want the best you'll need to go hunt them out because the best people never need to apply for a job; they've got employers chasing them. But that's a separate issue.
If someone has the right attitude and interest then asking how they do anything will tell you how good a programmer they are. If they do a good job thoroughlt, they're good; If they don't, they're not. It really is that simple. And if the employer doesn't understand that even the best candidate will need some time to 'bed in' to a new job the you'd better explain it, and why, in your interview and if they don't get it, leave quickly.
 
Commenting years later - just discovered this blog

The interview question I like most as an interviewer is one where I don't yet know the answer. There is always some unsolved problem or dilemma in our jobs - ask the prospect what they would do about it.

You'll learn very quickly how well they'll work with your organization at the problem-solving level in that problem domain.

When I'm the prospect this is the question I look for - if it's not asked I'll try to elicit something like it during the "anything you'd like to ask me" section of the interview.

Admittedly, this is because I'm much better in real, live, interactive situations than in canned and clearly artificial ones. So it may just be my bias.
 
All the people you actually want to hire, would never agree to an interview. Or fill out employment forms. Interviews are a farce. The people you want to hire, refuse to fill out an employment application, and work as contractors. You tell us the scope of the project, and we deliver the solution. None of this bullshit.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /