If somebody offered you a job to merely maintain an old, gigantic codebase, I don't think your first thought would be "wow, I'm going to learn so much from this!", and there probably wouldn't be any way you could assess the codebase quality before accepting the offer so you could end up thinking that eventually. This is how things that you want and that could help you grow can be vastly different.
This is why it's so important to grill your interviewers about the reality of working at the company, although I'll admit that I learned which questions to ask from bad experience. Asking those questions also happens to serve as excellent signalling to your technical interviewers, much more effective than being able to solve some silly logic puzzle.
And to be perfectly fair, you do learn so much from working on poorly written projects that are a horror to maintain. Failure teaches you which mistakes to avoid next time.
Good code is surrounded by good processes. Ask about the processes that lead to good code. This not only susses out what the situation is on the ground, but also demonstrates your own quality.
As a recent grad who has been fired from two jobs, I would be afraid to join a poorly written project because I would worry that I would fail and then be fired.
Learning how to be successful is pretty important and teaches you things you cannot learn from lurching from failure to failure.
Would you mind sharing your best, most probing questions-- the one's that proved most useful cutting through corporate posturing and BS?
Development from scratch means much more ... "sales" overhead. Meetings and (ultimately) disposable documentation.