[stove]

Does anyone have experience with this style of interview from the candidate side of the equation?

I want to move to this style of hiring; however, I fear that because it's against the grain I may miss out on good candidates. Is that unfounded?

[ubernostrum]

I do from both sides, albeit without being paid to do the exercise. Take-home exercises are great.

When I was looking for a job last year, I liked that it was something simple and low-pressure (compared to typical coding-interview practice) which approximated how programmers actually work. It was OK to look something up in the documentation if I didn't have an API memorized off the top of my head. It was OK to change my mind partway through and realize I could do it more cleanly another way. It was OK to pause for fifteen minutes and get something to drink.

Now that I'm on the other side of it, I like that it's a more natural thing. I like that I'm not having to loom over someone or try to fill awkward silence while they live-code. I like that I can read their solution before I go into the interview and have some prepared comments or questions to get discussion going. I like that it emphasizes the collaborative nature of programming in a team.

Good candidates are beginning to revolt against traditional coding interviews. Take-home exercises are one of the alternatives that people actually seem to like on both sides of the interviewing equation. So you're not going to miss out on good people by switching your coding interview to a take-home; if anything, you're more likely to start attracting them.

[StavrosK]

I want to second that, with the caveat that, if the exercise is unpaid, I am much less inclined to do it (mainly because I am too busy with paid work to take on more, especially unpaid).

I've interviewed with companies that gave all kinds of exercises. I have no problem with take-home exercises, if they're implemented like the article suggests. A few times I've gotten "do this exercise and we can maybe pay you a bit for your time", followed by them never paying and me never asking. If you decide to pay someone for exercising, tell them how much beforehand, and pay them as soon as they hand it in.

The best interviewing experiences have been with paid onsites for companies, even if I didn't end up getting hired in the end (I got to meet the team, work with them, they took me out to dinner, etc, it was nice).

[wccrawford]

I did a weekend exercise for a company once. I didn't care for it. I felt like I was wasting my time when I could be doing something I wanted to do instead, but I wanted a new job and they seemed decent.

However, before they had time to review it and get back to me, another company interviewed me and offered me the job and I took it.

From the other side of that, we now give these assignments when hiring. It has virtually eliminated the bad candidates, and we've hired a few good junior programmers for a change.

However, neither of those 2 situations paid anything. They were throw-away projects that the company couldn't actually use to avoid any legal issues. If we were going for experienced programmers, I think I'd recommend the payment route. But junior programmers? We got too many applicants to send it to all of them, and so we'd end up pre-filtering them like we used to do, which makes the process less valuable.

[cldellow]

We do a variant of this, although we don't currently pay. Perhaps we should. IMO, it skews towards people who are diamonds in the rough (junior, or non-traditional background) or experienced people who are burnt out on traditional whiteboard interviews.

It hurts the size of our funnel, but I think the results we get are pretty good.

[peller]

Well, if somebody legit wants to work for you, I suspect they'll be as curious about working with your team as you are curious about working with them. It's really a win-win situation for both sides.

[philipkglass]

I got my first software job (at a startup) by doing well on an unpaid take-home challenge that I was able to spend a weekend on. A few years later I missed a job opportunity with another company by failing an optimization challenge question that had a much shorter time limit; I started formulating it as a graph search and by the time I realized that was a dead end approach my 3 hours were up. I definitely prefer having a weekend as opposed to a few hours. (Maybe I would have been a bad hire for the 3-hour-challenge position, if a typical work day really involved solving problems like that in a few hours, but I suspect it wasn't representative.)

When I was first looking for a software job I was a researcher who'd written a lot of his own tools but I didn't yet have an open source portfolio or commercial development experience. Solving a challenge was a great way to break the chicken-and-egg dilemma of needing experience to get hired and needing to be hired to get experience.

If I had to switch jobs again I'd also love to find employers screening with weekend challenges instead of live coding. Paying me to complete challenges would just be icing on the cake. I've done well at every company I've worked at, but asking me to write heapsort or whatever while you're peering over my shoulder and the clock is ticking is extremely stressful and unrepresentative.

I'm one of the people screening hires at my current job and I don't want to subject candidates to stressful live coding. But neither would I want to hire someone who can't write decent code and challenges look like a good way to prevent that. Surprisingly, even some people who include a github link in their CV are sharing code that's quite poor. (Like turning O(1) operations in an inner loop into O(N) because they picked the wrong collection type, in a language that offers perfectly suited collections in the standard library.) Maybe they think that nobody will actually read it, and having a github account at all will mark them as savvy?

[epage]

I've only interviewed at one place that used homework. They had two homework assignments with follow up phone interviews to talk about it. The next round was going to fly me out for an in-person pair programming interview. We then parted ways because my circumstances changed and I wasn't going to be able to work in one of their set locations.

I might be more ok with it if it was meant to replace the in-person interview but otherwise it took up significantly more of my time. It was nice that they gave me 2-3 $100 amazon gift cards but, like other posters, I'd rather have my time than extra compensation.

The first assignment was supposed to take 4 hours but took me over 6. The second was supposed to be a whole day thing but I could only put in about 4 hours.

It was useful to gain some insight into their culture. I'm still mixed about what I think of it. The short takeway is that they are continually learning and updating their practices (good) but they were koolaide drinkers (bad) and throwing around buzzwords from specific individuals' blogs as if that was everything without showing a deep understanding of those buzzwords (causing them to completely miss that I exercised those same principles, even if I had no clue what they were talking about).

The longer version. They originally were going to turn me down for not using enough <buzzword>. They were also disappointed that I didn't use <buzzword>. Originally, they weren't even going to explain more than that but I pushed on it to see what I could do better and through the conversation they warmed back up to me. Later I looked up their buzzwords.

The first was SOLID which appears to have limited use in the industry. First, they couldn't even break up which part of SOLID I was violating but instead were throwing the acronym of acronyms around like that was all that needed to be said. When I dug into their feedback more, I found out it was my main function that "wasn't SOLID enough" which did argument parsing and delegated the rest of the logic to other code that was so well designed that they had to throw out the main follow up question.

I literally could only find one software development subcommunity that used the second buzzword and that was mostly limited to one consultant's blog. They also showed a lack of depth in it because I was actually using it, just at a different layer in the stack, solving the same problem they thought it would address.