I will not hack on your codebase for free in an interview | Hacker News Reader

I will not hack on your codebase for free in an interview

hownottohireadeveloper.blogspot.co.uk

159 pointsgroundCode244 comments

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.

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.

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

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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?

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

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

You know what? I wish companies let me play with their codebase in an interview. At least then I could see how much truth there is to all the "yeah we totally have a great automated test suite and build process" I get told during interviews.

A whole day is unreasonable, but I'd jump at the chance to do what TFA describes as "free work" for an hour or so.

I wish I could have gone back in time to look at a codebase before saying yes to a job. I wouldn't have taken it had I seen it.

I would hate to find myself in a situation like that, but bad code isn't the only thing to look out for. I would dread finding out 80% of their code came from open source and that they made it a point to not contribute the changes back to the community. This would really rile my feathers. Particularly if they asked applicants about their open source contributions.

The truth of this statement makes me weep inside.

Jump at the chance to look at the codebase. A whole day coding, I get the concern there, but yes, otherwise, I urge you a thousand times, look at the codebase.

For bonus points: can they provide instructions for you that allow you to go from zero to working dev-environment within a day?

At my last company, we gave a toy test outside the codebase for code production skills (basically a skeleton and some unit test to make green) and a simple task (changing a color, swapping an icon etc.) inside the production code for the navigation and orientation skills. A secondary target was that the candidate had seen the real production code in the real IDE, with a future co-worker next to him before accepting the job.

We would hog the candidate's time for half a day, but it was not half a day of production for us, it was also a lengthy team lunch at a restaurant, and a lot of talk.

Ah, that's a good idea. I'd negotiate it down to an hour or two, then when they pull me over to an iMac, I'd pull out my laptop instead and be like, "OK, let's do this! Where's the repo? Are you using Vagrant? Great, I already have it installed. What's the command to run the tests?"

If after the allotted time I still don't have a working dev environment, well, that job's not for me.

So here's the problem:

1) A great way to assess your technical chops is to watch you code.

2) A great way to see if you can do the actual work that you'll be expected to do on a day-to-day basis is to work on a real-world task on the team's actual codebase.

3) If you have what it takes, then it's crappy to have you "work for free" for a day. But if, after the day's over, it's clear that you don't have what it takes ... then have you really "worked for free"? (Remember, freelancers don't get paid unless they deliver.)

Here are some ways to address this problem:

1) Do paired programming on the actual codebase -- but on an old problem, the solution to which has already been implemented in production. This makes it clearer that the exercise is merely to assess your skills and not to get free labor out of you.

2) Pay all in-person interviews for their time. Once they've passed the phone screen and whatever other preliminary hurdles you've set up, you should feel pretty good that they're not just wasting your time. So compensate them.

3) If you don't have the budget to do #2, which -- let's face it -- is uncommon, then perhaps you could offer a signing bonus to anyone you end up hiring that essentially repays them for their time.

Regarding solution (2) it is probably that you should offer to pay for their time. Many people can't accept paid work under their current contracts.

Also whatever the plan if the interview is going to be for more than a couple of hours let the interviewee know the rough plan in advance.

4) Do paired programming on an actual feature or problem for an hour or two. Work with your potential team members and discuss the feature, do some rapid prototyping etc.

The assumption isn't that your code will be deployed at the end of the day, but that both side will get to see how the other works and you don't waste too much of anyone's time if it's not a good fit.

"perhaps you could offer a signing bonus"

Comp time. You wasted a vacation day at your previous employer by "working" here so your official start date is Friday but don't bother coming in until Monday morning. Seems simple enough.

Or you come into work on your start date but I'm not giving you any work assignments of any sort for n+1 days where n is whatever is normal (zero?)

Or start on Monday but don't bother coming in the following Friday.

> (Remember, freelancers don't get paid unless they deliver.)

Not if the freelancing contract has a kill-fee or partial payments upfront. Both of which are really good ideas, because they prevent clients from taking advantage of freelancers.

I had to look up the definition of a kill-fee http://freelancewrite.about.com/od/glossary/g/KillFee.htm

Pay the people for their time

"freelancers don't get paid unless they deliver"

Well, depends. If you're having a clear deliverable I agree, if you're getting them for staying there and following the team, pay the person.

So here's MY opinion on the problem:

1. I totally agree with that. Yeah, watch someone code. Do a short hackathon. But not a day's worth. Seriously. 2. Using the actual codebase is fine but the interview starts to stink when the interviewer says "I gotta get this pushed live by the end of the day so let's get 'working'". It's not about "is he genuine?", it's about "that's a little weird, does he even want to interview?" 3. Here's an issue. What if you have 10 great people. I've been in a hiring process where it was DIFFICULT to find a person. So you get 10 days worth of free work and have to hire someone based on OTHER metrics. Be it budget, their demeanor, or whatever else.

Also, freelancers (same as contractors) get by the HOUR unless contractually provided otherwise. Meaning that it's not just about the deliverables. If I was doing freelance work on a big project, had a scope, I'd get paid by the hour. If the company cut me off (didn't let me finish), they would pay for that hourly work, not for what I delivered. Same with scope revisions and other stuff like that. Sometimes you even work for a company HOURLY, doing random work that they need done. Again, it's HOURLY.

This topic comes up here all the time and I'm always shocked to see that this is even considered as a hiring practice and I'm surprised it's not outright illegal.

This problem exists in every field and for every kind of job. Nobody takes seriously the notion that a book-keeper candidate should do your accounting for a day to see if they should be hired, or have a contract manager negotiate a contract for a day for free, or a designer design for you for a day. So why are developers freed from this?

Because it's feasible for a developer to sit down in front of a terminal for a few hours and start hacking away?

Here's part of the problem from the candidate PoV

1) It's slave labor (obvious) and opens you up for a never ending series of small, but annoying lawsuits if you don't hire the candidates.

2) Candidate doesn't know if you're serious about hiring, or just doing a cattle call. There's a lot of reasons companies do this, but it's a practice used by some very well funded startups that wastes unbelievable amounts of people's time and is like a cancer in the industry.

3) Candidate likely has plenty of other irons in the fire, and your company isn't a special snowflake. If they're currently employed it's even worse as they have to figure out how to take time off of work to waste doing free work for somebody else. Now let's say they have to do this for the 20 companies they applied to, that's a month off of work!

4) Development on complex codebases is hard, most engineering companies don't really expect a new hire to be very productive on their codebase for a few months at best. It doesn't actually test them on their day-to-day as much as anybody might think, because their day-to-day job function will rapidly change over their first six months as they start to wrap their brains around the work.

What is appropriate?

1) Ask for a portfolio, open source projects, other work they've done, etc. Hopefully they have some kind of work history they can show off.

2) Irritating, but ask them to complete basic development tasks -- fizzbuzz is a good example. Surprisingly, most bad engineers will be stumped by surprisingly simple questions like "write a for loop" or "write a basic SQL query". If they pass that, ask more and more complex questions until they're at the level you need. You can usually figure out a candidate's skillset within 10 questions. But please, don't waste anybody's time with brain teasers and puzzles and other nonsense. Keep it focused and keep it real.

3) Actually have a conversation with the candidate. Plumb their knowledge. Ask them about various frameworks they've used, or languages they've experimented with or whatever. People who know their stuff can usually talk endlessly about their past experiences, people who don't can't and you end up with "well....C++ is nice, but Lisp is a great language!". Too many hiring processes forget this part of interviewing because it takes practice to get good at "interrogating". But it gets you so much soft information about a person as well.

4) With questionable candidates that you're 50-50 on, be open to offering probationary employment. 30-days, or 90-days or something. It must be well structured (weekly check-points, options to leave after the first 30 days, etc.), and you have to take it seriously. It's up-to the candidate if they want to take this or move on to other opportunities. If they move on, nobody's time was wasted. If they really need something right now and they take it, you have some exit valves if they stink, and if they're promising you can adjust final employment one-way or the other.

5) Something I hated at first, but have come around to a bit is the idea of a take-home problem they can work on at their leisure. Perhaps a problem that wouldn't take more than 2-4 hours to work on. Why is this different then having them hack on your code? Because you can make it not-your actual code, and can use it to concisely test exactly what you're looking for. Plus they're not taking time off of work to do this. They can spit-shine and polish their response as much as possible and really show off if they want.

A voice of reason. I've had too much personal experience with bad companies and bad interviewing processes for my own good.

I think that #3 is spot on. Most companies AREN'T that special snowflake. Just like I would not tolerate a company with ridiculous demands, I imagine a company would not tolerate me. I'm not a snowflake, neither are they. This is a business negotiation between two parties.

As far as "what is appropriate", you're spot on, too. I'd just like to add on some details per point from what I've seen:

1. you can easily tell when a project is just NOT theirs. I've heard of people (from hiring managers that interviewed them) that copy (not fork!) someone else's projects and slap their name on it. If you're a programmer, you should see these stick out. If you're still concerned, go talk to them about the project. You'll learn a lot about their knowledge.

2. Exactly. Just like you would not ask a mathematician to calculate if a train with thirty tons of coal is going at the speed of 70mph from NY to LA, and another train with sixty tons of radioactive material is going the opposite direction at 230 mph but accelerating at 3 mph...you know what I mean.

3. This is the best point. You'll quickly find if someone IS or IS NOT knowledgeable about a subject. Not just by talking about the "top article on HN!" or some brand new framework, but having a conversation about work, problems they've encountered and how they've solved them, how they like to work etc. You learn not just about the person but a lot about their experience.

4. i've never really seen probationary employment in practice but companies seem willing to do contract work or contract-to-full-time type deals. Sounds very similar

5. Spot on. I find these annoying however, because I've been in a situation where I had 3 projects like these to finish. All of them small 2-4 hour projects but all to do over the weekend. I guess it wasn't that much of a big deal in the end and I do prefer this to any other type of "test".

Probationary employment is guaranteed for the most part here in Aus. Takes the risk out somewhat for both parties, especially considering it's harder to fire.

Well, there is a probationary period here (US) too but it doesn't make much sense employing 20 developers just to figure out which one you want to join full time.

Probationary also pretty much guarantees that you won't find the best programmers.

not necessarily. I completely expect the initial 30-60 days to be in that transitional/probationary timeframe (could also mean I'm not among the `best programmers`).

But to each his own.

I double #3. I guarantee if I can talk with a candidate for an hour over coffee, I can tell if they have a clue. Same if you talk with me. Assuming of course the interviewer is of similar experience. Not asking trick questions, just digging into the actual experience of doing work they claim to have done. Working on something for months should allow the candidate to talk for hours if necessary. Or not if it's a lie.

Remember, freelancers don't get paid unless they deliver.

Contract developers on a day rate very much do get paid time (and materials). If they can't afford a day of his time to figure out if they want him they shouldn't be interviewing him.

One of the common interview questions for a non-technical management/marketing person is: "having researched our market, company and competitive position, what strategies do you think we should pursue?"

Imagine if I were an experienced exec or strategy/marketing consultant, came up with a few interesting ideas and demanded to be paid for them on the spot? I'd get laughed out of the room.

Similarly, when you sell a consulting project, you're expected to do a certain amount of analysis in your pitch, with no guarantee of being chosen for paid work.

But none of them will do 8 hours of analysis and put it into a report.

I was going to add that. It's one thing where a developer gets asked, "Well, if you could rearchitect (or create) our application, what would you do?" and then discuss what frameworks, where to focus on caching and optimization, discuss technology, paradigm etc.

And I've been asked this before, "We serve a million visitors a day, what kind of caching and optimizations would you implement to handle that type of traffic?" Completely fair question.

It's another to do that work.

>> (Remember, freelancers don't get paid unless they deliver.)

That depends on the freelancer. I charge a day rate.

> Do paired programming on the actual codebase -- but on an old problem

That's what I was thinking. Which is why I thought "uh oh" when the interviewer said they needed the features live later that day. So, not only does the coder get to do free work for the interviewer, there's time pressure as well. Sweet!

Not to mention shipping a new feature on a codebase you are, by definition, not familiar with. I'd at least want to budget time for testing the thing. Not to mention I have severe doubts in the competence of someone who lets random interviewees edit their live code.

So I have gathered that these are some of the populations of developers:

1. There is a class of people who will not do algorithmic interviews, who think they are puzzles and not exactly what a programmer does on a day to day basis.

2. There is a class of people who think doing homework assignments makes no sense, especially if you have a full time job and this eats into your evenings.

3. There is another class of programmers who won't work on coding projects because you may potentially be exploited.

For a group of people with highly specialized skills (who get underpaid when compared to lawyers and doctors), we do tend to complain a lot.

Don't forget the 4'th group, the class of programmers who refuse to put code on github.

I've gathered there is a population of "developers" who refuse to demonstrate the ability to code at any stage of the interview process.

(The OP is definitely not part of that crowd, given his willingness to submit a pull req to some open source project.)

Really? I am required to have an account with Github, to prove something?

In the real world, some of us work on highly proprietary code bases, where putting any code up online could expose the risk of future lawsuits or prosecutions, certainly this has already happened to individuals in the industry.

Thankfully in the real world there are some sensible and mature interviewers who are able to look beyond the heinous crime of not having a Github presence.

People who can't easily demonstrate their skills are always at a disadvantage relative to people who can.

For every one person who is great but can't publicize any of the good code they write, there are a lot of people who simply suck. Differentiating between them is expensive (read: hours interviewing the good candidate, many more hours interviewing bad candidates) which is why the people with a good github/bitbucket/ftp server full of code are at the top of my list. If they all bomb the interview, maybe I'll move down the list to the people who's skills are unknown.

This simple reality is why one should demand more money from employers who impose restrictions on what one does outside of work.

On the flip side, I have very rarely found an interviewer who has actually read through my github code. It is more like they are scanning through an imaginary checklist of 'has github account, has repositories in it' etc. The other day I got asked by an interviewer if I knew python. This was rather strange to me because we had just talked about one of my github projects ...which was an ml library for python.

My point is that if having a github account becomes a silly barrier like having an education from top school, it kind of defeats the point of being fair whilst also acquiring good people.

tl;dr; If you take a good practice and cargo cult it, you'll get bad results.

When I was the interviewer, the most useful lines to determining competency tended to be find github code, ask pointed questions.

As someone who is now interviewing for a new job. I've had three interviews this week ask pointed questions on github contributions including requests for me to change things on the spot ( or talk through a change that might occur).

Exactly. A lot of work is proprietary and confidential. Should you have a side project to show, sure, if you can do that without getting fired, or worse sued. As a salaried employee, In the past, I have signed employment contracts that basically state they own anything I write. I sure I'm not alone.

Well, I'm in the 4th group, then.

My current job, and every previous development job has clauses about outside development, and what internal hoops have to be jumped through. I'm compensated for that restriction, so I don't mind.

Even lacking those restrictions, contributing to open source projects just isn't really my thing, and my personal projects are just that -- personal, and are usually ugly, hacked together in a hurry and never revisited solutions to specific problems, not resume filler.

If you can't find some way to determine if I'm a good fit without looking at github, having me do unpaid work, or playing trivia games, you need to revise your hiring policies.

Why have we, as a group, allowed the creation of this requirement, official or otherwise, that we have a public portfolio of work we've done on our own time?

Don't be so hard on yourself. Any code that solved a problem is very impressive to an interviewer, showing independent iniative and get-things-done. Even silly seeming things like an AppleScript to copy birthdays from your address book to a text file.

Just because you don't have a Github account, doesn't mean there aren't a plethora of other ways to demonstrate the ability to code with samples etc. Don't conflate no Github account with no ability to demonstrate code.

If you want to be pedantic, I should have a said "a github, bitbucket, gitorious, darcs.net or ftp server full of fortran".

I think it is more than just being underpaid. Doctors, dentists and lawyers do not have to go through such stupid recruiting processes. I've known people to get hired in 15-20 minutes. The assumption is that your education and previous work experience is worth something.

In tech, it feels that one's education and work experience is what gets you the interview. Then, it doesn't matter. I'm tired of hearing the old "developer with 10 years of work experience who can't do fizbuzz". Rather than a lack of competence, the issues are:

1) Most humans can only hold so much information in their head at a given time

2) Tech/dev tool updates move ridiculously fast. It seems they are moving faster as time goes on.

Here's an idea: hire smart people. Even if they don't know your particular stack. Here's another idea that will never happen: lets all agree to be tested for interviews in one tech platform (that'll happen when pigs fly). We dismiss these issues now because we are young and hip. Eventually, many of us will have kids who we want to spend with. That's when we'll be on the other side of the table and have our oh-shit moment. I guess I shouldn't complain about the inevitable.

> I think it is more than just being underpaid. Doctors, dentists and lawyers do not have to go through such stupid recruiting processes. I've known people to get hired in 15-20 minutes. The assumption is that your education and previous work experience is worth something.

This is also true for PhD students and research labs. Like if you are a C.S. PhD student interviewing at Microsoft Research or in an academic position, no one is going to ask you code up insertion sort. They look at your papers and evaluate you. I sometimes regret not doing a PhD for this very reason.

> Here's an idea: hire smart people. Even if they don't know your particular stack.

What the fuck does smart even mean anyway? How do you find out in the space of 5 one hour interviews if a person is smart or not?

1. If smart means problem solving ability, the way we test it now is a huge crock of shit because it is hard to abstract out domain specific elements from pure problem solving. I mean if you take any Math olympiad book, there are no pure problems beyond the puzzle level, most of them have a few tools of the trade that you can use. I remember someone posting here that IQ tests are illegal and probably not very good.

2. If smart means suave, sophisticated or looks like me (the accepted buzzword is "cultural fit"), it is going to not scale very well.

I've always thought that (in regard with most tasks) being smart would be another way to putting "gets sh*t done." I'm by no means a great programmer (I'm a mathematician and could only stand a CS degree for around a year before deciding most of it was boring and I'd rather get into the interesting stuff on my own) but I can get things done. Sometimes the code is ugly, I forget to add test coverage (or god forbid, error checking!) or it is unnecessarily convoluted. But on the end of the day, it's doing its job. It can be refined later on, and each error check/test coverage problem/non-idiomatic language feature I forget is a lesson for the next project in the same language/stack. I'm smart? Yeah, think so, at least with this narrow-minded definition. In other aspects, I'm not (like when confronted with these interview-like puzzles: I've always hated them, even as math gimmicks.)

See this is where it gets into the realm of being subjective. I used to think that getting shit done was the only prime directive that matter. Until, one fine day I found myself given legacy code written in PHP by some dude who hadn't been in the company for years and years. Suppose you had come by my table during that dark and painful period and asked me if I would hire the dude, I would probably have said no, god no. On the flip side, there is a tradeoff. You can't realistically expect to ship if you expect every module to be pretty as fuck. Again, this is also something you realize with more experience? Are you then smarter? This is kind of getting into theory of the mind territory here.

As with all things, it's a trade-off, and there is a balance somewhere in the middle. i.e. Don't do really dumb things like copy-pasting code everywhere, but also don't feel that every line of code must be a masterpiece. There isn't one rule or paradigm for all situations; you just have to use your best judgment.

As redblackthree says below, there's some leeway in there. I guess it comes down to knowing what tradeoffs are you doing to get it done sooner. In my case I usually know where I've done some cheapish job and mark the code area with a "FIX: explanation of what should be done" for when I have time for that. I also eventually come back and clean up whatever code mess I got, or at least comment the mess so it doesn't come biting back at me in the future.

> This is also true for PhD students and research labs. Like if you are a C.S. PhD student interviewing at Microsoft Research or in an academic position, no one is going to ask you code up insertion sort. They look at your papers and evaluate you. I sometimes regret not doing a PhD for this very reason.

this has not been my experience, lab / academic jobs are a day of interviews which probably will not have any programming questions because you're hiring a scientist, not a staff programmer, but you will talk about research, ideas, and be expected to think and produce insights on the spot, and you as a candidate will give an hourlong talk. the decision is not made before you show up and the desires of the hiring body are very fickle.

>I'm tired of hearing the old "developer with 10 years of work experience who can't do fizbuzz"

Then we need to solve that problem, not bury our heads in the sand and pretend it doesn't exist. When you post a job ad for a software development position, you should receive absolutely no applications from people incapable of fizzbuzz. Yet we the majority of applications we receive are from such people. That problem won't go away if we just say "well, you had a job before, so that's good enough for me!" and hire them.

I know two CS PhDs who would fit into the "can't code FizBuzz" without help. Both are machine learning/stats experts. Both also "code" in MatLab/R all the time.

However, it would take a developer 5 minutes to realize they can't code shit. They are good at other stuff ... sure ... and they shouldn't be applying for programmer jobs.

I think startups are trying to emulate the Google way of hiring and that is to their detriment. There used to be a time where Microsoft hired an MD/PhD to become a coder ... because he had raw intellectual horse power and a desire to learn. I know quite a few PhDs who would love to work for a startup. Most of them have gotten dejected after the interview process. The common complaint I hear is "interview made me think I'm going to be a code monkey. F that. I'll keep my cushy research job with a door on my office".

Well, those of us who don't complain about this stuff don't get heard much.

I think people ought to stop artificially limiting themselves and trying to pick overly-precise categories for themselves. You think algorithmic interviews are puzzles? What exactly is wrong with sitting down and doing some puzzles? Puzzles are fun! Homework assignments are fun! Coding projects are fun! If an interviewer sat me down with a truck and some tools and handed me the maintenance manual and said to me, install a new fuel injector using these materials and we'll see how you do, I'd say, hell yes! Sounds like fun! Tests my ability to think and try something new, too.

> For a group of people with highly specialized skills (who get underpaid when compared to lawyers and doctors)...

Too broad a brush stroke there. The vast majority of software development does not require highly specialized skills and is more comparable to nurses and paralegals than doctors or lawyers. (Not trying to be disparaging here, either to nurses/paralegals or developers, just running with your analogy.)

You don't think software development itself is a highly specialized skill? It's true that what we type might not be PhD research, but just learning a programming language is a rare thing.

It certainly takes less schooling than doctor or lawyer. Admittedly part of that might be that there are things we can work on of less consequence as we figure things out, so we need a little less prep for a exercising comparably specialized skill. Of course, part of the pay discrepancy is also going to be covering the difference in schooling costs = who spends longer paying off student loans, on average?

Part of that schooling involves intense preparation for tests put forth by the state before you are even legally allowed to perform the work you've been studying for.

That, too.

Ah, but here's the thing. You can be part of all 3 of those groups (and yummyfajitas' 4th group with no github profile), and still have an easy time picking up work. You just need to have something you can point to.

So we can skip all the above and the developer in question can show you several medium to large web applications running in production, all written entirely by him, some combining to pay his rent, one having won its category (technical achievement) at SXSW.

"There. That's what I can do", he says. "And here's my hourly rate."

No complaining necessary. Get yourself provably good, and all this interview silliness goes away forever.

Individual projects don't show how you work on a team though, nor do they show quality of code unless you submit code samples and those can be and are sometimes faked (taken from an open source project or just not written by them).

Pair programming on the other hand is an excellent way to evaluate how an employee deals with other developers and to get a feel for their quality of code.

Of course as many have suggested in other places in this thread you don't need to do new work. When interviewing candidates myself I like to find a feature/problem from the last 6 months that uses the core job skills I'm looking for and have them work through that. Using current development can feel like free work for them and often doesn't demonstrate the full range of skills you are looking for.

In my industry (copywriting), candidates demonstrate their abilities to employers with a portfolio of their best work. Would this work for programmers?

You will never see my best work because it's owned by other people.

This is easy because typically your best work is put out in public. This is rather difficult with most company source code. Also copywriting is probably not a team effort.

Hey, I'd take the offer - you get to see if the coding style and the procedures used are even remotely what you expect.

I personally would never join a place still using CVS for source code management, even SVN is something I'd like to have a night of good sleep before accepting. Same for not having proper bug tracker systems.

Edit: Also, as the introduction to How Stuff Works will likely be done by a dev team member, this presents you with the ability to ask the dev guys how the job really is, and not what a clueless HR idiot tries to sell you.

These are easy things to ask directly without working for free ;)

In most cases (distinct HR department) the HR guy doing the interview will have no idea what processes the IT department uses.

Worse case, the HR guy is actually a decent IT guy (so that the IT-related questions in the interview are actually fair), but he has multiple different IT departments which each use different operations policies so he can't answer your detail question. Happens especially in bigger companies or, as I experienced, in government.

A dummy project is your best bet. It provides a nice stable fixture from which you can gather repeatable data, and you can tweak it over time as you discover flaws in it.

If you're already employed, you're probably taking a day of vacation or sick time. So you're being paid. On the other hand, you're losing a day of vacation or sick time. This has been true for years and years (but that doesn't make it right).

Frankly I would seriously worry about trade secret exposure, and any restraint against "moonlighting" or competition by your current employer (some employers forbid working on open source as well). Working on live code puts both parties at risk here.

There are indeed companies where, if I had worked on their live code, I would never have worked there (one company was where I learned the phrase "train wreck").

> even SVN is something I'd like to have a night of good sleep before accepting.

Why's that? SVN may not be fashionable, but it's centralised, has ACLs and a hook system.

Because it will be a huge mess once you hit your first merge conflict or want to use proper branches. SVN is usable for source code management, but not really for efficient collaboration.

edit: And if the SVN server goes down / messed up by someone, you're essentially forced to sit around and staring into the sky. With git, all you may have to do is fiddle a bit with merging if someone did a git push --force. And if the server is down, you still are able to work on your own.

As someone who uses git and svn a lot, I'll say that git has more end user features. You can do so much more with git than svn. If you have to work on svn, you'll have to give up those features.

It might be a warning sign as well. An organisation on svn might be an organisation that doesn't upgrade and is resistant to change.

Both of the posts on that blog just read as sort of bitter and sad to me. I'm sorry you can't find a job, dude, but maybe your anger management is getting in the way.

Agreed. The author sounds a bit agressive.

Perhaps it would have gone better to politely explain why he could not / would not want to work an entire day for free. Also, an entire day? Since when are tests that long?

I understand where he's coming from but he comes off as very aggressive. He could have made it passive aggressive though... Did he have to sign over his IP rights before working on it? He could have worked on it and got a feel for things. If he liked the code and company and salary negotiations no harm done. If not, and he wishes to be passive aggressive argue that they owe him money for IP or he'll sue for copy right infringement. Company's that do this walk a fine legal line. I like to see and understand a companies risk assessment, mitigation, and contigency planning...

If the author was really being asked to implement features in a codebase that were expected to go live at end of day that's just exploitative and they have every right to be upset at being asked to do that for free.

But who offers to do a technical test for the entire day? For me, any interview going longer than an hour has some serious issues...

Compare to some actual technical tests.

A CCIE test has varied thru the ages but seems to have stabilized at an hour. I have no idea what an entry level dotcom would need with someone operating at that level, but it probably happens. The problem is at a CCIE lab test you're being evaluated by people more or less as good as you, but your average dotcom will be hiring you because you know more than them in a specific area not because they're smarter than you and they need to staff a team of underlings. probably. Maybe A / B teams or rotating pager duty with another CCIE. Maybe.

Look into the length of an oral PHD thesis defense. That's usually not a full day.

I would agree that in comparison to existing standards a full day is way too long.

Those are once-off tests. I didn't have to take an SAT for every college I applied to 5 million years ago, but I took one, and all the schools used the test.

If I'm looking at three places and each of them want me to sacrifice a day for the interview, that's a lot of my time, especially if I am currently employed.

should read: CCIE test .. one day. Same length as the pair programming exercise.

This guy is just lashing out because he can't find a job - personally I don't believe him about his interview code being released at the end of the day - that sounds much like the interviewer was trying to create a little pressure to assess how he performs under those conditions.

working during an interview isn't "for free" - both the interviewers and the interviewee are both taking a considerable cost in time which is a contract entered into by both parties for the best interest of both. The company spends a day also.

I see this from the other side far more often. Candidates that come in that claim to be able to code and yet when put on the spot can't do much of anything, wasting huge amounts of time and money. When I fly someone cross-country for an interview I don't go ranting online that I wasted that money.

I'm not sorry he can't find a job, he needs to grow up and stop whining and grok how this stuff actually works.

How dare this guy get angry about being asked to work for free for someone else's profit.

Then politely say "I don't think this is appropriate, but thanks for the opportunity." Setting up a blog that so far is exclusively for complaining about interviews seems a bit much.

Just looking at his two blog posts, I think that the company's hiring practice worked perfectly and weeded out someone who may be technically competent, but is toxic to the work environment.

His tone is aggressive and completely self centred - imagine trying to have a meeting with him where he sticks stubbornly to his opinion, refusing to listen to other opinions and potentially throws tantrums whenever he doesn't get his own way.

Secondly, the fact he refuses to pair program with a developer on the existing code base ' to see how he works within a team / on code - suggests that he probably would equally be unlikely to do anything outside of what he is technically being paid for.

I'm not saying anyone should work for free, but sometimes you have to help out, whether it's working a bit later or helping during a crunch time. He comes across like he only would want to work on things that interest him, during the hours he's paid and then be out the door.

I think the company that was hiring did a good job of filtering him out.

Part of being a developer is there's going to be some crap I can't shield you from as your manager, despite my best intentions. If I think you are going to suddenly turn barrack-room lawyer on me, or tell me it's not part of your job, or anything other than deal with it professionally and helpfully, you're a poor team fit.

And if you understand so little about how programming teams work, and think that you are going to - with no context of the codebase or problem space - significantly improve my Senior Developer's work such that you're worth your contracting day-rate for the interview (and are paranoid to think that the interview is a big scam to get you to work for free) ... you're probably delusional.

Thing is, as an employee, yes you should be able to deal with having to spend unexpected time on something. As a job candidate, the equation is a bit different. There is no commitment from the company or the candidate to each other, and the candidate may never get hired by the company in the first place. So why should the candidate give the company a day of work for free? And if a day of work for free is fine, why not 2 days, or a week? Clearly there is some point at which a job candidate should not be doing free work for a company.

It didn't sound like the company was looking for the interviewee to improve on the Senior Developer's work, it sounded like they wanted the interviewee to develop new features for deployment in a pair with the lead developer. Not the same thing IMO.

Maybe the company wasn't trying to concoct a grand scam, but there are certainly companies out there that would think nothing of doing so. And even if the whole 'write some deployable features' for us exercise was not devised as a scam, it doesn't change the fact that it is a bit unreasonable to ask a job candidate to spend a day writing code for you.

The guy even offered to write code for an open source project but the interviewer refused. What does that say about the company?

Attitude aside, its clear from the story that they wanted him to make features for their company for free, without paying him.

I know the start up way is to push for more, but if you are hiring a person to make sure they stay late and work unpaid time, you have a manpower problem, it isn't a problem with the individual.

The real problem is that companies far past the start up stage continue with this belief that it is the employees responsibility to work late for the companies mistakes, and yet when it comes to raise time try to fit you into a rigid and small benefits/pay increase. If there is supposed to be a give and take, where's the give?

my thoughts exactly. the overwhelming impression I got from the blog post was that the author was a self-important ass.

I disagree in part with your take on it - mostly with the idea that the hiring person expected to "spend the day" on the problem. I don't have a problem with working on open source or production code for 1-2 hours. But a whole day? If an employer asks you to work for free for a full day before hiring you, what does that tell you about how they value their employees' time? It tells me that they don't value it at all!

All programmers expect (or should expect) to have some demonstration somehow/somewhere. OP offered to demonstrate his skills but the hiring person was locked into their way of doing things (our code, our way, your time). The problem with this particular company is that they expected a whole day (or that's how he paints it at least).

> ... equally be unlikely to do anything outside of what he is technically being paid for.

"Technically" being paid for? There is absolutely no reason for anyone to do any commercial work unless being paid for. People are not slaves, they have their own lives and their own free time to do the stuff they want to do. To expect from anyone to work for free and complain when they refuse to is outrageous.

> I'm not saying anyone should work for free, but sometimes you have to help out, whether it's working a bit later or helping during a crunch time.

Yes, in fact that's exactly what you're saying--people should work for free. You're just calling it "helping out". The employee is not there to "help" you (do what? get rich?), they are there to do the job they're contractually being paid to do. If you need more work to be done, then arrange so. If you need free "helping out" feel free to call in your friends and family.

I share the same opinion. Appart from that, I'd love to have the opportunity to see and play with the actual codebase before signing up for a job. During my first days with a really friendly and somewhat generous company, I inherited a mind-blowing codebase (well I'm gonna call it "code", but I might as well call it absurd theatre). All the blubber that HR, product managers and team leaders feed you during interviews, gives you like 10% of the job description accuracy you would get from actually reading their code.

Anyway, I think attitude plays a really important role here. A candidate might be able to recite Linux Kernel code by heart, but if he doesn't show commitment or a bit of flexibility, I would never get him on my team. I'm not talking here about an 8 hour long test run. I bet the guy could have negotiated it to 4 hours or something. I gave away 8 hours of trial work once (+ 3 hours spent talking to managers during the other stages) and I never felt bad about it. I really don't get what the problem is here, I was always really eager to show what I can and to impress. It's all about being competitive. We're not pealing potatoes, we're writing code. Show some passion for Christ's sake. Or find a job that makes you happy even when you're not getting paid. That's the kind of job you'd like to keep for the rest of your life.

Say what you will about the guy's tone (impressions may vary), but I don't think the guy was being unreasonable about the heart of the matter.

> Secondly, the fact he refuses to pair program with a developer on the existing code base ' to see how he works within a team / on code - suggests that he probably would equally be unlikely to do anything outside of what he is technically being paid for.

I don't think that is the case at all, the guy offered to do some work on some open source code and the interviewer refused. It's not that he wasn't willing to pair program, he was unwilling to produce a day's worth of deployable code for free.

Programming is skilled labor, and doing skilled labor for free for a commercial interest devalues the profession. It's one thing for there to be occassional spikes in working hours, it's another thing to start out a relationship with the attitude of, 'You will do work that is valuable to me, but you will only get the chance of working for me in return'. That's what clueless people looking for programmers on Craigslist do.

Flip the situation around. Let's say the interviewee asked the company to provide a developer to spend a day developing an open source feature so he[the interviewee] could see the company's coding practices in action. What company would agree to that? Especially for multiple interviewees?

I had a similar thing happen to me when I was interviewing at companies right before graduating. One of the companies sounded like an awesome opportunity. They were willing to fly me out to San Francisco to interview me. However, the interview consisted of me doing 3 days of pair programming on their application.

After the initial shock of excitement I realized the cost to fly me out there was much cheaper than they could hire a dev for. I actually thought it was a pretty ingenious way for for a startup to get cheap work while raising money.

As some people have already suggested I think there are some good ways to avoid having to do this while still getting an idea for the candidate. You can offer to pay for their time, you can have them reimplement a feature you already have, or as the article suggests work on an open source project that one of the parties are familiar with.

The last place I interviewed with set the bar pretty high as far as I was concerned.

After a pretty standard interview one afternoon, I got asked if I'd be willing to come back in for a couple of days to see if I got on OK with their current team. They made it extremely clear that as they'd be taking up a couple of my days, they'd pay me pro-rata for them whether I got the job (and chose to take it) or not.

If you're interviewing with a company that actually cares about the happiness of their employees, then they tend to make this pretty obvious pretty quickly. I would suggest that the ones who make it obvious are the ones you want to be working for.

> LD (frustrated): "But I need these features out in the field today. Anyway, I don't see what the problem is, it's only a day's worth of work."

"This is meant to be to assess my competence. They're gambling your deadline on either being extremely sure that I am going to be good at this job, in which case they're trying to get a free day's work out of me. Or they're taking a worse gamble on someone they're not really sure of, in which case they have no respect for you and by extension their workers.

Either way, you shouldn't be using work that actually matters to test new entrants; in the former case it exploits me, in the latter case it abuses you. So, given it's clear I'm not a good cultural fit to this company, I'm going to have to decline."

When they say "I need these features out in the field today", my response would be: "shall we reschedule the interview then?"

Don't waste your time on an interview when you've got a tight deadline. Make some time for the interviewee.

I can see how he would be annoyed to do a day's work, however I would potentially have compromised on an hour or two. I have discussed , in detail, solutions to a company's technical issues as part of the interview process.

The interviewer may also have had no other way that they felt they could evaluate a candidate effectively.

However in defence of the OP, if somebody asked me to work with them for a full day I would also want paying for my time.

I have heard that large publishers, like Time magazine, will commission artists to create covers for multiple stories. They may have up to 5 tentative cover designs for any publication, then they are free to choose (right up until press time) which fully-designed cover they wish to run.

The thing is - they PAY for each cover they commission whether they use it or not.

----

My career began in graphic design. Many people try to get you to submit work and only the winner gets paid (or paid in full). I've had other 'take home assignments' or interview tests that they tell me to block off half a day so they can 'see my work' to 'tell if I'm a good fit'.

Don't be fooled by any of it - good work != good workers, and it's much more valuable that they see how you work on their team than how well you perform in skills that can be taught.

I quickly made a simple rule: I do the work; I get paid.

@Hiring managers: If you want to see a sample of my work, and my past portfolio isn't good enough for you - pay me for a small freelance project before offering me a contract. It's low-risk, everybody gets paid and is happy, and if you don't like what you see, don't give me more work. It's very simple. Anything less is criminal (where I live).

@Devs: Only have two prices: Pro, and Pro Bono. Nothing in-between.

Pro means there's no such thing as family discount, or friend discount, or a 'deal' on things. If the person knows you and wants you to be successful in life the last thing they'll ask you to do is work for less profit. See those selfish people for what they are. You should be happy to pay full price for anything, and it just makes it better if you're able to support somebody you know while paying full price.

Pro bono means it's $0.00. You should always have at least one project on your table that you are donating your time back to the community. Ever use Firefox or Chrome? Linux? OS X? Android? You already understand the benefits of pro bono work in the open-source software community, but as a worker maybe there are ways you can give back to the community you live in as well. Find people who need your skill set and make a habit of learning new things while helping others.

If you don't do any pro bono work, it's easy to get caught in the 'discount delusion' and you end up trying to give up all your profit instead. Do pro bono, and then insist on the full (fair) price for everything else.

This is one of those articles where I more or less agree with the author's content but absolutely detest the tone and style in which he makes his point.

He could have easily made the same point with far more calm and eloquence - why the anger and the tone that at least to me comes across as extremely arrogant?

I agree with the principle that you should charge a day rate for a day's work. However, I don't agree with the author in this case.

For the author, this is an unusually genuine opportunity to see what the work is actually going to be like.

If the author feels that compensation for this time is necessary, they ought to confirm the salary would be at a level to cover the time-cost and risk of interviewing.

Asking for money up-front is (unfortunately) sending a signal that you need to be compensated early because you expect not to be employed as a result of your work.

I've noticed a trend as of late with developer blogs. It seems that a bull market for developers has made a bunch of prima donnas of some of these folks. The point made is valid(dont work for free, and the interview process is broken), but seems he also felt the need to include all of the essential holier than thou blog techniques to make this point: - a "mock" conversation that leaves the person in charge flummoxed - use of the word "hipster" using this word is now kind of self parodying... - inferences that he shares the love by contributing to open source - use of the f word to drive the point home.

So I came away thinking this guy was a dick and probably difficult to work with, I wouldnt hire this guy even if he was the best developer Ive ever met.

That said, yes- the interview process is broken, there needs to be a better way to assess developers in the real world and not resort to trivia and "working for free". I think its been proposed here pretty often that a small short term contract is probably about the best way to be fair to both parties. The developer gets to show off what he/she is capable of, and doesn't have to give away IP for free. The company is protected by not having to make a judgement call based on how he/she answers programming trivia. The team gets to see how this person works and thinks about problems, especially if it is an in person interview.

Umm, I WISH all of my past employers let me peak at their codebase, experience their development process, and pair with an employee before asked to accept an offer.

FWIW, I did a free "starter project" for my current position and it was completely awesome. Worked with many teams, learned a few codebases, learned the metrics/logging systems, and learned the true size and formation of the production environment. A+++, would interview again.

A full day is unreasonable for an interview. But "working for free" for a while isn't. Of course they want to see you working on that particular codebase rather than some other code. And even more obviously you want to jump on the opportunity to see the code. An hour or two of pairing is completely reasonable.

That said: shipping code written by a person being interviewed is nonsense. Either the person was assigned completely menial tasks which doesn't evaluate their skill at all, or the manager is a complete nutjob that wants to ship features written by someone who has never seen the code before.

If the employer can't provide a person to pair with, and says you should spend an entire day coding features to go live immediately, it would actually seem like the employer believes interviews can be used as free labour. That idea is so stupid it is hopefully rare enough that it doesn't even deserve blogging/discussing. There are tons of useless interview procedures that actually deserve discussing.

Personally, i'd be okay pair programming on a base. But there's no way I'd do it for a WHOLE DAY. If i'm unemployed... maybe, but if i'm just looking for something different. I'd never have the time to spend a day at an interview. These guys aren't sharing the risk evenly here. There are 3 scenarios. We both like each other, i get hired. I don't like them or they don't like me and I don't get hired. 2 out of the 3 scenarios end in a no hire. They may loose a small amount of productivity, but I loose a day.

Personally, if it is a job I'm really interested in I would prefer to show my chops offering some free consultancy on an interesting problem, rather than answer daft hypothetical questions for an hour and a half.

But no, I wouldn't do it for a whole day.

Imagine you apply for Google or Facebook, you know, a dream job undergraduates want to be in and they said "dude you can hack on this little ticket with me today and I will show you the codebase." I am sure in this case majority would say "fuck yeah let me see how good your codebase is."

Like many have said. One way to find out whether you like to work or not is whether the code looks interesting, how your co-workers work with you and what type of problems they are solving.

One missing aspect in the discussion is its pair programming not here's a task see you again in eight hours.

I'd grill the heck out of my pair partner. Interviews go both ways and I hope I'd be paired with a real live employee not future supvr. I would probably learn more about company culture from that guy in 5 minutes than I could from management in multiple hours of regular interview. Its worth it to me.

I'd also look at it like an intrusion, uh, experiment. How much can I learn about this place in a day. Not being sneaky about it at all. You're going to be exploring the dark corners of the environment once/if you're on the job as a regular employee, so start shining a flashlight in there today. Yeah yeah they said we'd implement feature XYZ and we are doing that but it doesn't mean I don't read the surrounding code and verbally grill mr pair partner about his firewall or DB or caching system or whatever semi-related stuff I can talk about. Thats interesting. I'll trade labor for "interesting" anytime.

Its a pair event. Maybe I'm just old but I'm assuming I'd pull off a partnership where I talk about architecture and the pair, if he approves, does the grunt work (and maybe he intentionally sticks errors in to see if I can grunt as well as he can). Yes I know thats not exactly traditional pair programming but then again this isn't pair programming, its an interview of both sides. On the other hand, if their idea of pair programming is some dude micromanages me while I do all the work, I agree with the original author, F that. We just don't have enough detail.

It kind of sounds like if I ran into this dude at a bar or a con and we started talking shop about life in the biz, we'd have a fun old time talking and then he'd surprise me by sending me a bill later.

If I show up for a short interview at 9am and they demand me sit around till 5pm they better be feeding and hydrating me, and not cheap mcdonalds either. This actually happened to me once, and everyone left happy and well fed and that's exactly how it should be. Maybe I'm a cheap date but I'll "work" for a day for a $200 steakhouse lunch. Not every day, duh, but...

Finally "if we decide to hire you, your salary starts today" sounds like a fair deal to me.

I don't mean to knock on the pair programming model. It works amazingly for some people, there are cults around it disguised as consultancies and I even had fun with a few pair programming exercises. But... does your company actually pair program? If not, how do you know that you are not testing pair programming skills rather than testing whether the person can work on your stuff?

For example, when I write code, I write it in iterative drafts. I find that my train of thought breaks when someone points out a trivial piece of syntactically wrong code that I put in there as a filler for stuff that I am going to work on once I have finished iteration 1. I think of it more like solving a math problem where I sketch a picture and then gradually turn it into a sigma/lambda type proof. It is incredibly distracting if someone stops you in the middle of the picture and asks you how this has any connection to the final product.

During my recent search for a programming job, two companies gave me tests to assess my technical skills.

The first company's test was similar to that which the OP describes. A manager gave me a list of company contacts and asked me to build an interface for sifting through it. It was a boring, tedious task that benefited the company, but wasn't particularly representative of my skills or knowledge.

Contrast that with the second firm, which gave me a coding challenge. They gave me a list of prompts, including interesting ones such as "Build your own A.I. algorithm that can interpret poker hands."

Not only was the second test more interesting and indicative of my skills, it made me respect the company a lot more. I ended up accepting a job with the second company because their creative interviewing approach made me more excited about their offer.

A company I recently interviewed for handled assessing my technical skills in a way I found acceptable without having to pay me. I was sent a small Requirements document to program a small app that had nothing to do with their application, but would show off my technical chops. I was told to use whatever language and framework I wanted, but it had to be production ready code. I spent a little over half a day working on it and submitted it. During the on site interview I was given an hour to update the application with new requirements, then I went through a Peer Review as if the code was going out to the customer.

I thought this was completely fair, as I wasn't doing work for them but they were able to receive a fair assessment of my skills through more than, "Write a recursive function to calculate the factorial of a number"

Having an interviewee code on a live code base, whether or not they are being paid, is just a bad idea. They don't know anything about the code or architecture of the project, and aren't as invested in the product as the people actually working for the company are. What happens if the person writes some bad code that works? Do you throw it out? Will it slip through the cracks? What if they change something that was already coded that they don't know breaks something else? Do you not allow them access to the rest of the code base? The questions go on and on, just save yourself the trouble and don't do it. The fake application idea works great

Anything more than an hour or two should be paid for. That's been my experience interviewing across London and SF.

Completely agree with the author, being asked to create potentially production-izable work is ethically wrong.

On the flip side, you learn a ton about how the engineering culture by looking at their codebase.

I wonder how the copyright situation would be if you were to write code during your interview that they continue to use. That's before any sort of contract that details what rights the company has to your work (since they cannot take your copyright they usually reserve all other ways of using it). So technically that's still your work and you have full rights to it.

IANAL

You're right you'd own full rights to your work. That doesn't make a difference though - you'd realistically never sue them.

I completely agree with the blog post writer. I have a job, and if I was to work on some other companies code base while still working for the current one, all kinds of copyright issues ensue (Swiss).

Having someone, who is not an employee mess around in your codebase before they are hired is a lawsuit waiting to happen. Not worth it, and if you could convince me to come into your office for an interview and this is what awaits me I am leaving in no time.

What happens if you don't hire the guy and sell a 100,000 copies with his work product in there? Do you own the copyrights or have a license to it? Probably not, and if it was me coding then my lawyer would have a field day with you and your company.

So besides the insanity of not hiring a developer like you hire anyone else by references, reputation and limited work sample tests. Do you think you can tell some lawyer, please work on this case for 8 hours and then I will tell you if you get hired is going to go along with this? He will bill you 4000 chf for the pleasure and so would I.

In Europe you have probation periods, i.e. you hire someone and find out that they can't do the work you terminate them on the spot. Is that expensive, relatively yes. But if that happens you already screwed up weeks earlier and it is time to pay the piper.

This entire consult to hire, or whole day interviews just seems unacceptably unproductive and ethically as well as legally questionable.

I understand the reluctance to work on the production code for an entire day. But like others have commented, I would rather do that and get a chance to see their end-to-end process rather than coming in on the first day and finding their dev environment is a complete mess.

I've come in as the new guy on a project and been greeted with a zip file of the code base (already out of date). It was complete with hard links to the main developers personal test database running on his machine.

I do not fully understand some of the negative comments from HN in that case.

If the same story had happened to a graphic designer then most would agree,as usual in that case, that you have to set limits and not work for free "just to see what you can do".

Well, it actually is different comparing a freelance graphic designer to a fulltime developer.

> If the same story had happened to a graphic designer then most would agree,as usual in that case, that you have to set limits and not work for free "just to see what you can do".

On the flip side, literally every interesting answer that you give folks in an interview process could potentially be considered to be free work. I used to work on recommendation systems. Say, I go interview at another company in the same space, literally any potential what-if machine learning problem can eventually get into the situation where it goes off text book fairly quickly. At that point, any information that I talk about has two values: 1) it helps the people understand that I can do this shit. 2) it also helps them maybe solve the problem based on my experiences from my previous job. In the case of 2), they are essentially getting free work. How do you resolve such a situation? Should we have an industry wide standard where people pay you a market rate for every hour you interview?

http://dilbert.com/strips/comic/2010-04-02/

Isn't that what a portfolio is for?

After reading on that page and coming back, I felt a bit blind.

But I agree with the post. Very well written.

1. I will hack on my codebase for an interview. Look at my github account and choose say three issues. I will fix one and you can see the pull request.

2. Otherwise, fuck you, hire me. I am available on a day rate for heavens sake. You can throw me a project that will tart up your site, improve your jenkins flow, add 100 test cases. Whatever.

This is a massively scalable approach, an the way you should be parcelling out work most of the time.

That's fine. We'll try to evaluate your abilities in some other way, with the initial impression that you're a prick. :-/

A day is a pretty unreasonable request. Maybe an hour would be more reasonable?

It seems everyone has their own opinion on what a tech interview should look like on both sides of the barricades. I think it would be great for companies to advertise the interview process in the job ad. Just three lines on the various steps in the process would help a lot.

FWIW, I really like it when I can hack or even see their codebase upfront.

A whole day is a little excessive but other wise that's exactly what an interview should be. I'd like nothing better than to see the actual code I'd be working with and see how I work together with others on the team.

In fact I once passed on a job offer because they wouldn't let me see the code until I accepted.

I don't see what the problem is: it's clearly not work for hire, and he doesn't mention any explicit copyright assignment. At the end of the day the candidate retains copyright, and the company has no right to the changes.

(Of course, the idea of a day-long technical interview exercise is truly insane.)

The code was going out at the end of the day. Whether they had the copyright or not, they clearly intended to use it. What's he going to do; take them to court over it?

I would, and if it wasn't me my current employer might...

The developer does came across as a prick. The thing is, does the company allow anybody to access the code? Probably not, because that code is very likely proprietary company information that only certain people are allow to view and modify.

So from that standpoint, validating the skill set using opensource tools would be the way to go. Having an outsider view and modify internal company code demonstrates poor judgement on the part of the interview, as that code is not her/his to just expose to anybody. I would be wary of even considering that role if interviewer is willing to expose their code without considering the legal and ethical consequences of that action.

Do you really need to take up an entire day of somebody's time just to see how they code? Is there something that you can see in eight hours of coding with someone that you can't see in one or two hours?

Also, if you're going to require full-day interviews from your job candidates, it's not likely that someone who already has a job that they like will be interested in interviewing with your company. And if you're looking for highly qualified, experienced developers, they do already have jobs that your company is trying to lure them away from. You don't want to artificially limit your candidate pool to students and the unemployed.

Hint: A really good way to hire is to actually pay candidates as short term consultants and see how they do. It's real work, on your real product, likely for less than you'd spend to "interview" anyway.

I hope the guy who wrote this is 15.

http://hownottohireadeveloper.blogspot.co.uk/2013/10/no-im-g...

Well, I've made a interview at a company that asked for pair programming in their codebase, but actually paid for it. Since it was just 2 hours, it was cheap for them, and I didn't felt exploited. I felt it was a great way to get to know the company and discuss real code. I really don't like algorithmic interviews, they normally just test you CS 101 memory under pressure.

I get his point, but this is the wrong way to express it.

For high-pay, high-impact jobs, 8 hours of time to get through the hiring process is not unreasonable. My current job had a few hours of interviews even after they had narrowed the candidate pool down to just myself, to be sure I was a fit for the company culture. VP/C-level positions in large companies will put you through the ringer with multiple days worth of discussions.

I would gladly pair program for a day vs. 20 hours of interviews, tests, and other evaluations. One day, get it all done, and get a decision. Sounds great, especially if I had already set my day aside for the interview.

So my guess is that aside from the obvious attitude problems, this guy has never held a truly senior level position, because he clearly does not understand the time that goes into hiring. I highly doubt this company had 50 people pair program with them. This guy was probably their final candidate, and probably would have had a job offer by the end of the day if he had chosen to be cooperative.

> we've got some features I want to implement and push live by the end of the day

This is not an interview.

The interviewer is focused on his "regular" job, not the candidate. Plus, the candidate can't possibly become fluent enough in the company's app/API/codebase to actually accomplish the task in a day.

Interfail.

On the one hand, TFA is obviously put off by both the tech stack and the hiring procedure. This suggests to me the possibility of a poor cultural fit, so the outcome is probably for the best.

On the other hand, it is reasonable to have a backup plan for situations where someone is adament about not working on your proprietary code for free. Any legal issues aside, as someone familiar with the existing code base, a lead should be able to conceive of a contrived scenario that closely maps to work that will be done on a day to day basis.

While I am personally an advocate for contributing to open source projects as part of a company's cultural, that is not something that all companies are okay with, or that all leads see as valuable. Without judging one way or another, this is another factor that should be considered for cultural fit.

well, at least they didn't give you puzzles

As flawed as the interviews are, whatever you do that makes you filter out a person with an attitude of this type, it is probably working.

If they are really hiring, the interviewee should do it. If he can't sense whether they are really hiring, he shouldn't do it. But it should be preceded by something else first, such as fizzbuzz.

And that said, it should be shorter than a day, but still, if they're hiring he's there because he wants the position, and this is an excellent test.

Pair programming on a company's app is the single easiest way to know what you are getting yourself into.

I recently did a full day of this and by the end I understood their whole stack, where the system failed, and managed to find a, "oh shit look at that... that's awful" part of the code.

I would take 4 hours in a potential employer's codebase in a heartbeat.

Why they can't foresee this instead making work for free? I mean, you get a technical team who can interview the possible guy, talking code, you can know what's the guys skill level, if you cannot see how good he is in interview without making him do puzzles, work for free, then your team's technical skill is really low.

IANAL, but any code written by the interviewee is likely not owned by the company, thus exposing the company to serious liability if said code is used in production.

Most employment contracts have a "work for hire" clause with respect to copyright assignment. In contrast, most interviewees at most sign an NDA.

We do like real-world assessment when hiring. We always pay the candidate's contract rate for the hours spent though, and if they don't want to enter that arrangement, we find some open source or other real-world coding exercise that doesn't benefit us. Seems only fair.

I think day-long interviews are fine, and I think real-world work samples are fine, but the combination is pushing it a bit as far as what is fair to ask job applicants to do, unless you're going to have some sort of explicit and upfront agreement about a trial period.

I'm kind of curious, before doing a live coding session or anything like that has anyone used a snippet of code from the codebase and asked the candidate to go through the code and see if the candidate understands it / feels comfortable with their coding style?

This is definitely wrong - legally and morally. I have had companies show me snippets of their code base to analyze and work on which is fine. Gives me a better feel about how competent to development team is rather than isolated puzzles and questions.

I would love to see your codebase while interviewing. There's no faster way of seeing if you're a competent bunch to work with. Also no faster way of detecting interpersonal and "soft" dysfunctions in your group.

The cost of having a team member hand-hold a new person through the code is almost certainly greater than any value the newcomer would add in a day, so if the OP's argument had any merit, he should have been the one paying them.

Good lord, does nobody plan before they start hacking away? If someone wanted to watch me write software, they would see a bunch of scribbling on a notepad or whiteboard for most of the time.

I agree here, but I wonder if it'd be kosher to pair program on an open-source project...that my team totally intends to incorporate into our closed-source product?

Perhaps the interviewer could work on the job you had to take PTO just to go to the interview. Then you can assess his skills and just say you were WFH. Fair trade?

Just a weird question that occurred to me in the first few paragraphs...

Why is it always a ping-pong table?

I don't get it. Pool tables are way more fun.

Silly question: If I hack your code during an interview, don't I own the changes, and derivatives thereof?

Too bad! Interviewees are not guinea pigs! High time that interviewers realize this.

Another article being penalized. On the third page now. I love you, HN algorithm :)

So you won't see the code until hired? Not very smart, I'm afraid.

you charge $56/hr in a daily rate? O_o

High or low?

low... a good rough base for freelancing should be triple whatever the salaried hourly rate equivalent would be (i.e. $80k/year => $40/hr, so you should be charging $120).

I do give a break if I'm charging in bulk (i.e. I have a really long term ongoing project with you and we negotiate a different rate).

At end of day: svn revert -r

this blog post is bad and the author should feel bad.

Pretty common!

Just a few comments I left on this blog post, maybe someone here will also find interesting or useful:

I'm sorry, but I must respectfully disagree on a number of points. I think you make a number of flawed assumptions and miss some great opportunities when you pass up an interview that allows you to work in their code base.

1) Maybe this company was different, but as for me if I bring in an interviewee and say "Let's pair on some code for a day, and try to release a feature" I know up front this will be an up hill battle. Can you really say that you, an interviewee who has never seen the code base, will suddenly make amazing production grade code? I am absolutely sure that if I were to grab one of my other engineers, seasoned in my code base, I would get this task done in half the time. The point is, I am assessing you to see how you work with me, what your attitude is while we pair, what your contribution to the process is, and to a lesser extent how your code looks. Can I get this out of an open source project enhancement, maybe. But I can certainly get this out of my code base and it will cost me more than it will cost you in income.

2) You've missed the opportunity to look at my code base for a day. I can't name the number of times where I have walked into a company after a lovely interview experience and said to myself "I wish I had seen their code base, this is horrible". Your other blog post states you want to "test the company" before you take a job. Test them.

3) I won't discuss how low your day rate is, and how it establishes that you are an inexpensive engineer (that may have been what you were trying to get across) but I will discuss investment in future earnings. In my last few jobs I have received at least a 5 figure signing bonus, and generally a healthy pay raise (this is generally why I move companies). When I sit down to pair for an interview "for free" I don't think of it that way. I think of this as an investment into my future earnings. I am going to get a signing bonus from this "trendy startup, complete with ping pong table". I am going to get a healthy pay raise. It will equal far more than my day rate. You might say "But what if you have to do 5 or 10 of these interviews with companies before you get a job?" I often do! Getting a job is a numbers game. But I am still highly compensated for my time, just not right that moment. It is ok to defer payment. Investments can be quite rewarding. (Not to mention, money isn't everything. There are other reasons you may want to leave to another company. Account for that in your equation). If I interview with 10 companies and they all have me working on their code base, I hope they enjoy the one day of free work. I won't get paid by all of them. But I will not lose a dime of my own income in the end. I will make it back when one of those 10 companies hires me.

I understand from this blog that you would rather not be tested and that you would rather not work on a companies code base. But a company that wants to hire you, wants to hand you a pile of cash and a hefty salary and benefits, needs to assess you somehow. You also need to assess them. I think a day of pairing on their code base can easily tell you if you are a fit for them and they are a fit for you. In the case of this interview, maybe they very quickly figured out you are not for them.

not hired!

Firstly, I think they wanted to 'assess' not 'asses', well at least I hope so (spell checking is not optional; even on a blog).

Now, I agree with the blog post: if you want me to code at interview it has to be open source, pseudocode or a toy library. Not your production app. I don't want to see you proprietary code till I am hired in case some moron on your staff later goes on a spree suing people on an open source project where the code looks 'similar' to what they may have seen in your code-for-free cheapskate interview process.

Personally, I'd pay money to see the real code before considering a job offer... :-)

On the other hand, the pingpong table is probably enough hint.

I have to disagree there. A workplace that emphasis on fun at work does not imply bad code quality, nor does it imply good code either. Not sure what the fuss is about ping pong.

Does work performed in an interview constitute work for hire? I wonder what the copyright implications are in the US.

Reply on news.ycombinator.com