I would like to add the reason I continue to use my current method is that it creates so many diverse points of data (using that term loosely) because so much h

I would like to add the reason I continue to use my current method is that it creates so many diverse points of data (using that term loosely) because so much happens in the hour we're together. There is something incredibly revealing when it comes to collaboration, especially if the objective is slightly open-ended. People have very different styles of approaching ideas and a lot of the time, it's revealed when the objective hasn't been overconstrained. Simply asking people, "What would you do here?" and "What's your approach?" in a non-judgemental way that actually conveys you're interested in their ideas goes a long way. Also, phrasing your questions so they come off as genuinely curious rather than pointed goes a long way. Most of all, letting people take you somewhere you didn't expect to go is an interesting way to learn about someone. When your agenda is open enough to allow a person to solve a problem with tools or ideas they're comfortable with, it can be eye opening. However, if I see them doing something where I feel like I improve it, I offer to show them a trick and this gives me a tiny peek to see how they learn. Do they get it right away? Do they ask good questions? I think all those things are important aspects of collaboration. You need to have a genuine interest in each other's ideas and receptive to teaching each other new ideas and making each other's work better by adding your insight as well as absorbing their insight. That's why I'm hesitant to simply interview and ask questions. I actually enjoy coding with other people and it's hard for me to see if I'm going to like working with this person if all I'm doing throwing questions at them so they can wax poetic about their last job, thoughts on tech/methods, etc. Again, I'm still not convinced my method is optimal.