No, because the quality of the existing code isn't what affects my interest in the job. The vast majority of software out there has mediocre structure at best. Your responsibility is to improve it gradually, leaving each function or module you touch a little bit better than you found it.

The jobs I've enjoyed the most and learned the most from were incidentally the ones with the worst codebases.

That said, it's probable that there's a certain degree of awful that it's simply impossible to work productively with. As a hiring manager, I wouldn't consider it unusual or a red flag for a developer to ask to see the codebase; and every project has at least some code that isn't too sensitive to share (well, there are probably some exceptions in regulated industries).

If a developer doesn't have the maturity to be willing to work with a codebase that's six years old, where the earliest layers were quick-and-dirty proofs of concept developed without automated testing just to get a startup off the ground, and the latest are better but still flawed, then they're a poor fit here anyway. We need developers who understand that the code exists to serve the business and not for its own sake.