Sunday, July 02, 2006
  Hiring a Juggler
Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.

Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.

OSCon 2005: Juggler, originally uploaded by x180 Courtesy James Duncan Davidson/O’Reilly Media.

Manager: Do you work with flaming objects?
Candidate: Sure.

Manager: …knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.

Manager: Do you have a line in funny patter that goes with your juggling?
Candidate: It’s hilarious.

Manager: Well that sounds fine. I guess you’re hired.
Candidate: Umm… Don’t you want to see me juggle?

Manager: Gee, I never thought of that.

“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, Chapter 15 of Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister.)

Update: Some relevant links

Of course, some interviewers are just looking for an excuse to talk about technical issues and will not prejudge you in any way. Speaking for myself, I would laugh if you wrote something like this out. But then again, I once worked for someone who had won the second International Obfuscated C Contest.
Don’t Overthink Fizzbuzz

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.
My favourite interview question

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 backend 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 “Hiring a Juggler:
For another perspective, have a gander at What's with the "programming test"!?.

He says: I asked him if the interview process also included an Object Oriented design test, or an algorithms test…nope, just the programming test. Riiiighhht!

I think there's a lot of common ground between these viewpoints. Namely, it is ludicrous to only administer a test. Tests are necessary but not sufficient. That's why many companies need eight or more hours of interviews to hire developers.

There's more than just testing, but there is some testing.
I don’t know about you, but before a candidate walks into my office for their first interview, I Google them.

Resumes just aren’t enough to determine depth and breadth of experience. It makes it much easier on me if a Google search produces a hit on a website or blog that contains coding samples and technical observations. I personally also like to see stuff about the candidate. It’s nice to know if they are involved in volunteer work and what their extracurricular activities are. In an interview you can’t really directly ask about personal stuff, but a blog will usually contain those little pieces of information that can provide a bigger picture.

I personally like to work with well-rounded individuals who I know have initiative. You can’t get that from a resume or even during the interview but from a blog...yes. I wrote a post a few months ago where I state my belief that if you want to be an engineering contender, you need to blog about technical stuff. Or at least find some medium to share and help others. Such as forums and articles, where your name is going to show up.
Before a candidate walks into my office for their first interview, I Google them.

Uh oh, you're onto me!

But seriously, before I interview candidates I also Google them. But they still have to Juggle :-)
Last link is malformed
Thanks Mike, I fixed the link.
Lest you believe that fifteen years of buzzword-compatible experience and an ability to intelligently discuss software architecture should excuse a candidate from juggling:

The Abstract Candidate
Hey, that's me juggling!

I'm a professional developer, and an unprofessional juggler. :)
I've been through many interviews lately, and I've come to few conclusions. I've been reading this and other blogs, and now I feel I'm ready to comment.

1. Big companies don't care about any of your experience. They interview fresh graduates and experienced developers all the same. Sorry guys, I'm pretty much tired of calculating the best floor to drop the egg off (and it's the same question in many companies). I hope that some time we can really talk about the projects I did.
2. Most companies ask design questions. That's ok, but the problem is that they ask questions about the problems they've encountered themselves and expect you to come up with the same answers as they did, taking into account the specific restrictions they had. I think this is wrong, because their solution might not be the best available and obviously you can't think of the restrictions they have in their project (their solution might be the best under the 100 restrictions they have but they don't tell you about it in the interview). It probably took them several weeks to come up with a good solution that accounts for all the possible problems. I'm sorry, I think I'm a good developer, but not a wizard, and I can't do it in 30minutes. Another example for such biased thinking is that in two interviews I was asked to implement a function that searches a string for one of possible characters given as other string (I don't remember its C name - I'm a more of a java programmer). At one company a simple solution that uses a 256 byte array was fine and was exactly what they expected. At another company they expected me to propose a solution that handles unicode characters as well (using a hash) and were not happy at all about the array solution.
3. In some companies I've received a written Java test. In a subset of them they had errors in their test. Were they kidding!?
4. Programming questions are nice and I like them. However I really hate writing programs on a piece of paper for two reasons. I'm used to write with a pen and I'm used to write code in several iterations. For example, I can start with checking for some preconditions, then in the middle of the algorithm think of a better idea and start changing the code I've already written. When using a computer (even notepad) there is no problem in doing that. Writing the code on paper makes a huge mess....

That's my 2cents and rants on interviews....
Thanks, great rant. These unnamed companies deserve your invective.
re: same question:
as an interviewer, i try to ask the same questions of all candidates to get an 'apples to apples' baseline comparison;
i also inevitably ask different questions, because each conversation elicits something unique, but i still want that baseline in the mix;

re: asking design questions:
i've also commonly asked candiates questions about design and other isses that relate to current projects -- after all, that's what they'll be working on; however, i dont measure their answer against my 'solution'; i try to evaluate on its merits and also to evaluate both the candiate's thought process and communciation skills.
Technical questioning fine.

Writing programs with pen and paper less so.

When hiring a surgeon, would you ask him to perform surgery in the interview?

When hiring a manager, do you ask him to "manage" a fake scenario with real people?

These are extreme examples but they make a point - make sure you know what you're testing.

...and as for Googling.

Seems pretty unprofessional to me.

There are a number of people with the same name as me, with websites and blogs.

To be denied a job because of some unconscious prejudice you had against someone else's blog would suck.

When hiring a manager, do you ask him to "manage" a fake scenario with real people?

I don;t know if you have any experience hiring managers, but this is a common technique (that doesn't mean it's optimum, but it does mean that it isn't laughably ridiculous).

When interviewing for a job, managers are almost always asked hypothetical questions such as:

"You have an employee with a performance problem, but he has been with the company for a very long time and has a strong reputation. What steps would you take?"

Would you consider this type of question unreasonable?
There are several kind of interviews, I think there is no size that fits all.

A programmer should be capable of searching and quick studying, but it seems the mentioned interview questions do not find this capability :D

<< 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 /