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.
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).
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.