Comment To avoid legacy code, constantly change jobs ;) (Score 0) 360
Unless you hop from startup to startup, you'll have to deal with legacy code at some point, either someone else's or your own. Here are some indicators I came up with (warning: a lot of broad generalizations follow; they don't always apply):
1) "was the code base developed in-house?" in-house developers generally have a deeper understanding of the requirements, resources, and the company. Some contractors do just enough to meet the requirements so that they can get paid and move on to the next project. Quality is generally higher when someone has to maintain the code and/or face their peers every day in the office.
2) "how many projects are developers involved in at once?" if a developer has to juggle more than a few projects at once, one or more might not get the attention that is needed to be of the highest quality. Conversely, if someone is just focused on one project, the quality might be better due to their deeper commitment to the project and understanding of the internals.
3) "what's the employee turn over rate?" your experience is likely to be less awful if the original author or authors are still around; they can at least explain some of the reasoning behind the design decision. Conversely, if the original designer is long gone and many people have dabbled in the code, the quality might suffer due to developers having different ideas about how to best maintain the code and different understandings of how everything fits together.
4) To follow on the "Are there code review processes?" question, you might want to ask "how is performance evaluated?" It's a good question to ask in anyway, and that might give you an insight into how much oversight there is of a developer's work quality.
Also keep in mind that you need to strike a balance between beautiful code, functionality, and time/cost. Sometimes less elegant code is more maintainable, takes less time to develop (i.e. costs less in labour), and does the job well enough.