> Surely the disagreement should be obvious? If they interview 50 candidates and get each candidate to do a free day of work, they're exploiting the candidates and the market.
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.
Otherwise it's a pair-programming test with massive hand-holding from another developer
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.
Right. If the application is easy enough to define that someone completely new can code it up in a day, they can just send it to India and be done with it.
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
Perhaps, but that's not what he's complaining about. He's complaining that he's providing them business value for free. He's not, he's tying up one of their Senior Devs for a day, which is a pretty good sign that they really want to hire the best people.
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.
If the company sees hiring as "tying up one of their Senior Devs for a day" rather than something so important that it warrants investing serious time/resources/Devs on it, then I don't think they "really want to hire the best people" at all.
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.
I think he fundamentally misunderstands the employer-employee relationship.
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.
But this isn't an employer-employee relationship. It's a prospective employer-employee relationship.
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.
A first interview should never be sitting down with code. That's a waste of everyone's time. The first interview should probably happen over the phone, though it could be in person. There are too many people out there looking for programming jobs that can't pass the idiot test. In the last interview I went on the first thing they had me do was write a for loop. They explained that, while it may sound stupid, too many of the people that came in couldn't even do that. Where I work right now, we have been trying to hire for a PHP job, but most of the people they've brought in don't know basic things like what an associative array is.
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.
I agree about the first interview, though I'd also say that you should agree in advance what's covered and if both parties want to code while it's not what I'd do then who am I to say they can't.
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.
Sure, your company invests the time of many people in the process. But you do it because you've determined that overall it adds value to have another employee. It's worth the cost. Hopefully, most things that they would otherwise be doing if not searching for a candidate would also add or maintain value of some sort (whether monetary or not). So really, it's just another value adding task that must be done. So we've established that in the end you gain more value by having that employee than it costs to hire them.
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.
Someone else said that it wasn't a good use of a developers time to give up a day for interviews because the potential return wasn't good enough. I completely accept that. My take is that, in the market I operate in at least, spending a day doing an interview with someone who isn't really that interested probably isn't the best use of my time either.
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?
I absolutely agree. I think that it's important to first establish interest and weed out candidates that are obviously unqualified. You can figure a lot of that out in a short amount of time. While some of your best candidates may already be employed and thus only casually interested initially, at least for someone like myself that interest could increase significantly after sitting down and chatting about the company and projects for a bit. If I were to then become really interested it could be worth spending a lot more time in an interview process.
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.
In your perspective, businesses paying for travel expenses of candidates are being scammed.
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.
1) Maybe it's just the UK but paying travel costs isn't standard here. That might change if someone was coming a long way but that would be very rare.
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.
I see your way of thinking. As someone pointed out already, the issue of two contradicting opinions is due to us thinking from single perspectives. Nevertheless, let us see where it will lead us to:
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.
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.
If they don't need or want this job why are they coming for an interview at all?
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 they don't need or want this job why are they coming for an interview at all?
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 don't assume every candidate is desperate, but I do assume that they have an interest in working for us.
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?
> 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.
An interview is a two way process. The employer finds out about you, you find out bout the company. There are interviews where I thought my skillset was a complete mismatch, but got the job, and others where I got scared off by what appeared to be far too much enthusiasm for the company (seemed kind of false to me). I also realised I would be getting 8 days less holiday than I was on.
Monetary compensation for something like that is hard, though. There's no societal standard on the value of a person's day, and it opens the possibility of abuse on the other end (professional interview-taker). In practice, there is an intangible compensation, in the form of a reasonable expectation of being hired.
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).
On what planet is there a tradition of paying for the time spent in an interview? The writer of the article knew it was an interview, and presumably knew approximately how long the interview would be.
He knew he was in an interview for sure, however the terms have changes as soon as the lead developer asked him to code in the current application in order to test his skills.
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.
It is common practice when hiring a developer to pay them for time spent programming if it's any significant amount. I've never heard of paying for all the time spent in the interview, or for time spent if it's just something small and simple to get a quick feel for skill. But if they're asking for more than an hour or two or if they're asking for new features added to their existing code base, it's completely fair to ask for compensation.
this is what i don't get though... why a few hundred why $450? Why not just a stipend? $100, maybe 200. Basically just to be polite, not because they actually owe you anything. Companies simply shouldn't have to pay per candidate they interview. It's not the way the job market has ever worked really. I guess a stipend for pair programming may make it clearer that they're serious so people don't whine, but it seems silly since you should be in the market for a job not a day's work.
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.
>> 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.
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.
That's a very one-sided metric. There is a large range of definitions of large and complex. The dev process or team size might make it extremely difficult for outsiders to contribute. I can understand why you and others would like to attribute all productivity squarely on skill. In almost all cases, everyone is trying to manipulate the consensus of who's productive and who's not, who made a good hire, who has good employees, etc.
Some systems are needfully complex, because they do a hell of a lot.
And some are needlessly complex but you inherited them from another, long-gone team and somebody has to maintain, improve and update them, unfortunately!
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.