This is why I'm most interested in two things when interviewing for a job. 1) Are the devs happy/How long have they been here 2) can I see code?
I have been there and the sad truth is that for most codebases I'm going to argue that bringing the whole thing up to a nice status is going to cost too much if it's already in production. Unless it's going to be running for many many years, it's probably not worth the investment. And if it's not worth the investment, then there will be no investment. That may be the correct management decision - but it's a huge red flag when choosing a workplace.
If the code isn't in production already, then it's another matter. Then you can make it worse before it gets better, and it may be a productivity boost even if the cleanup takes several years.
The thing to look out for if you can't clean up the whole thing, is any kind of modularization. Can you suggest that some subsystem is either rewritten or refactored? Make a business case such as "we have so many bug reports in subsystem X" or "We could easily make Y processing 10x faster". Even without tests, it's sometimes possible to implement a new subsystem and use a previous subsystem as the test - your new subsystem works if it responds the same as the old one.
If you are not allowed to take an architectural or greenfield approach (i.e. you can neither rewrite or do large-scale refactorings of at least parts of the code) and you are simply asked to provide small focused (business-driven) changes to the code, and management shows no clear dedication to large scale refactoring or rewriting, then I'd reconsider working there.