3 ms·
I'll leave out the details of the two I've done since it's a sore spot on my psyche but I'll talk about them in general. Maybe yours is different, but I think
by Zimahl 13y ago
I'll leave out the details of the two I've done since it's a sore spot on my psyche but I'll talk about them in general.
Maybe yours is different, but I think the first problem is they typically have a lack of clearly defined goals. I know that probably is the idea behind these - to see what someone comes up with - but it can be very intimidating. Especially given the fact that the interviewee is already nervous enough and now they are given something ambiguous. I think that's more nerve-wracking than the interview itself.
Second, I think that code-style tends to get graded on these more than the content. Unless it's completed in some really novel way (which isn't always a positive) there's nothing to do but nit-pick how the code looks.
Third, its disrespectful of the interviewees time, especially relatively large coding assignments. If a candidate has a job, is it fair to expect them to go home and spend a couple hours working on something that is essentially worthless?
Finally, typically the candidate gets no feedback. I had one that was a 'pass' and I never found out why. You are essentially grading me on an assignment and then don't have the decency to tell me what was wrong? This is related to the previous item as a time-waster.
So, those are my reasons. Just my two cents.
- tptacek 13y agoI don't want to let myself off the hook too easily here, because we don't hire for typical developer roles; our work-sample tests are very well defined (they're exercises in finding and exploiting vulnerabilities) but I'm generally interested in the technique overall. So let's stipulate I'm a hiring for a standard dev role. I think you make some great points. (1) Yes, ambiguity is death. It's bad for the reason you say it is (it psyches you out, and discovering how people perform when they're at their most psyched-out is a pointless exercise). But it's also bad because open-ended tests are hard to grade and compare. Work-sample tests need to be standardized and they need to be defined rigorously enough that you can draw comparisons between candidates, and then draw comparisons between the performance of hires and the tests. (2) Yes, grading superficial issues is also bad, for the same reason: when you give someone "points for style" (or demerits), you lose the ability to make apples-apples comparisons with candidates over time. (3) I flat out disagree that take-home work is disrespectful of candidates. Most interview processes demand that employees submit to several (3+) hour+ long phone screens, then show up at an office for 1-2 days of interviewing. Allowing candidates to do the most important technical portion of the interview on their own time, on their own schedule, in their own location is simply better for the candidate than forcing them into a room with a whiteboard. (4) Yes, not giving feedback to candidates is one of the great sins of tech hiring. Some of this is folkloric; for instance, there's a belief that providing feedback to candidates you opt not to hire sets you up for frivolous complaints down the road. But there are ways around that problem.
- Zimahl 13y agoI see your arguments for #1, #2, and #4. Fair enough responses. As for #3, if you aren't a fairly exclusive 'brand' (like Google, Amazon, maybe Facebook) and you are known for having a long interview process, I think a fair number of applicants won't even bother. I've been asked by Amazon to interview a few times and their process just seems like a big pain for not much gain. Unless I was right out of college I just wouldn't find it worth the effort. So if a recruiter tells me an interview process is extensive and way too involved for the market, I'll just pass. When jobs are plentiful a candidate can afford to be picky. EDIT: sentence clarity.