4 ms·
Ugh, the take-home test/coding assignment. I've done two of these and I will never do another. Bottom line, if a company can't be bothered to respect that the
by Zimahl 13y ago
Ugh, the take-home test/coding assignment. I've done two of these and I will never do another. Bottom line, if a company can't be bothered to respect that the time the interview process eats up for both parties, they probably aren't going to be worth spending their time with long-term.
- tptacek 13y agoInteresting. Why do you feel this way? We rely on "take-home" (they're set up in advance of the f2f interview) work-sample tests pretty extensively, and I feel like they're probably more humane; for instance, you can look things up on the Internet, do them in a comfortable setting, &c.
- ciclista 13y agoHow long do you usually expect these tests to take? Do you pay for the interviewees time?
- tptacek 13y agoNo, we don't. And, a couple hours. The time commitment we demand from candidates is calibrated to be about the same as you'd demand from a (rigorous) day of on-site interviews. Our on-sites are a half-day thing, not a full-day.
- ardit33 13y agoGood developers have always a project that they are working on. Be either an open source project, app, game, little library, whatever. Working on a take home assignment is just a waste of time, where that person could be working on something useful. Or they could be spending that time with their kids, friends, or just relaxing. The only time it is ok to ask for a take home assignment is when the person is at most a couple of years out of school, and they haven't proven themselves yet. I personally refuse doing to do take home assignment as I have enough projects in my belt that I can show. It is usually a sign that the other party is not mature enough, and they don't know what they are looking for, and once you join that company they will treat like a junior engineer, when you might be past that.
- tptacek 13y agoBut you can say the same thing about a long in-person interview, which has the added disadvantage of demanding your time during the working day.
- Zimahl 13y agoI'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.
- nicolethenerd 13y agoI used to agree with you, but I've seen the other side of this. When I was applying for FT jobs out of school, one of the companies I interviewed with sent me a small coding assignment, which I completed - I got the job. I've been here for over 2 years, and turning in that coding assignment is probably one of the best things I've ever done for my career. Was it really necessary for them to tell that I could code? I don't know, but showing up at work and knowing that everyone I worked with had been subjected to the same test and rigorous technical interview was nice - I knew I was working with smart people. In contrast, the other two companies I got offers from barely had any interview process at all, which was worrying to me - if they'd hire me without so much as a fizzbuzz test, who knew what kind of people they had working for them?
- nawitus 13y agoCoding assignment sand fizzbuzz tests are not necessary if the applicants can demonstare their coding ability otherwise, by e.g. showing a portfolio.
- Zimahl 13y agoAre you going to be so responsive to silly fizzbuzz tests 10 years down the line with multiple successful (and unsuccessful) projects under your belt? If a senior developer gets asked to write a sorting algorithm don't be surprised if they just walk out and enjoy the rest of their day.