(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
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.
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.
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
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.
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.<
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.
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.
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?
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.
Comments on “Hiring a Juggler”:
<< Home
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.
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.
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 :-)
Uh oh, you're onto me!
But seriously, before I interview candidates I also Google them. But they still have to Juggle :-)
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
The Abstract Candidate
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....
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....
# posted by 
: 6:22 PM
: 6:22 PM
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.
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.
# posted by : 8:35 PM
: 8:35 PM
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.
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.
Ben:
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?
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
A programmer should be capable of searching and quick studying, but it seems the mentioned interview questions do not find this capability :D
<< Home
