That's also why I balk at companies that give take home tests to screen applicants.
Since you think about hiring a lot, I'm curious: do you think the above is accurate? If no, how would you phrase it differently? If yes, how would you recommend testing that hypothesis instead?
In addition to the argument that the economics of temp- to- perm don't work out in this market for tech talent, there are also fundamental problems with the approach.
Most importantly: lots of people can perform well for short periods of time, especially if they don't have to deal with interpersonal conflicts (which take time to develop) or technical design disagreements (which only happen at inflection points in product/service design; ie, it might take 8 months to discover whether someone can "disagree and commit" to work on a team where they disapprove of some technical decision). Also, lots of people can work well on a project for a couple weeks before they get bored, and some of those people lack the ability to kickstart their engagement back up again once they feel "burned out" by a problem domain.
I think those are some of the most likely failure modes of new employees, and they also happen to be different from the failure modes that classic interviewing and work-sample testing are likely to suss out; ie, you can cover the non-psychological non-work-ethic concerns about new candidates with a relatively straightforward hiring process, so temp- to- perm might not even buy you much even if you don't assume that the approach is costing you the best candidates.
The problem is that companies looking to fill full-time slots are looking to fill full-time slots, not to engage a succession of contractors.
By requiring candidates to perform in a contractor role prior to signing on full-time, companies are effectively disqualifying most candidates that are currently employed. That's because very few people sniffing around for a better job than the one they have now can afford to drop out of the market for months or even weeks delivering work as a contractor. That's not how most people switch jobs; instead, most people search for their new job from the comfort and security of their current job, knowing that if (say) interviews don't work out, they can take their time looking for the next lead, knowing that they can continue to execute on their current job.
This is a problem for employers because virtually everybody you'd want to hire in this market is already employed.
Typically they offer to take a slightly-low full-time weekly salary+benefits number, divide it by 40, and pay that as an hourly rate. Oh, goody.
No company wants to pay a contractor the going rate for contractors, and then face the unenviable task of talking that contractor's rate back down again when making them a full-time offer. Nor do they want the bother of haggling over the details of a contract deal that will almost always prove, one way or the other, to have been a wasted opportunity. (If the worker proves to be competent, the contract will be replaced by a full-time offer as quickly as possible. If the worker is incompetent, the contract will be terminated at the earliest practical date. In no case does anyone care much about the contract. It is a consolation prize for everyone involved.)
My personal philosophy is to treat contracting and employment like oil and water. Both can be tasty. But they are different things and one does not merge seamlessly into the other.
Anyway, I learned. Thanks.
The problem here is obvious: the best candidates don't ever have to put up with stuff like this. They're actively courted by prospective employers.
Sure, not every candidate can be "one of the best candidates". But why would a rational employer select a screening process that overtly rules those candidates out?
Maybe yours is different, but I think the first problem is they typically have a lack of clearly defined goals. I know that probably is the idea behind these - to see what someone comes up with - but it can be very intimidating. Especially given the fact that the interviewee is already nervous enough and now they are given something ambiguous. I think that's more nerve-wracking than the interview itself.
Second, I think that code-style tends to get graded on these more than the content. Unless it's completed in some really novel way (which isn't always a positive) there's nothing to do but nit-pick how the code looks.
Third, its disrespectful of the interviewees time, especially relatively large coding assignments. If a candidate has a job, is it fair to expect them to go home and spend a couple hours working on something that is essentially worthless?
Finally, typically the candidate gets no feedback. I had one that was a 'pass' and I never found out why. You are essentially grading me on an assignment and then don't have the decency to tell me what was wrong? This is related to the previous item as a time-waster.
So, those are my reasons. Just my two cents.
(1) Yes, ambiguity is death. It's bad for the reason you say it is (it psyches you out, and discovering how people perform when they're at their most psyched-out is a pointless exercise). But it's also bad because open-ended tests are hard to grade and compare. Work-sample tests need to be standardized and they need to be defined rigorously enough that you can draw comparisons between candidates, and then draw comparisons between the performance of hires and the tests.
(2) Yes, grading superficial issues is also bad, for the same reason: when you give someone "points for style" (or demerits), you lose the ability to make apples-apples comparisons with candidates over time.
(3) I flat out disagree that take-home work is disrespectful of candidates. Most interview processes demand that employees submit to several (3+) hour+ long phone screens, then show up at an office for 1-2 days of interviewing. Allowing candidates to do the most important technical portion of the interview on their own time, on their own schedule, in their own location is simply better for the candidate than forcing them into a room with a whiteboard.
(4) Yes, not giving feedback to candidates is one of the great sins of tech hiring. Some of this is folkloric; for instance, there's a belief that providing feedback to candidates you opt not to hire sets you up for frivolous complaints down the road. But there are ways around that problem.
As for #3, if you aren't a fairly exclusive 'brand' (like Google, Amazon, maybe Facebook) and you are known for having a long interview process, I think a fair number of applicants won't even bother. I've been asked by Amazon to interview a few times and their process just seems like a big pain for not much gain. Unless I was right out of college I just wouldn't find it worth the effort.
So if a recruiter tells me an interview process is extensive and way too involved for the market, I'll just pass. When jobs are plentiful a candidate can afford to be picky.
EDIT: sentence clarity.
The only time it is ok to ask for a take home assignment is when the person is at most a couple of years out of school, and they haven't proven themselves yet.
I personally refuse doing to do take home assignment as I have enough projects in my belt that I can show. It is usually a sign that the other party is not mature enough, and they don't know what they are looking for, and once you join that company they will treat like a junior engineer, when you might be past that.