Hacker News Reader

Comment by tokenadult | Hacker News Reader

Too aggressive in tone for what the gripe is here. I wouldn't hire this guy. Several of you long-time participants on Hacker News have noticed various iterations of my FAQ post on company hiring procedures,[1] and if you haven't read that, I invite you to follow the link and read it. Genuine work-sample tests are a GOOD idea in hiring, as most of the comments already here have said. Perhaps a full-day work sample feels too long to most job applicants, compared to a one-hour work sample (but how much would paying each applicant help with that?). There are also intellectual property issues here (but doesn't freedom of contract in most countries allow a way to resolve that issue?). But he doth protest too much, methinks.

In any job application situation, the company's concern is "can this applicant really do the job and do it well?" The applicant's concern is "will I really find a good fit in this company and advance my career here?" In general, a work-sample test is a very good idea for answering both kinds of questions, and anyway research shows that a work-sample test is a far more valid hiring procedure than most other hiring procedures that have been tried. Check my FAQ link for research citations on that topic.

[1] https://news.ycombinator.com/item?id=5227923

P.S. Yes, I intend to touch up my FAQ draft some more and then post it to my personal website. I just bookmarked the blog post kindly submitted here as another resource to refer to as I update my FAQ.

AFTER EDIT: I'd be happy to discuss with readers who disagree with this comment what the nature of your disagreement is. That helps me learn to make the FAQ better for its next posting on my website.

View on HN

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.

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.

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

E: My awful grammar.

It's interesting.

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.

Remember, you need the employee. The employee doesn't necessarily need the job if they're already employed (and sometimes even if they aren't).

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

No, I need /an/ employee, like they need /a/ job

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.

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

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.

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

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.

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

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.

It might as well signal of an over-complexed project design.

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!

Heyo. From time to time I do interviews at my employer which involve having someone hack on our code base, pair-programming style, for around an hour-ish.

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.

There's a big difference between talking through an interview for an hour with some questions on how they'll handle a code base with maybe a function or two here and there to demonstrate, and the following:

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

The actual red flag here is that the LD has no sense of software schedules or QA, or is feeling so pressured that he can't make time to prepare a well structured interview session.

The interviewee isn't going to be able to do it (correctly) without the guidance of the interviewer. Not if the project is of more than trivial complexity.

An actual example (from another domain): http://www.polycount.com/forum/showthread.php?t=127990

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

Software isn't art. If a company can break down its problems so much that complete outsiders can make them work in a day then they wouldn't need developers.

http://www.amazon.com/dp/0321751043

As we're all aware, adding extra developers to a project will cause it to finish sooner, so adding dozens of them for one day each should get your product out the door weeks ahead of schedule. Right? Right??

lol yeah this is what gets me too. I'd be pretty damn surprised if a company i was applying to (so they will be conceivably paying my bills for a long time...) would give me $450 to sit next to one of their programmers and slow him down for a day.

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

The less scrupulous English language schools do exactly this where I live. They'll post a job offering online and have you teach a "demo class" as part of your interview. In reality, that demo class is just a class that they didn't want to pay a substitute teacher for. Clever eh?

But in this case they offered an endless supply of teeth rotting soda and snacks and the possibility of playing ping pong (I assume only if he got his "work" done). I doubt the bridge builders are compensated with that! /sarcasm

Tone was rather aggressive, but still within the norm for someone being blindsided with high-stakes requirements for changing an unfamiliar codebase with an extremely aggressive deadline - and no compensation. Bait-and-switch: this situation wasn't an interview as expected, it was being assigned work with severe threat of being fired without due pay.

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.

Severe threat of being fired? He wasn't even working for them. If he wrote a bug and it made it into production, it would be 100% the fault of his mentor.

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

The point is that he would be working for them. That's why he was so aggressive in his posted rant. He'd be writing production code going live that very same day, and then (one may safely presume) he would be relieved of any further development duties, not allowed in the building again, and not paid for his work. The situation as described was indistinguishable from obvious deceptive practices (persuade person to do work under guise of "interview" with no intention of paying or hiring).

If you want to argue that he should be paid for his time I agree.

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.

You're missing the big picture. If all it was doing was slowing down a developer for a day then the company wouldn't bother interviewing anyone that way because all it is just a cost and there is no benefit to the company. However, the company does that because they decided there is a positive value, an actual benefit to hiring a needed developer and knowing that they can do the job.

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

Sounded like the change had to go out same day. You don't handle a short-term real deadline by slowing down a developer and releasing a candidate's code in production. To a lot of us, this didn't sound like an interview, this sounded like getting someone to do needed work for free. Yeah, maybe we're wrong and it really was a genuine interview question, problem is that's indistinguishable from the "free programmer for a day" interpretation.

Isn't the fact that the company is looking for employees an implicit statement that they would find it beneficial to have one? The corollary is that interviews to find employees, being currently The Way Hiring Is Done, must therefore also be of at least some benefit to the company. Whether this benefit outweighs the benefit of having the company's developers in their seats writing code instead of interviewing is at best subject to opinion.

I was talking about the marginal work product for that one day of work. We have to remind managers that developers are not cogs that can be slid in and out of a machine, and that's true.

I'd be happy to discuss with readers who disagree with this comment what the nature of your disagreement is.

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

Most interviews I've been in take essentially a whole day. Whether I add code to their codebase or not. I'd prefer working for free for the day... At least I'd have a better idea of what I'm getting into.

May I ask where you're from? I'm in the UK, and in my entire career I have never had a single visit to a prospective employer that lasted more than a half-day. It's not unusual (IME) to do that a couple of times, so maybe some places do everything on the same day, but I've never been through a recruitment process that wasn't all done in a couple of half-day visits at most. Maybe my experience is just coincidental and completely out of the mainstream.

I am not the person you are responding to, but multiple day interviews are pretty common in silicon valley. A few weeks ago I did a whole day interview of nothing but frigging white board exercises while they stared in their phones and look annoyed when I talked to them., and didn't question me about my resume or otherwise try to figure out if I was a fit or skilled beyond implementing memcpy twice in a row (I shit you not). That's a bit unfair, there were good questions, and good interviewers as well, but it was still just "find the bug", "implement XX". Then they called me and asked for another round. Uh, no. I then hear I'm ungrateful because they were prepared to throw a bunch of money at me. Oh la-de-friggin-da.

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.

Thank you for shining a light on this madness. I've had the same experiences here in SV and these "extreme hiring" practices don't seem sustainable to me.

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.

A very successful department lead I know exclusively uses a probationary hiring practice on top of a pretty extensive set of interviews and coding tests (a bit excessive for my taste, but meh).

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.

Yeah I've interviewed in Seattle and Chicago mostly. A couple half day visits sounds like a day's worth to me. :)

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.

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.

If that makes sense?

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.

You're totally right, but eliminating risk costs time/effort/money. So pay him. You've already seen his CV, talked to references, interviewed him, done a technical interview, what more do you want?

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

Thanks for compiling this faq, btw. The unstructured nature of HN tends to work against any sort of historical or accumulated knowledge. I have a vision of people stepping up and doing this for different CRTs (Commonly Recurring Topics) on HN and pretty soon we're the StackOverflow of... well, something.

The anger comes from being put on the spot like that. There are clear ethical concerns here and the interviewer is just bulldozing over them. I don't know many people that could handle that situation gracefully.

this is a little off topic, but related: I've seen it time and again where an applicant DOES spend the time to do work for free/part of the interview process (I won't get into this religious war), and then not get any response back from the potential employer. Not a yay, nor a nay. That, my friends, is exploitation.....

For lack of a better mechanism, I'm commenting here so that I can read your very informative user page when I get home later. Sorry for the noise all.

Sure - when restaurants take on a new cook or chef, they may well ask him to produce a dish or two, but none of those dishes will be sold to paying customers outside. The staff/management will check them, try them, review them, but will not be selling them to the customers outside.

Undiscussed: the paying customers would understandably be outraged to discover live code which they paid for was created by non-employees operating without pay under adverse conditions. You want to work for a company that would do that to their customers?

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?

Is this sarcasm? I don't think most people care about the conditions workers have to work in. This a problem that bridges many industries from chocolate to diamonds to electronic products to clothing.

But why do we care? In your specific example (which I do recognize as being proffered as an analogy not an equality), I'd rather the food went to a hungry person than picked at then dumped in the trash. Of course it can't work that way because after all they need to taste your food to evaluate it.

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.

Reply on news.ycombinator.com