The idea is in order to get the highest signal-to-noise ratio assessment in the least amount of time, you should ask for and look at old code before they come in and then just hangout for an hour.
Why? The most important interview questions to answer are:
Solving puzzles on a whiteboard or asking angular.js questions will not answer any of these. If you need to ask those questions then you haven't done the homework on the person or they can't communicate their skills properly. Either way, this is a problem and an on-the-spot interview isn't an appropriate tool to fix it.
In fact, such technical inquiry should be considered harmful.
Presume you have a clever brainteaser. In the best circumstance, a candidate thinks a bit and gives a nearly textbook answer.
This is a problem: either it's a dishonest candidate who has seen the problem before and is misrepresenting memory as cleverness or you're in the presence of a unusually gifted genius. Unfortunately, statistically, it's likely the fraud.
Let's say the answer is acceptable. Is the person stubborn and inflexible with it? Would they be implementing it by hand or not know how to refactor it or and not look for a library? Everyone knows the right answers to these questions. So where does that get us? What if, instead, someone gives an honest and detailed answer. What does that say about the people who gave the "right" ones? Who knows!...that's the point.
Now pretend someone doesn't come up with a satisfactory solution. Either it's an unsuitable candidate, the question was asked wrong, the candidate is better than you and you don't understand the solution, or perhaps the brainteaser has nothing to do with how one allocates their time, prioritize their tasks, documents their code, communicates effectively with team members, or does anything else that actually matters ...
The brainteaser wastes valuable time better allocated to actually getting to know the person.
Every codebase at every company is new. Learning how something is built and not breaking it too badly while pushing the project forward is the essence of a good hire.
If the thought process is "This codebase is in ABC Lang, I must find people who know ABC Lang!", this will
Enumerating and requiring skill sets warp the field in a hazardous way. If you aren't convinced of competence by the code offered, then you shouldn't be at this phase.
Additionally, knowing the existence of something isn't necessarily correlated with one's ability in it.
For instance, many scripting languages have near equivalent technologies for things like package management and unit testing. Would someone who has worked intimately and extensively with the Python, Perl, PHP, Ruby, and Go equivalent of Node.js XYZ (but hasn't heard of Node.js XYZ) be better than a person who started reading a blogpost on Node.js XYZ an hour ago, but has never actually used it or the XYZ equivalencies in other languages? Who'd do better at "What is the Node.js module XYZ for?" Who ultimately could write better code with XYZ?
Although that's an extreme case, gotcha questions as a substitute for assessment of breadth and depth are a common poor-information tactic. Reviewing code and doing some googling is a far superior and less error-prone indicator or quality and experience.
The on-site hangout is a pleasant, friendly, respectful hour where you offer them lunch, buy them coffee, and just kick it. You've already vetted their technical prowess over email and there's other things to communicate now:
The interview tactic here is called "gathering". Give opportunities to volunteer information through the process without the appearance or ceremony of the interview. You can make subtle, unguarded assessments of their overall suitability and answer the ever-pressing question "Can I work with this person daily?"
Additionally by asking for and contacting references before they show up helps you see if the candidate's perception of themselves match the perceived reality of others.
Afterwards, send an email thanking them for their time and ask them what their interest is. This is the dreaded "Why company X?" in addition to "Why technology Y?" and "Why team Z?" all in a non-confrontational, eager, and courteous form giving them the time and space to be thoughtful and sincere about their answers to these important questions.
End Goal: A compassionate and effective way to find out who wants to be there and is right for the job.