Won't hold my breath.
I'm sick to the back teeth of most of these mini coding projects, though. They're too often sent by companies who aren't even sure they want to hire at all or wouldn't hire you anyway for some unrelated reason (age, race, etc.). The projects are always boring and almost never suitable for a portfolio.
It's also too easy to hit the 'send email' button and too easy to ignore the responses. Unless there is some cost for the company sending you the mini-project, a lot are going to waste your time.
For this reason, I actually prefer interviews. They're going to at least do a cursory examination and reject you outright before wasting an hour of their own time.
Another thing to keep in mind is that for a lot of people who are already employed, permission must be obtained from current employer before contributing to open source (and more and more companies are actively enforcing that unfortunately).
I am always puzzled about contract clauses that try to limit what an employee can do in their free time. I understand that some people may be in a bad situation and have no choice but to put up with it. But if we're really in a seller's market, as everyone says, how can this kind of thing become a tendency?
This is further reinforced by various employer-specific clauses in the hiring contract / code of conduct.
Its screwed up but its the world we live in.
Any employer who puts that clause in their contract and whinges about not being able to find good developers has only themselves to blame.
Where I am employed we are actively hiring. In late 2012, three of us started a small experimental projected which became a hit with our customers. As more feature requests came rolling in we realized that we need a bigger team to work on the project. We have been hiring since the start of 2014. We now have a team of about 15 engineers, but we still have few more open positions.
From our experience, resumes usually are not a good predictor of anything we care for. The only useful thing it tells us is what firms the candidate has worked at, and what those groups were doing while the candidate was there.
When a candidate comes onsite we spend significant time showing a demo of our product, what our groups ambitions are, discussions to understand what the candidates career goals are etc. We also have the standard white-board interviews, often attempting to design a small feature on our product. This takes significant effort on our part. Before investing this time, we will prefer to see some code from the candidate.
The candidate is offered an option to show us (1) some code they wrote which is out in the public domain, OR (2) some code from their employer (if their employment terms allow it) OR (3) solution to a small coding question we provide. Our coding question takes about 4-5 hours of the candidates time.
This process has worked very well for us. We have been able to screen our candidates with very impressive resumes who wrote horrible code. We have also found many great candidates (some who are my colleagues now!) with ordinary looking resumes.
I hope I have tried to explain our thought process behind asking candidates for some code.
As a front line filter it is cheap, simple and revealing.
FWIW we have a coding project but it's part (a large part) of the on site and really just replaces the whiteboarding and such. Candidates are not asked to code on the fly in ither sessions
For what it's worth, I'm not talking about the 2-4 hours an interviewee spends on-site. I'm talking about the additional 4-8 hours some companies expect interviewees to spend doing coding projects or time spent on-site above and beyond 2-4 hours.
So for instance, my coworkers that complained when I said they should be spending several hours reviewing code samples before an interview are being just as silly in my mind as people who get bent out of shape over 5-6 hours of leg work. At the end of the day it behooves both parties to spend a fair amount of time and energy here, in theory this could be a relationship which last many years - isn't it worth it for everyone involved to put in the effort to make sure it's a good fit?
And really, at the end of the day it's entirely possible that the way a particular company or candidate conducts things reflects right away that it's not a great fit (e.g. a candidate loathes the coding challenges, or a company balks at a candidate requesting money). There's nothing wrong with that, a fast fail isn't a bad thing.
A job candidate loses both time and money. I complete your challenge, I don’t get paid, I get thrown into the street and starve. I would have made more profit washing dishes at a restaurant.
Besides, word on the street is that nobody can expect to have “a relationship which lasts many years” with any company, so drop your pretense at perfection. That is a contributor to the tech industry’s problems with lack of diversity and actually filling positions with people who can do the job.
This assumes you're not currently employed
"nobody can expect to have “a relationship which lasts many years” with any company"
If I'm taking a job I'd like it to be a place that I could see myself staying for a number of years. It might not work out that way, but it's my goal.
Why not? Make it a test that is easy to score and then finding people who do well on it and are interested in working for you is rather high, no?
I want to hire someone to do a job. That job requires a base level of competence. If they exceed that level such that I think they will bring positive value to the company I vote to hire them. I don't care about their motivation or "passion" beyond what is required to take them over that bar.
I don't see it as a waste of time; it's about the potential payoff, which is a (presumably) better job with better opportunities. I wouldn't apply to a job unless I was reasonably sure I wanted to work there anyway. I might be very lucky in that I've worked for good companies in the past few years and the only reason I'd leave one of these companies is for a much much better one. Usually when I leave a job, I've become bored of the problem domain anyway and am looking to solve new problems.
Disclosure: 31 year old man, no kids, I live with my partner.
I hate to be that guy, but everything changes when you have kids. Trust me, a spare hour when you have nothing better to do than jump through some hoop for a company is an extremely rare luxury item when you've got little ones. I love solving problems too, but there aren't any technical problems as interesting as reading a book to your snuggly little human(s). :)
c.f. http://blog.codinghorror.com/on-parenthood/ (not about interviewing, but filter your thoughts about free time through the perspective that article provides...)
On the other hand, when I am looking for a job (I am unhappy at the current job ) I go far and wide as I am applying to multiple companies. In this situation I talk to the ones that ask for interviews first, as they appear more committed, and push all the tests after the interviews. From my limited experience, by the time the interviews clear up I have at least a couple of offers on hand. Offers I can identify with people I've been talking to, the environment I've seen, the location, the projects etc. Spending several days on tests, which, at best will bring an interview, which may or may not lead to an offer, which, in its turn, may or may not be better than the offers I already have now looks like plain gamble to me. So I take the best offer instead of doing any tests.