Much of what's being said is focusing on one half of the work-sample: the company assessing the potential employee but this:
"The applicant's concern is "will I really find a good fit in this company and advance my career here?""
Is a big deal too.
Wondering what the company is really like? You're going to get to work for a day with one of their devs, see what they're like, see their code base, their tools and processes, their standards.
Given that most companies oversell themselves (the old saying interview is like a seduction, a job is like a marriage), this would seem to me to be an amazing opportunity to find out if this is the right move.
Sure you want to be pretty certain before you commit this time, but so will the company - unless you're off the charts great it's likely they'll lose as much of their lead dev's time as he gets you up to speed as they'll gain from you - so as a final stage in a recruitment process that could lead to a long term commitment, it seems win win.
Yeah... No, it seems exploitative to me. Let's hack on a FOSS code base, hell make it a library you use!
Or if you want to work on something that is yours, let's reimplement stuff you've done, but let's not take a whole day where I work and I don't get paid. Or ask me to build you features that go live, and I won't get paid and might not get the job...
There are better ways to achieve what the prospective employer is after, without getting me to spend 8 hours building features for your application with a risk that I will get nothing out of it, but you might.
As a candidate what will teach you more about the company, the product and the role - working on the real code base on a real change or working on an OSS project?
It seems at least as likely you'll learn something material as I'd get working code out of you that the lead dev couldn't have written on his own given his better understanding of the problem domain.
On the other hand, many people already have jobs are were contacted by the company looking for a candidate. I would have to take a day off work to go in for a full day interview, so some compensation is also reasonable.
> On the other hand, many people already have jobs are were contacted by the company looking for a candidate. I would have to take a day off work to go in for a full day interview, so some compensation is also reasonable.
I would say that if getting the opportunity to evaluate the company as a fit more substantially than a traditional interview isn't adequate compensation for the company getting to do the same for you, that's quite possibly a good sign to you and the company that you aren't really a good fit.
I disagree. While I have an awesome job, I'm always casually open to new opportunities. That doesn't mean that I'm willing to sacrifice a day of my time for an opportunity which I know very little about before making the sacrifice. If I'm out of work and/or desperate, then yes, the potential benefit outweighs the cost/risk. Since I'm not by any means desperate or looking, asking me to take the risk/make the sacrifice with no compensation is more than the possibility of some yet unknown potential gain.
That isn't any logical grounds to assume I wouldn't be a good fit. That just means the ROI tells me it's not worth my time. Without seeing significant potential reward and a reasonable possibility of getting the job, and actually wanting it, there is no way I'd go in for more than a couple hours of coding without compensation.
The issue here is that I'm making a significant investment (both time and potentially money) in what sounds like quite a long shot. You're casually open to a new opportunity but that sounds like I've only got a relatively limited chance of landing you (and that's on top of us deciding you're a good candidate for us).
You say that the ROI doesn't work for you, but the chances are those odds mean it doesn't work for the company either (we could invest the time and money in the interview and still not land you - that's always a possibility but here it sounds pretty likely).
In all honesty it sounds like the right thing in these situations isn't to pay money, it's to either find a more efficient way to work out whether it's a good match (so that a long interview was either unnecessary or something the candidate was willing to do) or for both parties to walk away and look for a better way to spend their time.
Just to be clear, it's not that I don't value the developers time, I absolutely do, it's just that I think handing over money in this situation (a) may work for the developer but doesn't for the company and (b) rather muddies the water.
"The applicant's concern is "will I really find a good fit in this company and advance my career here?""
Is a big deal too.
Wondering what the company is really like? You're going to get to work for a day with one of their devs, see what they're like, see their code base, their tools and processes, their standards.
Given that most companies oversell themselves (the old saying interview is like a seduction, a job is like a marriage), this would seem to me to be an amazing opportunity to find out if this is the right move.
Sure you want to be pretty certain before you commit this time, but so will the company - unless you're off the charts great it's likely they'll lose as much of their lead dev's time as he gets you up to speed as they'll gain from you - so as a final stage in a recruitment process that could lead to a long term commitment, it seems win win.