As others have said, there is no reason not to let the candidate work on related OSS projects or on already solved tasks. Adding new features to a code base for free is not on. This is like hiring labor for your bridge building company, getting 50 people and having them drag rocks around all day and then not paying them. Feels close to illegal.

If the application is so simple that you can get actual productivity in someone in the first couple hours then stop trying to hire candidates and outsource the entire thing to India for a fraction of the cost.

Otherwise it's a pair-programming test with massive hand-holding from another developer which is ridiculously more expensive for the company.

I'd choose to spend a few hours on the employer's actual application over any other form interview.

Obviously there are extreme cases (hey we'd like you to spend a few weeks working on this API, you know, for the interview), but I don't get that vibe from this article.

It that's all it is, then what is the benefit of doing it for more than maybe an hour or two? Are you really going to learn much more about the applicant's general level of skill and experience, or change your opinions on whether they'd be good to work with, if they are with you for 3 or 4 or 8 hours instead?

On a separate point, you are making an assumption that in a pair programming situation the hand-holding will all be one-way because the applicant doesn't know the code base. Hopefully anyone you're thinking of hiring would also be able to show the partner/interviewer a useful thing or two in a whole day of coding based only on general programming principles.

Also, if the applicant has a general knowledge of what the business does (which hopefully they bothered to research before applying!) and the interviewer and code base are any good at all, the applicant will understand enough about the problem domain to being to work "natively" within a day. Of course they won't suddenly understand everything, but interviews are two-way deals, and if someone the employer puts forward to represent them can't explain their own product well enough for native thinking to at least begin, or if the code base is so bad that a decent candidate can't start to find their way around after a whole day, then the employer failed the interview.

This isn't like a comic book company asking job candidates to submit a page of a script, where they can just use it as is. Software is a very living product and you need live people maintaining it.

I do think that companies should consider paying a candidate a few hundred bucks to spend his whole day with you. This doesn't change whether he's working on "open source stuff" or the company's product they are selling for money.

EDIT tldr: they should have paid him for his time not for his product

He fully accepts at the beginning that he knew they wanted a day of his time, and he was willing to give it - he just wanted to work on some open-source work instead of their product.

I've been asked to work on a company's live code as part of an interview process, and they paid me pro rata based on the salary for which I was applying.

Asking someone to do so unpaid for more than an hour or two just isn't reasonable.

If someone hires me for a day's work and he uses it to make a million dollars, I have not been cheated.

If someone hires me for a day's work and he can't extract any value from it, he has not been cheated.

He seems hung up on the fact that he thought the company was benefiting from his work. 1) They probably weren't, as you said, and 2) it doesn't matter if they do or not. He should be compensated for giving them a full day of his time regardless of whether he gives them useful work-product.

During the first interview would you consider paying for the time of the person interviewing you? My day rate to customers is £1000 and while I'm interviewing you I can't be doing that work so let's call it £125 an hour to read your CV, answer any questions you may have about the role and so on.

Yes they potentially want you to work there, but you presumably also are interested in working there. If that's the case why is your time valuable but theirs not?

And if you're not interested then why are you interviewing at all?

Quick edit: I think I've been slightly misunderstood. I'm not suggesting that the candidate should pay anyone anything, just drawing a (possibly bad) parallel.

A good interview is a chance for a candidate to see if it's a good job - that's worth investing time in. The organisation get to see if the candidate might be a good employee - that's worth investing time in. But both are making an investment and both are getting something out of it. To me it already looks like an equitable deal, I don't see why introducing money is helpful, particularly in a lopsided way.

As to why the actual code base and an actual problem - because it's the best test for both sides. What does a candidate learn more from, the actual code base and a real world change or a OSS project? I'd suggest that he's at least as likely to learn something material about the company and the product as they are to get usable code out of the candidate.

Assuming you've at least weeded out the many people that are a waste of time and money, then I think it's fair to pay anyone you bring in a reasonable rate for a couple hours of work.

Also, with most companies that contact me, I don't really know if I'm interested at all until I go in and talk to them. Don't presume that all candidates are interested in working there. It's hard to know until you know more about what they do, their processes, the culture, the type of people you will be working with and what the management is like.

But you're missing the bigger picture.

As a employer, interviews are massively disruptive and time consuming. For us over two interviews you'll speak to at least one manager, two or three developers and probably someone from the test team and or an analyst. All those people will read your CV, prepare questions, spend time interviewing you and then get together to discuss and make sure we've given you proper consideration and provide feedback. These are people who are generally relatively well paid and have other things they could be doing.

We'll read 3 (pre-screened) CVs for each first interview, 2 short first interviews for every second interview and probably 3 long (several hours) second interviews for each offer. So to get to one offer we'll have read 12 CVs, done 6 first interviews and 3 second interviews. I don't think we're abnormal - that's about typical for places I've worked (though I've heard of places who are far more demanding).

Much of that is done based on little evidence (usually a CV which may or may not be totally factual) and it's certainly not an indication that we want a candidate to work for us, merely that it might be something that could work out. Understanding whether it's more than that is why we're doing the interview.

My point is that we put a lot of time and effort (which has an associated cost) into seeing whether someone is a good candidate for us (and if we think this is a good job for them).

We don't ask for compensation for that time so why is it reasonable for a candidate to do so?

A candidate absolutely has the right to say that they aren't willing to submit to a particular interview process but I think asking for money to interview requires a very lopsided view of the process and, as a hiring manager, would have me pull the plug instantly.

From the employee perspective they may or may not actually be looking for a job, versus casually interested in all possibilities (like me). They also may or may not already have a job, in which case they'll have to take the day off to go through such an extensive interview, giving away work and potentially IP for free.

If I have a job and/or I'm not really desperate, then the cost of the interview may be greater to me than what I see as the potential gain. Especially when compared with the other possibilities out there. There are a lot of companies that will pay for any significant amount of time spent coding for an interview. Why would I waste my time with a company that doesn't value my time (esp. taking it off work), the work they're asking me to do, or potentially the IP I give them (e.g. if I come up with a new way of looking at a problem or a new solution they haven't thought of during the code interview).

A couple hours is a reasonable sacrifice, IMO, but may depend on each candidates situation. If I as asked to spend more than 2 hours coding, I would ask for compensation or turn down the interview.

If you're casually interested the aim shouldn't be to do a day long technical interview, it should be to establish what the real level of interest is and to either build that interest or establish that it's the wrong thing for you / us. Once we've done that we're either in a situation where you're keen on the role and we're looking at something where a day might be a good investment for you, or we've saved us both a day.

Making a significant time investment when one party isn't serious about the opportunity is the wrong thing to do for both company and candidate, and throwing money at the problem doesn't change that.

Ultimately I'd like to show you I value your time by not wasting it, rather than by paying for it if that makes sense?

Personally I don't think that a company will learn much more from 8 hours or more than they could learn in 3-4 hours tops though. I think it's overkill in most situations.

I would disagree with you. First of all, it is unclear of the role he was screened for.

1. It is clear that they needed the 'job' (features) done today, so a very likely of actual value to the company.

2. The candidate offered working on OSS project. Being a contributor to OSS project is a great value (not bukks though) itself, so I would not say it being 'free'. Saying that working for free on OSS is same as working for free on company's proprietary codebase is wrong...

3. Not everyone is "omg I will work here even for free, because it is awesome and I am changing the world". The candidate might have no difficulties finding job offers, and he values the money over excitment of a project. That is his choice, some professionals know what they are worth.

4. Employer - employee relationship is straight forward: pay for value, get paid for value.

If I have been interviewing him, I would instead give him a plus for not being "yah I will work for free, just give me a job" - a signal of desperation and troublesome candidate.

2) That's been discussed elsewhere in the thread. My personal view would be that unless the candidate had existing domain knowledge as well as technical skills, the lead developer would likely have been able to do the job faster themselves.

If they are being used as a freelancer for a day then I'd agree that that's exploitation but it's such a dumb thing to do (is any company really getting an unknown interviewee in to write production code to a deadline in a way their lead dev can't without the help) I very much doubt it's the case. If the developer had reason to believe that that was the case then they shouldn't ask for money, they should run away fast as the company is being run by idiots.

3) I agree but from the company's perspective to invest a day of a developers time (even without the money) I'd want to address as much of that doubt as possible up front.

4) As per point 2, I don't believe there is likely to be significant value in the code, just in learning about the candidate and that's reciprocal - the candidate is getting valuable information about the company which will form a .

Turn it around, would you want to work for a company so desperate for talent that they have to pay you to come to an interview?

To me it just sounds like you don't want this job much and the best outcome for both parties is that you go your separate ways.

1) I was talking from the personal experience in UK. Though, this might be conditional and post-student specific period.

2) Lead developer is getting a double value: interview a candidate, develop the product.

> Turn it around, would you want to work for a company so desperate for talent that they have to pay you to come to an interview?

I would like to work for a company valuing my professional time. The interview process itself is usually exciting, I learn a lot for myself by talking with inspiring people. But a day of coding is carrying by a degree less benefit to my professional and personal growth.

> To me it just sounds like you don't want this job much and the best outcome for both parties is that you go your separate ways.

I would rather not live in a employer's pony world where everyone dreams of working in their company.

As a company, you can hire someone highly loyal, thankful, putting his soul onto company's idea and unskilled, or less loyal and more skilled. You choose the balance. It was never possible to get both of the two worlds.

E: My awful grammar.

I don't see this as an employers pony show (and I'm both someone who looks for jobs as well as hires), I see it as looking for an equitable arrangement where someone interested in a job gets together with someone interested in hiring them. Both have a need and the aim is to mutually satisfy that in a way both parties find acceptable.

Paying someone who isn't sold on a job and a company to come in for a day seems to me to be the wrong solution to the problem. The persons questions and doubts can almost certainly be addressed (or not) in a far more time efficient way at which point they're in a situation where they can work out whether a day is a good use of their time. The real question seems to me to be how can we get it so that day, if they choose to attend the interview, is a good use of their time, rather than paying them because there's a high chance it's being wasted.

We can value someone's time by paying for it, or by doing what we can to make it time well spent. I think we should try to do the second one rather than the first.

Sorry hiring people is a burden, BTW, my 1-day contract labor rate is $25,000/day. Why should I waste my time doing your labor for free?

If after research and any questions they want to ask ahead of an extended interview they still aren't sold on the reasonable possibility that it's an interesting opportunity it doesn't seem a good use of my time, let alone hard cash.

How many sales have you made at that price? My figure isn't hypothetical, it's our standard day rate which we sell at and is the opportunity cost for those people's time. I'm not seriously saying that we'd ever consider charging candidates, just saying that the company is already making a significant investment in the person.

Maybe this is a local thing and supply and demand are more out of whack where you are than here (the UK) but what's being proposed doesn't feel equitable to me even in a candidate driven market.

(See also the edit above in response to your earlier deleted post).

If you can't answer that question yourself without assuming that every candidate is a desperate unemployed mook on their last dollar you can bend over a barrel to squeeze some free labor out of then you probably shouldn't be in a hiring position.

Flip the question around, if you didn't need somebody to do work for you, then why are you bothering to open a position?

> How many sales have you made at that price?

You're the one with a problem so big and urgent that you're willing to take a random person off the street and put them onto your production code for a day. As the person solving that problem for you, I get to dictate the price, not you.

If you think you can sustain your daily charge rate and grow your business without adding more people, why aren't you doing that instead?

I think we're agreed that by the time you got to doing any extended technical interview you'd have gone through a fair bit - the company would have seen CVs, the candidate would have done research. There would have been a shorter first interview where both sides could ask questions.

At that point I'd hope that the candidate would know whether they were interested enough. I'm not saying they should be certain but it should be more than just an idle "what's this?" situation.

If that wasn't the case then the right thing to do would probably be to talk a little more about what the candidate was looking for, what concerns they had and whether we could address them and what (other than money) might convince them that an extended interview was a good use of their time. If they couldn't be convinced then we could either talk about a shorter interview (either instead of or ahead of a longer one) or we'd have to accept that we'd not sold the opportunity to them and ask why we felt that was likely to change during a day together but couldn't be addressed in any other way.

To be willing to hand over cash to someone to attend an interview I'd pretty much have to be convinced enough that I'd be willing to offer them a job without the interview.

As for desperation - I don't think I've ever been or would ever be as desperate as you make out and this isn't a "random person off the street". If I was I'd hire a freelancer and still take my time over the long term hire.

As for the price, no you get to make an offer, and I get to politely decline and look elsewhere. Both my experience of recruitment (both recent and long term) and standard practice in the industry says that that's working out just fine. It may be that there are specific local conditions where you are that mean otherwise but I can only comment on what I see in the UK.

Out of interest, your bio says that these days you're largely management. Would you ever pay someone to come for an interview? Do you think you'd be able to sell it within your organisation?

No, and I'd never try to do the practice that started the entire thread of getting somebody to work on my production code for free for a day either.

It's probably illegal in both of our jurisdictions number one, opens you up to unbelievable liabilities number two if you don't hire the person (at least in the U.S.), and is just outright unethical. It keeps popping up here from time to time though and it makes me wonder about two things

1) What kind of people does HN attract that are in hiring positions?

2) What kind of abuse do engineers take for granted that they'd be willing to entertain the idea?

> I think we're agreed that by the time you got to doing any extended technical interview you'd have gone through a fair bit - the company would have seen CVs, the candidate would have done research. There would have been a shorter first interview where both sides could ask questions.

Personally, I've been very far along in interview processes before one side or the other decided to pull the plug. I've even been as far as starting to fill out initial employment paperwork before pulling out after finding out something about my future employer that hadn't been made clear to me during the earlier interview processes (in that case, I found out the people who I interviewed with were not going to be my supervisors. And after meeting him, I found him to be unsavory and that was that).

I think we're probably talking about different subjects, I was referring to the rotten idea of grinding a day of slave labor out of candidates the OP brought up while it looks like you're focused on appropriate compensation for people's time during long interview processes. If I'm the one who got off track then I apologize.

The employee/employer relationship is a business relationship. As such, think of yourself like a business. Sometimes you have to spend money (time/effort) to make money (paycheck).

To view it any other way seems entitled to me.

Lets put this way, you are interviewing for a Car Sales position, you get to the my store and I ask you: Hey, today you gonna spend the day selling cars, it will be our test, and then you sell as many cars as you can for free.

Do you still consider this, part of the interview? Keep in mind that you are bringing profit to my store.

As others have pointed out, a pair programming interview costs them money. If you want the job you should be comfortable with an extended interview... lot's of companies do a series of interviews, should candidates be paid for that? As long as you're not naive this stuff isn't too big a deal. If I didn't like it I'd leave -- and I have during a pair programming session once, but it's because it helped me to quickly get a really clear view of the situation. It's as valuable for the candidate as it is for the company, since you get to make a life decision based on actual information. This is a rare gift in a way.

That said, I think half a day max makes more sense.

Pretty much this. For some large, complex codebases I've worked on the metric has been that if the engineer can meaningfully contribute within a week then they're likely damn good at the job. Two weeks and they're still fine.

And some are needlessly complex but you inherited them from another, long-gone team and somebody has to maintain, improve and update them, unfortunately!

But the work isn't free. Sure, the company isn't paying you, but the company is paying me, and you can bet that we're not getting as much done as we would get done on an interview-free day. I don't think anyone's ever been under the delusion that we're just trying to get cheap labor to build our codebase for us.

> LD: "Well, I thought we could work on our application, we've got some features I want to implement and push live by the end of the day"

Key difference being that the interviewee is going to be adding new features that will be pushed live without any further work by other employees.

A company solicited "art tests" as part of a hiring process that basically amounted to having the candidates create free content for them.

maybe I wouldn't say anything too valuable unless it really seems like it will tip the scales but this is part of common sense and good judgment at any job -- if you publicly spill too many good ideas, others will repeat & steal credit. plenty of corporations will hire with a couple hours of interview but i don't really expect startups & small companies to work like this realistically. They probably need to be more careful with hiring. if you're obsessed with your "day rate" and think you can get people to keep paying it, then just keep freelancing...

the point of a job is to get a steady check every week in a more relaxed environment than freelancers typically face. if you want that opportunity, you have to prove yourself. the idea that they are trying to trick your fantastically brilliant mind into solving their problems sounds like a Ruby-ists fantasy or something, lol.

Just get real now and then, the author made fun of them for hiring [Hipster programming language] but he sounds just like [Hipster programmer]. If you walk into a place and you are not feelin the vibe then you are free to leave. Their request seems far from egregious though, I've done a pair interview before and it's strange but you're pretty much just shadowing someone and hangin out. They're not going to set up a dev environment for you and give you the keys to the codebase, come on.

Full disclosure: I have a job

When my employer wanted "work sample" for my interview, they set up a consulting contract, gave me time to familiarize with the codebase, discussed realistic sample assignment requirements, placed no limits on my work time, sensibly integrated my submission(s), and paid me for it. I'm very happy working here.

I am warming up to the concept of a very short paid contract to do the code interview, btw.

If you want to argue that he should be paid for the value of his work product, realize that in almost all cases that value is likely negative. Slowing down a developer for a day to work with a candidate is in no way beneficial to a company.

There is always a cost to hiring. When a company decides that the value of having that dev is greater than the cost of hiring them, then it makes sense to hire someone. It may not be an immediate monetary value, but the company decided they needed the dev. So they decided that slowing down a developer for a day to work with a candidate _is_ beneficial to the company.

Plus, like others have said, it really sounds like he was being asked to work on something that was adding value. If a company has decided a particular bug or feature is worth prioritizing then it obviously has value. That means that if a potential candidate comes in and does it, they are adding value (though whether the net value is positive or negative varies case by case).

I think you're generally being rather kind on the not-yet-employer here, but I have one specific point: giving up a whole day of your labour for free for every interview is not a sustainable strategy.

I don't know what the average number of interviews is prior to taking a new position, but if they all last a day, that is a lot of work for each applicant to do without getting paid, and it's a lot of work from a lot of applicants that the prospective employer gets for free.

Everyone is taking a risk going through a recruitment process, but typically it's already stacked heavily in the prospective employer's favour as they set the terms of the interview and generally it's held at their choice of venue, using their preferred facilities, and with minimal overhead for their existing staff.

Throwing in working for free on the prospective employer's real project, and IMHO this tips from unbalanced to downright insulting. If you want to hire a professional, give them some professional courtesy and treat them as such.

(I would almost certainly have ended the interview in that situation as well, though perhaps not with quite the same choice of words. But then this sort of one-sided relationship is why I choose not to work for anyone as an employee any more and instead run my own businesses, so I do have a well-established bias here.)

Hmm, obviously had something to get off my chest there. But interviews can go 2-3 rounds on the phone alone, 1 day or more on technical, and then more to actually talk to the team. It works for some companies because they have a steady stream of people that want to work for "Google" or whoever. Then everyone w/o the reputation of Google decide they should be like Google, follow suit, and you have the current madness.

There is the fact that a bad hire is extremely expensive, and it makes sense to be careful. But what working, skilled person has the time for such impersonal, multi-day efforts? When I put my resume on the street I had multiple inquiries from Yahoo, Amazon, Google, not to mention a bunch of smaller players. Just dealing with the proposed phone interviews would be a full time job, and I'd have to take a month off to go interview with them just to make an informed decision (why take the first job that comes along).

Something is seriously broken. So long as it is possible for me I'm not going to play the game, and do it the old school way - connections, people that know my work, and so on. But the trouble is, your connection ends up at a big company, and they are powerless to stop the HR/"best practices" juggernaut.

I've been lately thinking that perhaps we'd be better off with a more fluid style of hiring, say something involving real probation periods after which both parties assess how things are going and decide whether to continue. That approach is complicated, though, by the fact that on-boarding an employee is costly. Perhaps THAT's what we need to optimize.

Candidates are told up front about the probationary period and can back out if they want, but everybody who works there accepted it. It's amazing how many people make it through the hiring gauntlet (no matter how extensive, rigorous or complex she made it) and the completely bombed out during actual work.

Interestingly for the ones that don't work out, most of the time, the employees (I'm calling them that because that's what they are) opt to leave before the end of the probationary period. Nobody's upset about this because it's all handled professionally and sometimes people just don't work out.

However, the ones that make it past the probationary period are really really good employees. I think the average employment period with her company is around 5 years and while she's run the show they've had 99.999% up time in an industry that would probably get by just fine with an 80% up time.

You're right I'm talking more like 4-6 hours... but at that point you need to schedule the entire day for it so you can be on time, leave room for extra time to talk if the employer wants, etc.

So again, it's not that it is exactly 8 hours, but that it pretty much takes up a day.

"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.

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.

If that makes sense?

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.

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.

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.

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.

If you need a painter, you may want to see a painter's work before you hire him to paint your house. Maybe his portfolio was fake? Maybe that client reference is actually his uncle? Maybe he's never done this type of project!

So hire him to paint the shed first. You can't ask someone to do that for free...

ETA: I'm referring to product integrity. Do you want a highly complex and specialized product developed, at least in part, by people whose total exposure & involvement lasted less than a day and had basically no incentive to do it right?

All I'm saying is I wouldn't care if my work ended up in their code base vs an open source code base, and I'd prefer it to just being wiped from the hard drive after I was done. In return I'd get something very valuable - insight into the working conditions, what it is like to work with the senior dev, what the code base looks like, what the build and QA system is like, and so on.