Tim Lesher has an interesting post about applying meritocratic principles to hiring software developers. He suggestion is to hire developers as contractors for a trial period before taking them on full-time.
If you as a hiring manager aren't sure about someone, either on a technical level or just fit with your team, this makes sense. I didn't have precisely this experience when I started as an instructor at Northface, but I did start at a lower salary with an explicit "if you're still here in 3 months, here's what your salary will rise to." (This was primarily because they wanted someone to teach ASP.NET, with which I had no experience at the time.) I thought this was a pretty fair approach, and much better than a rigid "if you don't have the right keywords on your resume, don't bother no matter how good you are."
But companies won't bother giving the "maybe" candidates a trial period if they think they can find a "yes" candidate in a reasonable time. Not out of malice, and not even out of stupidity: even with a good candidate, they know that net productivity will decrease temporarily while one or more of the existing team answer the new person's questions and otherwise help him get up to speed; the bigger the project, the longer this lasts. With a "maybe" candidate, the odds that the eventual increase will make up for that only get worse.
Companies with smaller projects can better afford the risk, but they will still prefer to hire someone they are sure will be an asset than take chances.
Later at Northface I did the technical interviews for instructor candidates. The majority really were "yes" or "no."
That experience, incidently, is one reason I view with deep skepticism the claims by many of the slashdot crowd that there's plenty of hotshot American programmers looking for jobs, so we don't need no steekeen unwashed H1-B visa holders. Many if not most of the ones we didn't call back were the sort who, for instance, claimed years of MySQL, Oracle, and Sybase experience but couldn't tell me about any differences in their SQL dialects. Or the Java programmers who got wrong something like
class Dog {
public String name;
}
static void foo(Dog d) {
d = new Dog();
d.name = "Rex";
}
...
Dog d = new Dog();
d.name = "Prince";
foo(d);
// What is d's name?
So while contract trial periods can be useful, I think there are solid reasons why you don't see companies doing that more often. If you really want to move into the hot new *cough* Python field, work on an open-source project. Start a blog. Bring a USB drive with code you've written to the interview. Floss. Don't be a "maybe."
Comments
That's definitely true. I'm not really talking about using trial periods to find diamonds in the "maybe" rough. Dave couched his message in terms of a company's management of risk. That's what I'm talking about: a contingency for when your "yes" candidate turns out to be a "for the love of God, no!"
I've only made this mistake once, but once was enough. After he was hired, one by one, the entire team left not only the project, but also the company.
Now, one bad hiring choice in twelve years sounds like a pretty good record, but the effects on that product were large indeed. It doesn't matter if you only allowed one hit all season, if that hit drove in the winning run in Game 7 of the World Series.
As an aside, in an Open Source project, he probably would have submitted a number of excellent patches, created a half-dozen bitter flamewars on the development list, and then stopped having his patches accepted.
That's damage reduction.
I don't think you'll see this often, either, because a candidate who looks good to you will probably look good to the other places he's applying. Other things being equal, if you offer a trial and someone else offers a full-time position, odds are he's going to go with them.
Many of those "hotshot American progammers" tend to be over 35 and are considered "too expensive" or "unable to learn"; which is not true.
I have worked with may H1-B visa holders and the only ones that were worth the pay were educated at American universities. But, even that was not a good indication of their abilities because many universities are just passing the international students through the system because they pay a lot more tuition.
I prefer to hire people who have a track record for producing quality software and demonstrate that they enjoy learning new things.
Your Java example is only good if you are looking for a "coder". The design of the solution is more important than a piece of code that would never have been written if the person followed solid software engineering principles.