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

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

In the end I couldn't be bothered filling it in.

I would say there was a 50/50% chance I would have done it successfully. Sure I could study up and practice to make sure I passed, but I have been developer for 12 years. I don't need to fart about with algorithm trivia when the stuff I build is at a higher level for a different market.

I'll spend that time on my side project. At least I can use that again when the next company asks to see an example of my work.

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.