You'd rather solve B.S. puzzle questions, or debug basic algorithms on a whiteboard standing in front of an interviewer?
I like real work. You should too. Otherwise, you are absolutely right, we shouldn't be working together.
What the "audition" is all about is trying to make it so that you don't ever get into a situation where you hire someone, work with them for a month, and say, "Holy shit, this isn't working out at all, I'd better fire this guy."
In France or something, where it's super-hard to fire people, maybe that makes sense. In California, it's mostly about trying to spare the feelings of the manager.
And, yeah, I've had to fire some people. It really sucks, no matter how deserved (well, I'm talking about just not being able to do the job, vs. "for cause" where it's white line stuff, fortunately never had one of those cases).
What's the difference between that and a pre-hire, high workload paid assignment?
The only practical difference I see is that the eager employer gives the new employee some false hopes of slight stability, which may cause her to uproot her entire family, e.g. "got a job in city X, honey, we're moving".
Most of the really good engineers I've worked with can go anywhere. When they're available it's by their own choice, and they're gone damned quick. (One fellow recently got fed up with things over a couple of months, made a call, and the email he got back said in part, "Apparently you aced your interview. When should we tell HR you can start?". Seriously, how do you compete with that?)
The people are not on the street. These people will not suffer the gauntlet you have decided is necessary. They're going to think to themselves "That's cute," and look elsewhere. I won't do a weeks-long project. I know very few people who would.
You CAN assess someone well in eight hours; if you can't get a good handle on someone's skills in that amount of time then you seriously need to improve your own interviewing skills. The message you are sending right now is, "We mistrust our interviewing expertise to the point that we want YOU to take a multi-week risk, really a very high risk, just so that we can be sure."
Now, there are undoubtedly people who want to work at your company, and they are willing to go to any measure to do so. If you are all happy with each other, then I see no reason why our paths should cross.
I guess this is the point where you can publically rationalize your strategy by bucketing me as a jerk, "sour grapes," someone you wouldn't want to work with anyway because of red flags and such. I won't steer you away from this, since I can't offer any proof that I'm not.
But I'm darned sure you're missing good people, even if you're convinced I'm not one.
Candidates who do not currently have a job perhaps have more time, but still probably are not that interested in suspending their job search to consult with you, and also (correctly) judge this to mean that you're skeptical about their abilities, and want to take a job with an employer who is more enthusiastic about them. That may be somewhat irrational of the candidate, but it's also true.
Now, if I were Very Interested in working at Discourse, Fog Creek, or any similar place of work, rather than just at any place with a nice paycheck, I think the audition is a great idea, and something people would be willing to do.
The GP's main objection is that you only get the best people who want to work at __your__ company enough to spend time on your auditions. There are likely many engineers like them who have a network of job opportunities compelling enough that the added draw of it being Stack Overflow, Discourse, or Fog Creek is not enough to merit the extra work.
I hear a lot about GitHub, blogs, and open source contributions which essentially act as your audition open to all talent scouts.
Perhaps if the audition challenge could be posted to the applicant's GitHub account then it would be a bit more useful to the applicant. The challenge could be skipped if a project in the GitHub account already demonstrates proficiency in the desired application domains.
But only students, freelancers who want to quit freelancing, and the unemployed would be able to take "a few days to a few weeks" for such a project. For someone in full-time employment, a few weeks would be most of their vacation time for the entire year, just for one interview!
I don't think it works well as a filter either - a technical interview can easily assess capabilities and while you're right that it cannot accurately assess work ethic or motivation, a trial period cannot either! A desperate candidate during a trial period is generally going to behave very differently than he would a year down the road when he feels bored and the job is secure in his mind. Is it a better filter in a vacuum? If you start with the same sample of candidates, all of whom had to go through whatever process you devise, would a trial period make it easier for you to find the best candidates? Of course. But having such a process significantly skews your candidate pool to the desperate. That's not necessarily a wrong approach to recruiting, but it has nothing to do with hiring the best and the brightest. In addition, unless you're extremely careful, you'll be mostly judging candidates based on their familiarity with your technology stack and workflow, as opposed to long-term potential because that's what short-term productivity depends upon.
It may not apply to you in particular, but one other thing that would make me worry about a trial period is that it's indicative of two other personal flaws on the part of the hiring manager - he may be 1) indecisive and 2) technically incompetent. The indecisiveness part is obvious - not only is not being able to hire without a trial period a mark of indecisiveness by itself, it's also a hedge against future indecisiveness in getting rid of employees that don't work out. I also find that technically competent people can judge competence in others very well, very quickly. They aren't always right and there are qualities that only manifest over a longer period of time, but those qualities can't be judged in a few days of work.
Paul Graham's advice to investors is apt here:
http://paulgraham.com/angelinvesting.html
"How do you be a good angel investor? The first thing you need is to be decisive. When we talk to founders about good and bad investors, one of the ways we describe the good ones is to say "he writes checks." That doesn't mean the investor says yes to everyone. Far from it. It means he makes up his mind quickly, and follows through. You may be thinking, how hard could that be? You'll see when you try it. It follows from the nature of angel investing that the decisions are hard. You have to guess early, at the stage when the most promising ideas still seem counterintuitive, because if they were obviously good, VCs would already have funded them."
Stringing people along while not being able to make up their mind is what mediocre investors and VCs do - without seeing good evidence to the contrary, I'd guess that this applies to employers as well.
Edit: in case my point wasn't clear, I'm not saying the approach is wrong or doesn't work or anything along those lines, merely that it's not how you hire the best and the brightest. Now, it's possible he meant "the best and the brightest" in the cliched way where everyone thinks they hire the best and the brightest, in which case it's fine. But in a literal sense, if your organization needs the best and the brightest, you won't get it following those suggestions.
Edit2: the point of pg's advice isn't that being decisive somehow is correlated with risk-taking and thus higher returns. The point is that being indecisive doesn't lead to significantly better decisions and if you can't make decisions quickly, you won't get the very best deals. If you're known to be indecisive or advertise this up front, no one who can get other investors will come to you. This is absolutely the case for talent.
Cultural fit is not a good reason either. If you can't judge whether someone fits in during the interview, you're probably not going to figure that out during the trial period during which you have a desperate person desperately trying to fit in. What's worse, this very mindset of "let's hire people who fit in" leads to the worst culture. If culture matters to you, hire people who are different.
And yes, finding good engineers, regardless of cultural fit, is by far the hardest problem. If you're optimizing for cultural fit and you're not Google/Facebook-type talent magnet, you're not even in the competition for the best talent. This may be fine if your bar is low - and let's face it, almost everyone's is - but again we're no longer talking about the best and the brightest.
Startups and small businesses.. aren't.
All I'm saying is that if, as a business, you are seeking to minimize your risk portfolio during hiring you are, by definition, not seeking to hire the "best" employees, but to hire the best employees with the lowest risk profile.
Once again, I don't think this is bad. You're running a business and the task is to get the highest probability you'll hire a productive employee.
Nonetheless, the OP has a point that you may lose employees due to your risk tolerance being too low.
Example: I work on the C# compiler. I'm not going to take a prospective employer's "knowledge test" on C#, regardless of if that is statistically a good filter for them in hiring.
I can only speak for startup / small team hiring, but the problem I see here is that the only hiring metric that you seem to be testing for is if the person is a good engineer or not. I believe that is rather objective, and in these days pretty clear to assess with the plethora of people writing open source projects. Simply put, if I was recruiting, I would not have contacted if I didn't believe you weren't capable of the work. (I also have the same problem with "Traditional" interviews, inviting a person for a job then testing them with fizzbuzz is like hiring an athlete to join your sports team, and on the first day asking him if he can kick a ball.)
What really worries me - and why I'm more a fan of a trial period, is how do you, as a human being, fit inside our community. Other than "not being able to do the work" there are a million other reasons why someone would not enjoy, or atleast put up their place of work. Maybe the team always has 6 o clock beers, and you don't drink so you feel left out. Maybe the team are composed of entirely of Montagues and you are a Capulet. There are human factors in the work place, and I believe, everyone should be comfortable where they work - and despite talks of equality, openness, and acceptance, there are people that just plain can't get along with other people for whatever reason. Were human and we move on.
Now again, I'm trying to build a small startup team and it might be different in corporate. However what would you say to employers that are looking at "trial period" hiring as a way to gauge culture fit and ultimately employee happiness?
It's hard to get more real in my book.
I do agree it's a hoop (what hiring process doesn't have those, even if it's a mutual trusted friend vouching for them?), if you can't get it done then one or more of us has made a mistake, but....
An onsite interview can (and probably should) involve sitting you in front of their computer, and getting you to close a ticket.
If you give people homework problems, then it's possible they will either palm them off to a more competent friend (or just pay $100 for a freelancer); or consider it an insulting waste of time.
Neither will test whether the candidate is reliable. But at least an onsite test will be harder for them to fob off to someone else; and it's less of a waste of time. It might take them a day or more to set up a "hello world" build at home (depending on the build requirements, and how well you've automated things).