There are probably different interpretations of what "culture" means to different people. From a perspective of how people interact to the work done, I (listen for) ask questions about their process, like this:
1. What type of development process do you use. e.g. agile, interative, or waterfall?
Some shops don't have processes at all, which is often a red flag. Be prepared to dig in a little. e.g. if they're agile, you might want to ask if they're Scrum or Kanban, have a backlog, sprints, standups. A lot of places say they do standups, but not much else. If they have a process that they think is working, they're often proud to discuss it.
2. Do you do unit testing?
There are various approaches and you might be able to dig in to find out if they do BDD, TDD, or afterwards. If they don't, it could indicate design issues from non-testable code, strong coupling, hard to find bugs.
3. What are your code reviews like?
Code reviews (properly done) can be a great way to help other people on the team, share info, and generally improve the quality of the code. Lack of code reviews, is a possible red flag that people aren't helping each other on the team and building a common team standard.
4. How good are application requirements and how are they communicated to me?
This could be good or bad, depending on how you look at it. It might be telling if you feel a negative vibe out of the response. That said, it's rare to have developers comfortable with a certain level of ambiguity. It's mostly a data point to see how the interviewers react to an often-contentious subject and gauging how you feel about the response.
Also, be prepared to discuss your experience in any area you bring up because it's common for an interviewer to aim the question back at you.