If a candidate had a personal or side project that solved a unique and challenging problem I would look at it. When I have seen personal projects they look like programing class assignments or riffs on a language/framework tutorial.
When interviewing I am always most interested in how the candidate will fit into the team and organization, and if they understand the difference between adding value to the business and playing with technology for its own sake. The last time this came up in an interview the candidate had some Raspberry Pi/Arduino code they were proud of, probably fun but not relevant to the job, and so far removed from the business domain that I couldn't judge how relevant it might be.
I can see the argument for a candidate seeking their first job in IT needing to distinguish themselves from the rest of the crowd and how a couple of well-executed projects can help with that. However, it's unfair to expect that any candidate must have projects, especially if they're already in employment elsewhere - few of us have the time or the energy to put into projects of passion after we've done our 40 hours and taken care of other priorities.
Code samples are easy to plagiarize so I always ask candidates who have code samples to explain the code, walk me through it. It's disappointing to see how often candidates can't do that, either because they don't actually understand the code or didn't even write it themselves.