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

Friday, July 07, 2006
  It's Friday! Who's having fun?

One of the things rock climbers like to say is "the best climber is the one having the most fun."

(Don't worry, this post is not going to go on for pages trying to explain climbing culture and then trying to draw some sort of tenuous parallel to software development.)

Here's one response to the How would you design a program to referee Monopoly? question:
What I love most about the Monopoly question is how it sucks me in. Maybe it's because I'm a gamer at heart, but my mind immediately starts racing through all the different possibilities. It's a little embarrassing to admit, but I'd love nothing more than to sit in a room with another programmer and hash this problem out.

Because it's fun.

Jeff Atwood, The Monopoly Interview

Now, I'm not going to tell you that I have some sort of crystal ball for telling you that the guy having the most fun with Monopoly has the most fun with programming as a whole. But you know what? I think it's a significant indicator. (More on why I am probably wrong below.)

One of the things I look for when recruiting is enthusiasm. This is no secret. Pick up any random book about success (or "life hacking" as people call it these days). That word pops up. Read any random biography about somone you admire. That word pops up.

I can't guarantee that a programmer who thinks programming is fun does more and does it better than a dour-faced individual who come in and just works with a Puritan "work == suffering" mentality. But look around. Don't you think employers are looking for enthusiasm?

Now does that mean Monopoly is a great question? No, of course not. Enthusiasm can and does come through when a candidate loves to talk about a design. But enthusiasm can also come through when a candidate talks about a problem they've solved in a previous position or talks about where they want to be in five years, or does almost anything else in an interview... when the candidate is enthusiastic about their chosen profession.

Now what about this quote:

If you're interested enough to ask me in on the basis of my resume, then let's have an interview, not play stupid games or do tests.
Obviously the second person just plain doesn't enjoy this kind of problem. It's not like she said "hey, that sounds like a lot of fun, but what does it have to do with my job?" But that doesn't mean she doesn't have enthusiasm for her work. Maybe the she hates solving design problems and hates writing code in an interview, but ask her about what she accomplished in her last position and her eyes will light up. I don't know.

Interviewers are pattern matching machines. Interviewers have in their head two lists: traits they associate with success and traits they associate with failure. Ideally (IMO), these lists are compiled from personal experience.

If an interviewer has met a number of people who consider solving design problems interesting and who have been very successful designing software, the interviewer will tend to select candidates that enjoy solving design problems in interviews. This interviewer likes Jeff.

Another interviewer may have the exact opposite opinion. They may have known individuals that go into raptures over the architectural options of a design but failed to ship quality software on time. Such an interviewer would weed such candidates out. This interviewer likes the second person.

There is little consistency between interviewers, even within one company. And I'm sorry to say so, but sadly it's true: the subjective things like what you think is important about software development mean so much more than the objective things like how many years of experience doing X a candidate may claim to have.

One great danger is interviewers who (rightly or wrongly) consider themselves successful. They are their own shining example of success. How can such an interviewer avoid selecting people who are just like them? They believe they are a walking example of the kind of person that will be successful.

It's very difficult to shake this, especially when an interviewer has some length and breadth of experience. It is hard to say "I'm not young enough to know everything" and to look at a candidate's potential with a very open mind. Even when their track record and their attitude towards your suggested line of interviewing are not what you prefer.

Given this mess, are we in trouble in our chosen profession? I don't think so. I'll tell you why I'm personally optimistic: my "circle of concern' is well-aligned with my "circle of influence." Or to put it in a triter way, you only need one.

When looking for a job, you only need the one perfect job. It's irrelevant whether you get job offers from half of the places you apply, three quarters, or just one. What you need are the following:
  1. The perfect place for you is hiring;
  2. The perfect place for you interviews you;
  3. The perfect place for you makes an offer.
You only need that one interview and that one offer. All other interviews and offers are actually waste by-products of your search for the perfect job.

So when going to interviews, you can afford to be choosy. By all means, if you hate stupid games, walk on out. That company isn't your kind of place. It will be full of people who are very different than you. They all got their jobs because they think that solving that kind of problem is fun. And if you like programming but you have to ask a hiring manager if they want to see you juggle, don't worry about getting an offer from that place.

Do you really think you'll have fun in a company where you don't have fun in the interview?

Here's the thing I've seen in my career: some companies do a better job of interviewing than others. But whether they interview well or poorly, the company's character and style are always front and centre on display.

If you walk out of an interview feeling enthusiastic about working in that place, you have a much better chance of enjoying yourself at work there than a place where you walked out feeling ambivalent.

After all, if you want to be the best programmer...

Wait for it...

You have to be the one having the most fun.



Comments on “It's Friday! Who's having fun?:
≴If you walk out of an interview feeling enthusiastic about working in that place, you have a much better chance of enjoying yourself at work there than a place where you walked out feeling ambivalent.”

Quoted for truth!

Really, this is the flip-side of the interviewer's ≴If you're feeling uncertain, that's a ‘no hire’.” If you don't feel good about the prospect, just say no.
A very good post (again!), which triggered many thoughts in my little boiling head. So I have tried here to explain what we do, as an employer, to fairly select our candidates.
Nice thoughts! I somehow feel that more and more companies are looking for the "ready to code from day one" kind of programmer. The interview questions are centred around API calls, which class, which method, how many packages etc etc. I think as some companies try to churn out project after project, their short term view forces them to hire people who are exactly job ready, at least in terms of skills. However, a successful company, especially in the tecnical sector, will continue to look for smart learners, who are willing to try new things on the job, AND who do not remember the last API call, which anyways google can bring up in 0.001 millesec.
Nice thoughts! I somehow feel that more and more companies are looking for the "ready to code from day one" kind of programmer. The interview questions are centred around API calls, which class, which method, how many packages etc etc.

Of course, nothing is stopping an interviewer from asking about API calls and determining whether a candidate is enthusiastic about programming:


Interviewer 1: What is the difference between has many and has many :though in Ruby on Rails?

Interviewer 2: What are the advantages of using has many :though in Ruby on Rails, and please give an example from you own experience when you chose has many :through instead of has many.
Hmm..I was referring more to

Qs: Which method would you call to sort the collections?
Qs: How many methods does java.lang.Object have?

and stuff like that. Which to my mind is oriented towards "information".
Which method would you call to sort the collections?

Perfectly fine trivia questions. All I'm saying is that it is easy to ask those questions and determine the candidate's level of enthusiasm in the same interview.

Of course, if the interviewer doesn't care whether a candidate is enthusiastic, that's ok too.

But if you're an enthusiastic candidate, would you really enjoy this kind of interview? Do you think you would enjoy working in that kind of company?

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

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

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

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?

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

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

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

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

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

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 /