Standard processes are important, but they need to respect everyone's time.
I agree that companies have to be respectful of candidates' time. People do talk to their friends before they engage with companies or accept offers and word can get around fast if companies mistreat candidates (as it should).
1. You're dead wrong if you think employers are always getting more out of the employee. It's a mutually beneficial relationship and a free, highly competitive market in SF. If poorly treated, candidates bail and current team members do too.
2. We aren't talking about profits at all. This confuses and conflates eventual profits with employee salaries.
3. Nothing that I said indicates that we treat them like they came out of school. If you have a better alternative, I am all ears.
4. We don't want to do it quickly and cheaply. We want to do it as best as possible under our constraints. We're a small startup.
Good luck to you as well and thanks for flipping the bird. So mature!
I wasn't trying to get you to work with me but thanks anyways!
a) If you are trying to hire 5 engineers, say, you need to talk to ~25 candidates at least. It's a competitive market. b) If you aim to talk to 25 candidates in a short period of time, you need to have SOME standard way to evaluate candidates if you don't want to just throw darts on the board. Being sloppy with process is bad for companies and the engineers and a waste of everyone's time. c) In order to create a standard process, you have a very limited # of options to work from. I've seen comments like "do a co-working day to get a real sense" or "do a contract and see them work with you daily" positioned as realistic options. They are not. If an engineer has an existing full-time job they don't have the time to do co-working days or contracts. d) The other options are 1) whiteboard interviews 2) coding challenges 3) some combination thereof. e) Lots of candidates hate whiteboard interviews. Lots of candidates hate coding challenges too. Neither is a perfect system but it's better than doing nothing or asking for co-working time. f) We use coding challenges at the top end but we time-box it to 3 hours. If someone asked us to pay for the time, we would happily do so. g) Our coding challenges have 3 different problems so candidates can pick whichever aligns best to skills. One problem is JavaScript-heavy and 2 others are Ruby/Rails-heavy. h) Several engineers on the team solved the coding challenges on a timed basis before we put them out to candidates. Doing otherwise would be stupid/unfair. i) In the few cases where we've been able to do 1-2 co-working days, we have offered to pay for the candidate's time. Not full freight consulting dollars but something that indicates our seriousness. j) In this case, the OP got caught by a dumb coding challenge to build a full website. But the headline paints with a broad brush because coding challenges by themselves are not evil. They are a tool that can be used well or poorly. That's all.