> I learned which questions to ask from bad experience.

Would you mind sharing your best, most probing questions-- the one's that proved most useful cutting through corporate posturing and BS?

> failure teaches you which mistakes to avoid next time

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.

Even the jobs with poorly-written codebases teach you a lot. Only they're teaching you through experience what is or isn't maintainable.

Sure, but at a certain point, you need to learn a method to writing a maintainable codebase. Otherwise you never become capable of building a successful project.

How did you fail?

I'd love to hear which questions you ask in interviews to get this information out of the interviewers!

Ask them the questions you'd want to know answers to if you were hiring them, to determine their own merits. Insist on talking with the people you'll actually be working with. You want to know their opinions on programming paradigms, and design patterns. Ask about operational details like version control, code review, and releases. Ask about the history of the code base, who wrote it, where are they now. Ask how documentation is created. There are so many things you can ask.

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.