Hacker News new | ask | show | jobs
by swang 3519 days ago
i don't think pure cvs are the answer. i don't think a take-home is either. especially since a lot of companies expect you to put a lot of sweat into these take-homes.

if your take-home is a "half-day" which means... 12 hours? half a work-day? what? that does not sound appealing to me. unless you are actually building something unique, offering more stock, or more money, or a better work environment i am not sure how you can explain it's worth it to someone to go through your process and essentially wasting an afternoon to a week of their life doing the take-home. _especially_ when most companies will reject you for a lot of silly reasons.

in a perfect world your scenario would be "fine" and all your points your company may actually do. but across the swath of companies there is no guarantee of this.

for example you cite #4 as an point for doing take-homes, except i seriously doubt many companies mask/hide who the person coding it is. they usually just hand it to one of their engineers and go, "evaluate this" and now you're at the mercy of what kind of engineering person he/she is and whether they're currently too busy to give you a fair shake or any other myriad reasons.

you can barely get companies in silicon valley to admit there is bias let alone set up some blindness against it. unless they were able to submit the initial job application anonymously, how do you know your process isn't bias at that point from your HR person? maybe you do account for that, but how many companies realistically do that?

and again without knowing your company or your process, _every_ company with a take home says, "take your time", "we're not in a rush" etc but never actually tell you that they want just <X> and if you do <X> that's enough. people literally have no idea how you're going to judge their take home. maybe the question is unclear, maybe your view of a "good enough" ui to them is a ui that takes longer than the time you've alloted them. maybe you don't like it when they write their javascript without semi-colons but you don't bother to tell either the interviewee or the grader any of that. then there is also the problem that even with "correct" code a lot of engineers who review take-home tests just _love_ to nitpick to disqualify possible candidates. and if you _do_ have a process in place to guard against that, you would literally be the first company i've heard who goes that far in their interviews.

i don't doubt the way you're handling it is getting the results you want and is the best way to hire. but i doubt that's how other companies are handling it. now you expect people looking for jobs to be able to discern between you and the other group? you want me to apply and assume good faith that your process will only take half a day and is "fair"?

edit: i tried editing this to make it not sound very antagonistic, but it is late here in sf so it may come off like that so sorry if it does. i don't disagree that take-homes work for you. i just don't think most companies in the bay area have thought it out very much other than, "use take-home test in interviews"

1 comments

half-day means four hours. I'm being generous there, because a skilled developer can create a good solution in 2 hours, but many find they want to put around 4 hours in.

In terms of what you have to do for the take home to be a success, we explain that fairly clearly these days. I'm now on the 6th version of it because I ask for feedback from the people who do it and try to improve the wording and make it more clear over time. I also provide contact details for people with questions.

It's also a fact though that simply achieving the task is not enough if the code you used to do it is sufficiently poorly factored or overcomplicated to a ridiculous extent. We don't mark people down based on superficial coding style. Fails get marked by more than one person, the marking team is small and regularly talks about the individual tests they are marking, but there'll definitely be situations where working code gets marked as fail.

The person marking the take home does so before they get access to the CV. They do usually know the name, we'd need a more complicated process to redact names from submissions, but it might be worth doing.

I am sure there are ways we can improve our process, and I am aware that there will be lots of companies out there with a process even worse than ours, but I wanted to talk about it, partly as a way of getting feedback with the aim of improving it more, and partly because I hope that others can learn from what we've done.

I have been pretty happy about the team we've built with this process compared to teams that I've been involved with building in the past, so there are definitely good parts to it. The two big concerns I have with it are 1. are we being equitable with peoples time and 2. can we reduce the number of skilled candidates who refuse to do it on principle.