Ask HN: How is it fair that companies ask candidates to spend hours on a task?

I'd counter-offer with a wage appropriate for the hour for those "jobs".

To give you a bit of perspective: in other industries, it's quite common that Assessment Center sessions last around 6-8 hours (however, there are breaks and lunch included) and it's not uncommon to see even 2-day assessments.

Is it fair? I'd say yes, if following 2 conditions are met: 1. The method (AC/task/exercise) is well designed to actually test the candidate's skills and his/her performance is properly observed, measured, analyzed and assessed. It's fair for the candidate, because the hiring decision is adequate. 2. After all this effort the candidate receives both a "thank you" and short feedback about his/her performance.

Unfortunately these conditions aren't met quite often and that's not fair.

If you've gotten to know the company somewhat (several interviews that went well), give them a counteroffer:

"I know how important it is to test my skills before hiring me, so I'd like to propose an even more in-depth assessment: I'll work for you as a contractor for two weeks. If your team likes my work, you can hire me as an employee."

I don't know if it would work, but if you really can't spare the time to do assessments, it's worth a shot.

I'd suggest that fairness is irrelevant. Businesses will demand as much as they can. If great candidates stop applying to them because of their ridiculous demands, they will either have to reduce their demands or hire only mediocre candidates. If great candidates keep applying, they will continue to be jerks.

This is simply a result of the way economics works. Voting with your feet is the best way to stop it.

The best companies use short assessments to make sure that the long one will likely be successful.

As a candidate, I tend to ask that one of two conditions be met for these kind of projects:

Either:

1. It's open-source and I can show it/share it as I see fit in the future

or

2. They pay me for my time.

I prefer #1 actually, and most companies will be okay with the open-source thing, but will usually ask that you not share it publicly (on a github or anything), so that other candidates can't find it. I like this option because it gives me ammo the next time I'm asked to do a coding challenge ("Okay sure I'll do it, but did I mention I'm already in talks with a few other companies and have already finished their coding challenges? Here take a look! If these don't show you what you need to know, I'll take your test too."

Guess that will save time later if the candidate doesnt fit the role.

Instead keep a open project expectation, expected time to complete and get that agreed.

I've been on both sides of this and if the task takes any more than 2 hours. I offer an hourly rate that is reasonable and a well defined mini project that would showcase the skills required for the job. This way no matter the outcome hired or not the person does not feel unfairly treated and is always offered feedback. I also ask them what type of work they love to do and note that for a future project/hire that I may need in the future.

I strongly agree. I view it as highly disrespectful, especially since I have more than enough open source work out on GitHub.

I also do not wish to burden candidates with that when I interview them. I believe I am a good judge of character, and also a good judge of ability, so I haven't felt the need to offer a project after a phone screen or in-person. I do not even plan out the questions I ask except for having a loose set of criteria I look for when I interview a candidate. It is much easier if the conversation is fluid, as if between peers. That does not mean I won't ask difficult questions - sometimes I do, but I ask them depending on how the conversation goes and what the developer comes off as to me. My questions are meant to gauge the candidate's skill level, and whether there is a good fit for the company and candidate. I don't need to give the a super hard brainteaser - that only serves to filter for the exceptional, and isn't an efficient use of time. I don't need to give FizzBuzz - if I am that suspicious of a candidate, I will cut the interview short, since within the first 5-10 minutes, I already have a general hypothesis formed that I am testing for.

I like to open up interviews with asking about the candidate to explain his/her background. I will have read the resume beforehand, or read it while the person is giving the overview, to see if the person misrepresented anything on the resume or about his/her background. I ask about details about some recent experiences, and if it is the technology that my company uses, I ask for the candidate's views on the technology, including positives and negatives. I shift over to questions about beliefs on how the candidate approaches certain situations, or shift to the technical questions. I don't require exactness in answers, but if a candidate has an exact correct answer, it's a good sign. Similarly if I ask a trickier question and the candidate figures out how to answer it optimally quickly, it's a huge positive - you can't fake that sort of cognitive reaction.

Lastly, I save some time for the candidate to ask questions - even this is a part of my evaluation process, because more senior candidates know what type of questions to ask based on what they have seen in the industry.

For me, this has been enough for me to evaluate a candidate properly. Anything like a project is excessive and unnecessary.