Just because someone doesn't have many side projects doesn't mean they aren't a good developer. Often times we assume that other people will have had access to the same opportunities that we had - in college, in the workplace, and in life in general - but this is a fallacy. Perhaps a developer had to work their way through college and didn't have time to go to hackathons or work on side projects. Perhaps she was so busy running a developer network at her last job, in her last city, that she didn't work on something besides that. Or maybe they just don't care about side projects.
I think, ultimately, the goal of a technical interview is to get the interviewee talking about something that excites them. Seeing that an applicant can get excited, spend hours learning something, and dig deep into whatever they are interested in is the most important part of an interview.
Be careful with things like "cultural fit" as that nebulous term is often used to excuse personal problems. If you can, initially evaluate the interviewees work without looking at their name, race, gender, or other identifying information. By doing this, you help avoid inherent, subtle biases that your recruiters may have. Those biases exist everywhere, and the best we can do is take steps to mitigate their effects.
Finally, I think trial jobs are greatly under-appreciated. Offer an interviewee non-critical, non-trivial work on a week long contract basis. Pay them industry standard and work with them on the feature. If that feels right, hire them. If it doesn't, evaluate what went wrong and move forward from there.