If you'd like to try out some of these concepts on your phone, I've been working on a side project -- an iOS mobile game called Solar Express [1]. You can launch a rocket, rendezvous and dock in orbit, transfer between moons and planets, and land. It's a bit like a mini-KSP with real orbital mechanics, but more casual - no rocket building, and lots of delta-V to play with.
There's the "remind me about this" feature for messages. The intervals are well-spaced, too. (in 20 mins, in 1 hour, in 3 hours, tomorrow). I find it to be a great way to deal with an interruption that can't be ignored entirely, but comes while I'm in the middle of doing something more important.
Boon + Gable | Server-Side Rails Developer | San Francisco, California | Full-Time | ONSITE
Boon + Gable is a personal shopping service that takes care of all your clothing shopping needs - big or small. We make looking good easier by providing immediate access to stylists who bring a variety of brands and clothes to your home.
We're currently 8 people (2 engineers) and growing. We raised a $2.5M seed round from top investors in the e-commerce space.
We've built an end-to-end system to support our styling service, all the way from algorithmic item recommendations to scheduling to logistics, with 3 iOS native mobile apps, with only 2 engineers. We've helped hundreds of customers who love us.
I love this approach. I'm also wondering what you think about giving well-designed work-sample tests over Google Hangout instead.
The candidate shares their screen with you, so you can watch as they solve the problem in their own dev environment. You can understand how they approach problems (quick and dirty, slow and methodical, lots of rewriting, etc), and you can ask questions at the end. You get a good sense for how they work as an engineer even before having to bring them onsite.
This seems to resolve the time asymmetry of take-home tests as well -- the interviewer spends as much time watching as the candidate spends working.
The only downside I can see is that you have to design your problems to take about an hour instead of the 2-5 hours you could imagine for a take-home test. But, you can break them up into multiple rounds, and give additional exercises to the candidates who do well on the first one, for no more total time cost than a collection of onsite interviews.
For what it's worth, I've done this at my startup and hired a great developer, and got very positive feedback about the process from the candidates I didn't end up hiring.
At my startup, I've had some success hiring mobile devs through "audition programming" on Google Hangout.
I create a "real-world-lite" task like "connect to this simple JSON API I built and implement a recursive product category browser on top of it". I've done this task myself already with a timer and am confident that it will take about an hour to implement. Then I ask the candidate to share their screen and implement it in Xcode while I watch. As they develop, I can get a sense for how they attack problems (quick and dirty, slow and methodical, stack overflow copying, etc), and afterwards I can ask questions about their thought process.
If they did well in the first one, we block out a second one for another hour, and a third for another hour after that, each one testing different skills.
This avoids the time imbalance inherent in take-home projects, because I'm spending just as much time as they are. And it avoids the painful "implement a red-black tree" whiteboard questions by focusing on real-world work in their own dev environment. It also means I have a decent sense of their skills before I ever invite them to an on-site interview.