Archive for December, 2005
December 29th, 2005 by Mark Ramm
Today Joel Spolsky posted and article on his blog “The Perils of JavaSchools” in which he laments that people he interviews use Java to solve the coding problems he gives them in the interview rather than C or Scheme. This is a problem for him because “Java is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers.”
I think there are several unexamined assumptions behind this claim that won’t hold up when exposed to the light of day.
First, what does it mean to be a great programmer? Is it attention to detail and methodical testing? Is it the ability to hold complex systems in your head? Is it the ability to put yourself in the shoes of a user and really understand the problems they are trying to solve? My guess is that some great programmers have most of these gifts, but most great programmers aren’t great at everything. So if your hiring process only selects for one kind of greatness you are going to miss out on great User Interface Designers, great documentation writers, and all of those other kinds of greatness.
This leads directly to another assumption Joel makes: The problem is that we aren’t weeding out enough of the programmers who can’t handle recursion and pointers. But, he goes on to say that most programming, even most of the programming his company does, doesn’t require those skills. So, what he wants is for most programmers to be great at a kind of programming that most programmers will never get to do. Sounds like a plan a motivation disaster.
As far as I’m concerned greatness isn’t a singular quality that some people posses and others are incapible of — it’s a whole family of qualities, that most of us can participate in if we learn to find the work that lets do what we do best every day — and we focus on making our best better at every oportunity.
Chad Fowler has another take on what’s wrong with Joel’s implicit desire that more programmers would use C or Lisp to solve the problems presented in interviews:
“Why on earth would you want an interviewee to pick a difficult language? Thatâ€™s a bad sign!”
And I wholeheartedly agree. I want interviewees to choose the right tool for the job. They should choose the languages, libraries, whatever they need to make complex problems simple.
Not only that, but you should be auditioning programmers with the same kind of problems you expect them to solve on the job, and expect them to solve them in the same way. So if in an audition, somebody tries to write an RSS aggregator for internal use at a 200 person company that hand-parses XML in C, then I know something is wrong. The performance requirements aren’t there, and their time is too valuable to waste solving problems that have already been solved!
December 28th, 2005 by Mark Ramm
Over on Johanna Rothman’s blog she mentions that she was doing some training and discovered that people were interviewing with hypothetical questions rather than behavior based questions.
Many folks were asking questions of the type, “How would you…” instead of “How did you” or “Tell me about a time you did…” We practiced a bit so they could feel the difference in question type.
But she doesn’t explain why she prefers the how did you to the how would you. So, I think it would be worthwhile to talk for a bit about the advantages of both types of question.
Hypothetical questions can give you an idea of the way a candidate might respond to a novel situation, one which they’ve never faced before. They can also help you to get a view into the way that the candidate works through a complex issue to uncover their right path.
For instance you might ask a candidate “If you began to suspect, without any concrete proof, that a co-worker was stealing from the company, what would you do?” “Right” answers to this question might include:
report your suspicions to the boss
keep an eye out for more evidence
or to take that person aside and ask them about the suspicious behavior
The way they answer naturally can tell you something about the way that person thinks about theft, about trust and interpersonal relationships at work, and about authority structures. Depending on how your department/company works various points of view on any of these issues can be an asset or liability. The trick with open ended questions is to find questions where the best performers in that job consistently answer differently than the worst — and to know what answers you are looking for ahead of time.
Behavior based questions on the other hand, can tell you a just as much by the way the person responds. For example, when you ask something like “Tell me about a time when you had to talk to a co-worker or family member about something which you knew would be emotionally charged, and how you handled that situation.” If the interviewee responds hypothetically, you can be almost certain that they probably haven’t had this kind of conversation recently. And if they think very hard before responding, you have some evidence that this is not something that just comes naturally to them. All of this is similar to hypothetical questions, but key difference is that the content of their answers is far more likely to reflect the way they actually act, since people usually think they are going to handle difficult conversations differently than they actually do in the heat of the moment.
So, while I think both types of question have value, and I generally think that behavior based questions are going to kick hypothetical questions ass in terms of giving you more insight more quickly. On the other hand, there are situations where people are looking to move into new areas of responsibility, and you have to rely on hypothetical questions. Just remember that you need to know how the best respond differently than the average (or the worst) ahead of time, a good interviewee can make wrong answers sound awfully good!
December 26th, 2005 by Mark Ramm
Over on IBM Developer works, Bruce Tate (author of Beyond Java) talks about another innovative web framework written in an little used dynamically typed language — Seaside in Smalltalk. Smalltalk is the granddaddy of all object oriented languages, but it has never really broken out of its niche and become a mainstream programming language. Anyway, based what I’ve seen in seaside I am excited by the idea of continuation based web servers, and so I am doubly excited to see what happens when Peter Hunt and the other folks from Subway port CherryFlow (their continuation based server) to TurboGears.
December 26th, 2005 by Mark Ramm
I’ve been working a lot on the TurboGears book and class this last week, and I just got done with a several hour review of the history and theory behind MVC programming. I don’t know how much of this will make it into the final book, but it sure is a fascinating topic with lots to think about.
Anyway, I will be announcing the dates and times for the Ann Arbor and online version of the TurboGears class next week. There will be no fee for either class (though I might open up the online class for more people if some people want to chip in to cover bandwidth costs). The class will have a pre-lesson in Python basics, and will cover MVC programming, SQLObject, Kid, CherryPy, TurboGears widgets, the TurboGears toolbox, and fast data controllers AKA Simple CRUD, and lots more.
You’ll be the first to see information from the upcoming TurboGears book, and the only price of admission is that you give us the best feedback you can so that we can make the best book we can.
December 22nd, 2005 by Mark Ramm
I have been setting up Moodle to manage the online TurboGears class, and it turns out that I’ll probably run two parallel “courses” one for those who can attend the live lecture/lab portions of the class, and another for people who are doing the whole thing online. I’ve wanted to setup moodle for some learning management projects at work for the past 6 months, and I thought this would be a good chance to test it out. So far it seems really slick, though it does install a LOT of files!
I expect to open up registration on the TurboGears class sometime in the week before Christmas and new years, and the class will be free for those willing to provide me with good feedback and let me use it all to improve the upcoming TurboGears book, but I will have to limit the size of the online class in order to preserve bandwidth. Once I get the kinks worked out of the class after the first time, I’ll probably open up this class along with a more advanced TurboGears class to anyone who wants to take it. But, to do that I expect to have to charge a small fee to offset bandwidth costs.