[gorpomon]

I've been there too, I've definitely had bad experiences with coding assignments. I try hard to not treat others as I have been in the past.

I run a respectful process. I offer people ample time. I tell them that asking for more time is a-ok. I answer questions.

But at the end of the day, some people just really knock it out of the park (maybe around 30%?), and I don't think it's unfair to reward that.

[Tronno]

You consciously misrepresent how much time is required to do well.

You could run a fair competition by stating clear requirements. Instead, you reward those who are most willing to burn through extra personal time.

That is not respect.

[gorpomon]

I think I've nailed the source of this disconnect. I don't say it's a 4 hour assignment and then get mad when people don't spend longer, or filter our anyone who does well in the four hours. I go solely by the code I'm given. It's just that around 30% or applicants or so clearly spend longer because the assignment is so well done. That is all. I'm guessing this end result would happen with any amount of time I specify, be it 6, 9 or 20 hours.

Some people just really put effort in, and as I said in my top comment others don't. Often those others don't for valid reasons-- they have an offer on the table, they want another job more, etc. As I've said in other comments, I have no way of knowing who has put in more time (aside from Git history which isn't a clear picture, but indicative), nor would I create a malicious metric. Also, I clearly stated that I viewed this as a con of our hiring process. I'd love a clearer way to even out the time, but barring bringing in some more stressful process like some timed app or timed challenge, I don't think I can.

Say what you want, but rewarding folks who spent more time isn't disrespectful to other people who didn't. No job is a first come first serve scenario, you're both assessing each other on a variety of things, and it would be unfair of me to disregard people who excel out of fairness to those who don't.