We gave candidates an option of a take-home screen (build a web app that consumes our single-endpoint JSON/XML API and renders content) or a live coding exercise (implement a least-recently-used key value cache to store 100 entries). Folks who could basically code did a 3/4 day onsite that included a code review of their interview project or an applied exercise if they did the live coding. Offer out within 24 hours after the onsite. Any recommendations to improve that process would be much appreciated.

Thanks for the feedback about the 4-6 engineer's worth of talents. It's good to know, and we realized a similar thing and pared down the JD to be less oppressive-sounding.

Sleep and balance was important to the team (I personally averaged around 35-45 hours a week, working one weekend and being called in maybe a half dozen times over a year and a half; the system mostly runs itself), but we didn't find a good way to surface it in the description. Any suggestions on this is appreciated too. I struggled in that when we removed or played down aspects of the job, or emphasized work-life balance, we just got more folks who were seriously green in some parts (front-end devs who can pull together jQuery but have never deployed their own code or had to write backwards-compatible apps).

That's a decent interview process, provided the focus of the code review and the coding exercise is collaborative in nature. When I interviewed at IFTTT, they did their live coding exercise especially well. I never felt like I was being given an arbitrary pop quiz. It was a series of actual problems you might face on the job (a bunch of string replacement scenarios, if I remember correctly). The environment was more akin to pair programming with a remote co-worker than an interview. Instead of strictly evaluating and overlooking, my interviewer worked through the problem with me and even wrote part of the code. I didn't make it past that first live coding exercise, either. They wanted someone with deep JS knowledge and mine didn't go deep enough. They were honest and respectful, even when delivering a rejection. If I ever decided to move back to SF, I wouldn't hesitate to interview with them again.

Sleep and balance was important to the team ... but we didn't find a good way to surface it in the description.

That's a tough one. Any company you ask will say they're great on work/life balance. What else are they going to say? 'No, we're going to work you 80 hours a week every week. If we ever hit crunch mode, say goodbye to your weekends!' The only thing I can think of is to show them that everybody goes home at 5pm by having the 3/4 day onsite start later in the day and end at the same time everybody goes home. It also gives the added benefit of allowing the interviewee to interact with everybody as a group.

front-end devs who can pull together jQuery but have never deployed their own code

For what it's worth, that's pretty standard in web development. I've deployed code through beanstalk or jenkins, but devops sets that up. I've also deployed side projects to my own servers, but that's a whole different ball of wax compared to deploying to a corporate data center with load balancers. I wouldn't trust a frontend jquery guy to set up those kinds of deploy environments. It's a completely different discipline and field.