|
|
|
|
|
by saumil07
4586 days ago
|
|
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. |
|
Standard processes are important, but they need to respect everyone's time.