Sigh - yet another hiring process complaint post. As an employer hopefully I can shed some light here.
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.
I was talking about 25 onsite conversations leading to 10 offers and maybe 3-5 acceptances. In order to have 25 onsite conversations companies likely have to talk to 125-150+ total individuals via phone/email/networking events. That's at the low end once all the processes are dialed in.
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).
Remember, as an employer, you are getting more out of the employee than they are getting out of you. Otherwise you don't make a profit. I understand why you want to do it as quickly and cheaply as possible. But seriously, fuck you. How about a better answer. Unless the person just came out of school, don't treat then as though they just came out of school.
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!
Please rework this explanation so that the points you are (trying) to make are emphasised rather than obfuscated. Then get back to me and I'll consider whether working with you is an option for me.
Fair enough, and sorry for my snarky response. I know you weren't trying to get to work with me, but I felt the need to let you know that you needed to present your message properly. The audience here are programmers, often very good programmers, people who take pride in organizing their thoughts and their programs with optimum logic and efficiently. Your message looked as if it might be interesting, but it was ruined by the formatting (yes, that was the problem).
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.