11 ms·
> 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
by columbo 13y ago
> 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.
- danielweber 13y agoRight. 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
- peteretep 13y agoPerhaps, 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.
- danielweber 13y agoI 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.
- Tyrannosaurs 13y agoBut 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.
- jwarkentin 13y agoA 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.
- fat0wl 13y agothis 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.
- normalocity 13y agoOn 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.
- jwarkentin 13y agoIt 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.
- nakovet 13y agoHe 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.
- bane 13y agoWhen you call it an interview, but are in fact using it as a bit of free temp day labor without paying for the work accomplished.
- Tactic 13y agoIt is called an opportunity cost. 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.
- Nursie 13y ago>> 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.
- Tyrannosaurs 13y agoIf you take the time others need to spend with them getting them up to speed away, I generally consider it good if they break even in the first month.
- codeonfire 13y agoThat'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.
- alandarev 13y agoIt might as well signal of an over-complexed project design.
- Nursie 13y agoSome 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!
- Silhouette 13y agoOtherwise 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.