Skip to main content

Trial periods for software developers

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

Tim Lesher said…
companies won't bother giving the "maybe" candidates a trial period if they think they can find a "yes" candidate in a reasonable time.

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.
Jonathan Ellis said…
Yes, that's the other side of the coin, but my post was already too long. :)

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.
Jonathan Ellis said…
... and if he's kill-your-company bad, lay him off. Yeah, it sucks to lay people off but 1 in 12 years seems quite reasonable.
Anonymous said…
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 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.
Jonathan Ellis said…
Yes, my Java example was meant to be in the context of hiring coders. Sorry if that wasn't clear.

Popular posts from this blog

Why schema definition belongs in the database

Earlier, I wrote about how ORM developers shouldn't try to re-invent SQL . It doesn't need to be done, and you're not likely to end up with an actual improvement. SQL may be designed by committee, but it's also been refined from thousands if not millions of man-years of database experience. The same applies to DDL. (Data Definition Langage -- the part of the SQL standard that deals with CREATE and ALTER.) Unfortunately, a number of Python ORMs are trying to replace DDL with a homegrown Python API. This is a Bad Thing. There are at least four reasons why: Standards compliance Completeness Maintainability Beauty Standards compliance SQL DDL is a standard. That means if you want something more sophisticated than Emacs, you can choose any of half a dozen modeling tools like ERwin or ER/Studio to generate and edit your DDL. The Python data definition APIs, by contrast, aren't even compatibile with other Python tools. You can't take a table definition

Python at Mozy.com

At my day job, I write code for a company called Berkeley Data Systems. (They found me through this blog, actually. It's been a good place to work.) Our first product is free online backup at mozy.com . Our second beta release was yesterday; the obvious problems have been fixed, so I feel reasonably good about blogging about it. Our back end, which is the most algorithmically complex part -- as opposed to fighting-Microsoft-APIs complex, as we have to in our desktop client -- is 90% in python with one C extension for speed. We (well, they, since I wasn't at the company at that point) initially chose Python for speed of development, and it's definitely fulfilled that expectation. (It's also lived up to its reputation for readability, in that the Python code has had 3 different developers -- in serial -- with very quick ramp-ups in each case. Python's succinctness and and one-obvious-way-to-do-it philosophy played a big part in this.) If you try it out, pleas

A review of 6 Python IDEs

(March 2006: you may also be interested the updated review I did for PyCon -- http://spyced.blogspot.com/2006/02/pycon-python-ide-review.html .) For September's meeting, the Utah Python User Group hosted an IDE shootout. 5 presenters reviewed 6 IDEs: PyDev 0.9.8.1 Eric3 3.7.1 Boa Constructor 0.4.4 BlackAdder 1.1 Komodo 3.1 Wing IDE 2.0.3 (The windows version was tested for all but Eric3, which was tested on Linux. Eric3 is based on Qt, which basically means you can't run it on Windows unless you've shelled out $$$ for a commerical Qt license, since there is no GPL version of Qt for Windows. Yes, there's Qt Free , but that's not exactly production-ready software.) Perhaps the most notable IDEs not included are SPE and DrPython. Alas, nobody had time to review these, but if you're looking for a free IDE perhaps you should include these in your search, because PyDev was the only one of the 3 free ones that we'd consider using. And if you aren