3 ms·

This seems like a wonderful idea. I hate coding interviews, because I freeze up and I look like a total idiot and cannot do even the simplest things. Same thi

This seems like a wonderful idea. I hate coding interviews, because I freeze up and I look like a total idiot and cannot do even the simplest things. Same thing at exams in school or university - my mind just went blank and into a noisy self-rumination loop. I guess it's called anxiety. I interviewed with Google last week and bombed it, even though the problem was quite simple and I would have solved it wonderfully without all that anxiety. My mind just can't produce any sensible thoughts when someone's breathing over my neck and there's a timer. When I'm solving the problem in real time and talking about it, I have to stick with the split decisions that I verbalize and build on top of them, even though further down the road I realise they're not optimal and this contributes to the anxiety even more. It's hard to 'refactor' your ideas during a 45m coding interview, but this is exactly the process we go through when we write 'real' code - we try a thing, then we improve it by refactoring, we optimize it, we find and fix corner cases, etc. A take-home problem, on the other hand, would be totally cool. I have time to think about the problem, come up with solutions, optimize, unit test - do the real programming thing which I'm being hired for. I would then gladly discuss and explain the code with the interviewer. If then I would be given the task to extend the program with a new feature, then I would be familiar with the data structures and algorithms used and would probably find it much easier to extend, than starting with a blank file and figuring it out on the spot. But I guess not everyone agrees with the home interviews - some think it's a waste of time and I'd have to agree.. So I guess the optimal solution is to offer the option of on-site coding interview or a take-home problem. People like me would take the problem home, build it and shine at it, others, who's minds are sharpened by the adrenaline would take the on-site 1hr coding challenge.

robinson7d 11y ago
As others have mentioned, the trade-offs can be pretty complicated. Perhaps the take-home is always better for you, I won't try to argue against your personal preferences, I'm simply going to list a few reasons why it turns out worse for a lot of people. For one thing, as expected, the take-home questions are typically far larger than in-person interview questions. When you go into the office you're generally asked, in my experience, much simpler questions; you might get a simple FizzBuzz-like starter, and a few slightly more difficult ones. All in, it takes a few hours (Google and the like can be an exception to that, but I'll get to that after - I'm comparing smaller companies right now). The take-home work I've seen has generally been suggested by the company to take 8 hours, but typically been a bit more; they've been along the lines of build a fairly simple crud (I've had one that was a calendar, another that's a stream, etc.) with a bootstrap-or-similar UI, back-end validations, and unit tests for the initial commit, implement these 3-5 features on top of it in separate commits (tested, also standard bootstrap-or-similar UI, proper validation, etc.) And then, simply provide access to the repo. At first, this didn't seem wrong, in fact I figured "well, I guess it's a good way for them to see that you understand everything". But it came with several annoyances. For one thing, since each feature is a commit, unless you specifically try to prevent it they can see things like how long each part took; even if not consciously, this makes people try to get the work done quickly, without taking many breaks. It sort of reintroduces the "hard to 'refactor' your ideas during a 45m coding interview" problem. Another annoyance is that sometimes (and judging by other comments here, even often) they don't respond at all. The silence is unpleasant, to say the least. In-person, you can at least try to read tone and facial expressions. The other problem is one company I applied with threw a 10+ hour take-home without any warning before the interview. So a bit over an hour in their office, and another 10+ later. This is difficult if you're working another job. It's very difficult if you have a couple such take-homes at the same time, and a full-time, in office job. Scheduling a few interviews around work, and other commitments, is pretty feasible, but throwing in dozens of hours of additional coding is more difficult. With companies like Google, you know ahead of time approximately how long it will take. You can take time off accordingly. The process is known going in, and that's great. Basically, I think that for many people, myself included, white-board interviews are very stressful and frightening, but not quite as much so as: scheduling lots of extra time around your life, budgeting X extra hours because they take longer than suggested, building out the (much larger) projects, still having the time-constraint/expectancy issues, and after all of that not always even getting a message/comment afterward. Both interview processes suck.
- codeshaman 11y ago
  There's a lot of truth in what you write and I definetely see the problem. One solution is to have the take home interview as the final step in the process - after having screened the candidate and discussed general technology/framework/concepts without coding. When I did interviews, I found that just by discussing things like thread synchronization and let them explain the projects that they've worked on would weed out most of the candidates which weren't a fit with the position. Then the take-home problem would make a lot more sense for both the employer and employee. Or another method: You take home a problem, implement it, then present the solution to multiple potential employers. The problem would have to be unique (so that there are no ready made solutions online) and trusted by the participating employers. And I think this is exactly what OP is doing, and that's why it's great.
  - robinson7d 11y ago
    I agree with all of those sentiments. At the same time, I prefer the idea of presenting previous open source work instead of having a group of potential employers agree on a project that they can all judge. One benefit is that the work is less arbitrary, potentially useful for others. Another is it's more likely to be unique than an assignment is. Finally, do I want to work for any of those other employers? Applying to a group that way would seem odd to me; part of me thinks that choosing companies is important, but another thinks that there's some chance that that's just because I haven't tried it. Which, of course, leads me to agree that the OP is great as an experiment - it might well be a better solution in many cases. The fact that, in the OP, it's opt-in is a big deal as well. Though I'm still very skeptical of take-home interviews in general.

robinson7d 11y ago

As others have mentioned, the trade-offs can be pretty complicated. Perhaps the take-home is always better for you, I won't try to argue against your personal preferences, I'm simply going to list a few reasons why it turns out worse for a lot of people. For one thing, as expected, the take-home questions are typically far larger than in-person interview questions. When you go into the office you're generally asked, in my experience, much simpler questions; you might get a simple FizzBuzz-like starter, and a few slightly more difficult ones. All in, it takes a few hours (Google and the like can be an exception to that, but I'll get to that after - I'm comparing smaller companies right now). The take-home work I've seen has generally been suggested by the company to take 8 hours, but typically been a bit more; they've been along the lines of build a fairly simple crud (I've had one that was a calendar, another that's a stream, etc.) with a bootstrap-or-similar UI, back-end validations, and unit tests for the initial commit, implement these 3-5 features on top of it in separate commits (tested, also standard bootstrap-or-similar UI, proper validation, etc.) And then, simply provide access to the repo. At first, this didn't seem wrong, in fact I figured "well, I guess it's a good way for them to see that you understand everything". But it came with several annoyances. For one thing, since each feature is a commit, unless you specifically try to prevent it they can see things like how long each part took; even if not consciously, this makes people try to get the work done quickly, without taking many breaks. It sort of reintroduces the "hard to 'refactor' your ideas during a 45m coding interview" problem. Another annoyance is that sometimes (and judging by other comments here, even often) they don't respond at all. The silence is unpleasant, to say the least. In-person, you can at least try to read tone and facial expressions. The other problem is one company I applied with threw a 10+ hour take-home without any warning before the interview. So a bit over an hour in their office, and another 10+ later. This is difficult if you're working another job. It's very difficult if you have a couple such take-homes at the same time, and a full-time, in office job. Scheduling a few interviews around work, and other commitments, is pretty feasible, but throwing in dozens of hours of additional coding is more difficult. With companies like Google, you know ahead of time approximately how long it will take. You can take time off accordingly. The process is known going in, and that's great. Basically, I think that for many people, myself included, white-board interviews are very stressful and frightening, but not quite as much so as: scheduling lots of extra time around your life, budgeting X extra hours because they take longer than suggested, building out the (much larger) projects, still having the time-constraint/expectancy issues, and after all of that not always even getting a message/comment afterward. Both interview processes suck.

codeshaman 11y ago
There's a lot of truth in what you write and I definetely see the problem. One solution is to have the take home interview as the final step in the process - after having screened the candidate and discussed general technology/framework/concepts without coding. When I did interviews, I found that just by discussing things like thread synchronization and let them explain the projects that they've worked on would weed out most of the candidates which weren't a fit with the position. Then the take-home problem would make a lot more sense for both the employer and employee. Or another method: You take home a problem, implement it, then present the solution to multiple potential employers. The problem would have to be unique (so that there are no ready made solutions online) and trusted by the participating employers. And I think this is exactly what OP is doing, and that's why it's great.
- robinson7d 11y ago
  I agree with all of those sentiments. At the same time, I prefer the idea of presenting previous open source work instead of having a group of potential employers agree on a project that they can all judge. One benefit is that the work is less arbitrary, potentially useful for others. Another is it's more likely to be unique than an assignment is. Finally, do I want to work for any of those other employers? Applying to a group that way would seem odd to me; part of me thinks that choosing companies is important, but another thinks that there's some chance that that's just because I haven't tried it. Which, of course, leads me to agree that the OP is great as an experiment - it might well be a better solution in many cases. The fact that, in the OP, it's opt-in is a big deal as well. Though I'm still very skeptical of take-home interviews in general.