A candidate that has a good portfolio and can pass an algorithm and design interview, and described prior work experience on projects that seemed involved is your best bet of course.
No ones gonna hire you because you spent a decade and have a half finished game engine written Haskell.
All of that freedom is fake and some even in contradiction with each other.
You cannot take your time, or you pick a larger scope project, you will eventually run out of savings, or get questions from family members about why your job search is taking so long.
If you filter out everything but smaller scope projects then you have a far smaller subset of projects that aren't as unique because everyone else has done them. If you just graduated from University, you lack experience with project management and as the saying goes, write what you know, and so that'll limit yourself to video games or web and that one niche subject you took at Uni.
This advice feels like what you would get from a rock-star who was young and stupid and naive and very lucky telling a kid that if he just makes music and sticks it out he'll get scouted by a record label, When in reality he just was lucky enough to market pop-derivative music at gigs, while not realizing the kid likes to make music from sampled traffic noise and his favorite album is Music for Airports.
This is a high risk endeavour and you either need to make conscious decisions that mitigate risk heavily and are compatible with your personality, and the end goal of being financially secure.
You start from scratch, you can pick something you're interested in building and maybe also feel you can succeed at. You make up your own requirements, as you see please, so things aren't ambiguous or changing in requirements constantly.
There's no prior legacy constraints, there's no time constraints, it doesn't require finding ways to deliver faster by leveraging other developers.
You get to spend as much time as you need, go watch tutorials, take a hiatus, come back to it when refreshed, fail multiple times and try again, etc.
You can choose the programming language, framework, library ecosystem, that you're more familiar with and comfortable with.
And so on.
So having someone that can show some cool personal projects I've found isn't always a great way to know if they'll be good in a work environment and on a team.