When lunch is impractical (as with remote candidates), you have to find another way to backstop your research findings and figure out if this developer is any damn good.
You can do a lot of this over the phone, mind you, but it’s never going to be the same as in-person. It just isn’t.
For remote, I highly suggest going with a freelance-first approach.
Conduct a phone interview, treat it much like a conversation over lunch. Try as much as possible to make sure you feel pretty comfortable with this person, and make sure they’re comfortable with you.
Whenever you do feel comfortable (can even be at the end of that phone interview), you want to offer a short freelance engagement.
“What’s your freelance rate? We have a small project coming up that we’d love for you to take a crack at, so we can make sure we have a good working fit here. We’ll pay you your standard rate for the work, and both make sure we’re feeling good about things afterward. Sound good?”
Again: Yes, you will pay them for this work. And don’t make it bullshit work. Pick something smallish that you need done. Maybe some feature or supplemental piece your current team can never seem to get to.
Manage the code through GitHub or similar so you can get a clear idea of how this person works. Do they check in code frequently? Does that code make sense (ask your lead developer to take a glance if you’re not sure)? Is it timely?
Make comments on the code. Treat the freelance assignment as if they were already employed. Ask the same questions and make the same (code-related) requests you would if they were a full-time employee.
Again, you essentially want this to be a try-out period. Do you like working with them? Do you like the quality of the work? Do they like working with you?
Nothing tells you how a person will work better than working with them.
All the interviews and all the references in the world can never match personal experience.
“I’ve worked with this person. They were doing the exact job I’m hiring for. They did great at it.”
It’s the absolute best way to vet a candidate. Better than any whiteboard puzzle or brainteaser, it will show you how they work free of any artificial constructs and in a practical, real-world example of the work they’re actually being hired for.
It also eases the transition from the developer side. Much like you now know what it’s like to work with this person, he or she now knows a) what you’re like to work for and b) what the work they’ll be doing looks like. They’ll also likely know how you like code organized, what platforms you use and all the rest.
By the end of the engagement, they’re already pseudo-employed. It’s a handy intermediate step before either of you make a commitment.
Again: It’s much like moving in together before marriage.