I've been compiling a mental list of things I want to know about a potential team. The code itself is not one of them - too sensitive to get access to, too large and context-dependent to evaluate from an outside perspective. But I do have a bunch:

- How is the physical space, crowding, noise level, workstation quality? How many hours a week do you spend in meetings? How to decision makers think about focus vs. collaboration?

- What is the process by which a proposed code change gets to production, and how long does it take? Code review? Linters? Unit tests? Integration tests? Human QA? CI/CD?

- What is oncall like? How many alerts per shift? Signal to noise ratio? How do you manage incidents? What are postmortems like? Are they about accountability, system hardening, or trying to balance both?

- What are some of the debugging/observability/operational tools you've developed for your product? What are the stories behind them?

- How do decision makers think about tech debt vs. feature velocity? What if any official support is there for getting tech debt items worked on?

- Can I fix & try things on my own initiative in addition to meeting assigned tasks, or must every work hour be dictated by the process/PM? Is an architect telling me exactly how my code has to be structured or am I making my own decisions?

- Where do deadlines come from? How real are they? What happens when a project is looking like it won't meet its deadline?

- What would happen to the business if your team disappeared? What are your current projects and why do they matter?