What I'm seeing here is overengineering of the interview process.<p>There are three things you want to figure out:<p>1. Are they able to do the work, and if so, can they do it well?<p>2. Are they a cultural fit with your company?<p>3. Do their goals align well enough with yours? (do they have a genuine interest in the space you're in, are they just using you as a stepping stone, etc).<p>Points 2 and 3 can be discerned by the phone interview, the in-person interview, and the lunch.<p>Point 1 can be discerned by looking at and talking about a non-trivial open source project that the candidate has built. Basically, you want to dig into architectural or technical difficulties they faced (you always have these in non-trivial projects), and how they surmounted them. The finished product is more than enough to gauge competence and discover excellence. It's only if they DON'T have anything big they can show you that you need to resort to coding assignments.<p>Logic problems and brain teasers are a relic of a (thankfully) bygone era of bad hiring practices. There's no evidence to support the theory that people who do well at brain teasers do well at architecting and building applications. All you end up doing is potentially pissing off the candidate.<p>In the end, you need to understand that it's a two-way street. An exceptional candidate is likely to have many offers to choose from. Waste their time, and they'll go with someone else, leaving you with two kinds of people: Those who have a keen enough interest to suffer through your interview process, and those who are desperate enough to suffer through your interview process.