I've actually thought quite a bit about this, because I keep winding up on teams where ideas like "loose coupling" are controversial. It really depends on what you're really looking for in a workplace, so you should start with a good hard look at that, and define your questions to not be too pointed, but to get at what you really need to know.
For example, I might ask a question like:
What is an example of code I could write that would automatically fail a code review?
If the answer is, "we don't do code reviews," that opens up a discussion into why not and whether they'd be open to instituting them.
Other answers would tell me how high their commitment to code quality is, and how they even define code quality.
If I got stuck, who would I go to for help, and why?
This tells me how in touch the manager is with the strengths and weaknesses on the team.
How often do people on your team go to User Group meetings (or conferences), and what are some ideas that you've incorporated based on this participation?
Shows their commitment to ongoing learning, and that people don't just go off and learn things, but are able to talk about new ideas and hopefully encouraged to do so.
What are the performance measures for this job, when will I be evaluated, and what happens as a result?
You should ask this one no matter what. This tells you what the financiall incentives are for the team, which can be a good predictor of behavior. But equally important, it tells you what your career progression is likely to be, and what the trajectory of your salary will be if you stay with the company.