These are interesting but fairly generic and easy for a company to claim many to look good. When defining culture I think it's best to avoid generalisations an

These are interesting but fairly generic and easy for a company to claim many to look good. When defining culture I think it's best to avoid generalisations and have specifics: - If something breaks, what is more important: Preserving state for debuggability or getting online fast - Developers can always say they are not ready to push and continue testing - There are defined SLI's and error budgets - Design docs are required for new functionality - Senior developers are expected to {mentor junior developers, be proactive in creating tooling, understand the full technology stack, refactor} - Sliding scale of time spent on feature development vs keeping on top of technical debt - How much time is spent on automation - Are there well defined leadership tracks for technical and management (a yes/no isn't really enough here) - Onboarding/mentoring, paired with a senior developer or a hire that joined ~6 months ago There are a lot more engineering culture questions based on ownership, communication, personal development and specific engineering tradeoffs.