For the on-site interview, we ask candidates to bring their laptop. We advise them to use a typical, comfortable development environment. We've seen candidates struggle with the latest Ubuntu, installed that morning to impress us. So we don't want that.
During the hands-on interviews, we ask to see a side project, or any code they are mostly responsible for, and familiar with. We ask them to explain code, maybe change something, refactor a test, etc.
What we don't tell candidates is that this part of the interview is also about how they use their tools. It's important to see how good they are with their editor, command-line tools, can they type well, do they get easily distracted, and so on.
One of the most effective interviews we do is for project planning. A problem is explained in detail and the candidate is asked to design a solution. Not in code, but to talk it through in detail, drawing or writing docs/stories if needed. This phase helps show us how they break down a project, ask questions, negotiate features, and look for opportunities to reduce complexity. Bonus points for making a pen-and-paper wireframe or throwaway prototype.
What we refuse to do is the "puzzle" problems, whiteboard code (which makes no sense), or tricky technical questions. We instead want to find people that use best practices, don't re-invent the wheel, tackle problems pragmatically, and are good with their tools.
Over time, this approach seems to work well. However, we also discovered that we have to re-train and test our own interviewers. Without that step, the process can change unexpectedly, become inconsistent, or unfair. Don't just assume your staff is interviewing well - take time to check it out and help them get better.